• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2064
  • Last Modified:

OCS R2 sip trunk with mitel 3300 ICP

We have successfully configured communications (Mitel---sip trunk---Mediation Server) between OCS and Mitel ordinal users, however we have one small problem:
calling from Communicator to Mitel local user, Mitel user can only see calling number without name.
Name resolution works between mitel users and when calling from Mitel to OCS (OCS user can see caller's name, but Mitel user still can see only dialed number without name).

Does any one have any ideas?
0
from_exp
Asked:
from_exp
  • 2
  • 2
1 Solution
 
gaanthonyCommented:
Apply all the latest updates to OCS 2007 R2.  They are available on Windows Updates when you configure for all Microsoft Updates.
Next you can enable OCS Debug Logging on the OCS Mediation server and select Mediation and S4 under Components and set Level to All and Flags to All and start logging and make a call out from Communicator to Mitel to see how the number is being passed.  That may help in understand what Mitel is receive to do the lookup against.  Inbound in Enterprise Voice Scenario OCS is going to match against Active Directory using the Location Profile Normalization Rules which you say are working.  Not sure how Mitel does the matching but between the Mediation Server logs and the Mitel logs you might find your answer.
0
 
from_expAuthor Commented:
We have OCS R2, all parts are fully patched.

I've done a bit of sniffing(wireshark) from mediation server along with session logging.
It seems mediation server does not pass caller's name to Mitel, so To and From fields look like:
From: <sip:+755@domain.com;user=phone>...
To: <sip:+235@<Mitel IP>;user=phone>...
Between OCS and Mediation server conversation looks a bit different:
From: <sip:+UserName@domain.com;user=phone>...
To: <sip:+235@<Mitel IP>;user=phone>...


So is there any registry keys, or hidden features, I should enable in any of OCS components, to pass name to Mitel in format
From: "UserName"<sip:+755@domain.com;user=phone>...
To: <sip:+235@<Mitel IP>;user=phone>...
or I should look in Mitel side (I have a Telephony Directory in Mitel and I expect, that Mitel should resolve 755 to UserName from there...)
0
 
gaanthonyCommented:
OCS does not use if received or pass the "UserName" in the From.  Only what comes after the sip:.  You will need to look in the Mitel side.
0
 
from_expAuthor Commented:
got an answer myself.
take a look at a similar Q here:
http://social.microsoft.com/Forums/en-US/communicationsservertelephony/thread/4bc62115-c66d-4f81-bba1-a68e4cab84df

Qoute from a thread:

As my friend Chris commented, this is "by design" at this point.

The logic is that OCS is an identity based system, with strong authentication. Names in OCS are meaningful - they imply authentication. However names outside of OCS are in clear and can be easily spoofed.

For outgoing calls, the notion was to confine names to strongly authenticated realms only, or to leave it to the third party system to make its own determination of whether it wanted to perform name resolution, against what and how. Third party systems generally have some reverse number lookup capability and should be able to present caller name if they deem it appropriate. Note that transmitting the name from system to system is not mandated by the standards.
For incoming calls there is the possibility to do number lookup against Outlook contacts in particular and to present names on that basis.

Several concern have appeared over time with respect to this approach. For example, some third party systems such as CUCM are unable to do reverse number lookup for incoming outside calls (so it's not just an OCS problem, of course ;). Also it is unclear that it is any less easy to spoof the calling party number than the calling party name, so the argument on spoofing would eventually lead to presenting no information at all on incoming calls unless they are strongly authenticated. And that is clearly not an option... Last, OCS R2 now provides more situations where non authenticated names can be presented (such as non authenticated users joining an audio conference from a web browser) - and OC is now able to indicate that the user is not authenticated through a graphical indication.

We are clearly aware that customers would want the names to be transmitted across Mediation Server, and giving it due consideration for the future.

Thanks
0

Featured Post

2018 Annual Membership Survey

Here at Experts Exchange, we strive to give members the best experience. Help us improve the site by taking this survey today! (Bonus: Be entered to win a great tech prize for participating!)

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now