Solved

OCS R2 sip trunk with mitel 3300 ICP

Posted on 2009-07-02
4
2,033 Views
Last Modified: 2013-11-29
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
Comment
Question by:from_exp
  • 2
  • 2
4 Comments
 
LVL 12

Expert Comment

by:gaanthony
ID: 24770342
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
 
LVL 21

Author Comment

by:from_exp
ID: 24770888
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
 
LVL 12

Expert Comment

by:gaanthony
ID: 24772274
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
 
LVL 21

Accepted Solution

by:
from_exp earned 0 total points
ID: 24792607
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

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Have you considered what group policies are backwards and forwards compatible? Windows Active Directory servers and clients use group policy templates to deploy sets of policies within your domain. But, there is a catch to deploying policies. The…
If your business is like most, chances are you still need to maintain a fax infrastructure for your staff. It’s hard to believe that a communication technology that was thriving in the mid-80s could still be an essential part of your team’s modern I…
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…

685 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question