Recently ran into an issue where a client was integrating Lync 2013 with a Cisco Unified Communications Manager version 8.6.1 using Direct SIP. The behavior we experienced was PSTN callers would appear as "Guest" for participants that were connected to the meeting with Lync 2013 clients and as the Lync Frontend Server FQDN for participants connected with Lync 2010 clients. When you put your mouse over or hover over the odd name, it would show the caller ID as a long SIP string with "@anonymous.invalid" as a suffix.
Troubleshooting efforts lead to a Microsoft Premier Support Case. Here is what Microsoft came back with:
We did a deep dive analysis on the data you sent in, and here are the key points:
When a client joins a conference the way it knows about other users is by BENOTIFY method. Server sends BENOTIFY to client and in those message the xml content contains info on who else joined…who is a presenter..etc.
In this case, the BENOTIFY for PSTN (call coming in to conference from the CUCM) does not contain any display text – so for 2013 we see the guid for 2010 we see the server FQDN….probably a little change of design there. But the root cause is same.
Here’s a good example:
good call
<users state="partial">
<user entity="sip:3530;phone-context=DefaultProfile-0d74a58ee54c4ed59dfc333cd4570bd6@anonymous.invalid" state="full">
<display-text>3530</display-text>
<roles>
<entry>presenter</entry>
</roles>
<endpoint entity="{ea231f91-b5a2-461d-99be-d960e9b2daba}" msci:session-type="focus" msci:epid="4AF0BAF2CE" msci:endpoint-uri="sip:deldenlync.delden.com@delden.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.Caa:rwbqTnfwgVSUM15AqkoacgAA">
<status>connected</status>
bad call
<users state="partial" msci:participant-count="4">
<user entity="sip:7049756735;phone-context=DefaultProfile-d0b3c9a81a384777bb0811ba487554a9@anonymous.invalid" state="full">
<roles>
<entry>presenter</entry>
</roles>
<endpoint entity="{d81e731f-fb25-4146-b862-49ba7801a56c}" msci:session-type="focus" msci:epid="B27E8D1E99" msci:endpoint-uri="sip:KADABRA.ssloral.net@ssd.loral.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.Caa:rAvnmWCMW1W69NohbWNQZwAA">
<status>connected</status>
<msci:clientInfo>
<cis:separator/>
So the real issue is, why does the server send a BENOTIFY which does not contain caller-id information in the form of “display-text”?
That leads us back to what we get from CUCM.
In this case, CUCM sends SDP-less INVITE and later an update to update the caller-id. For typical call setup, the SIP Protocol dictates that the first INVITE sent by gateway contains all the information needed – like IP, port, codec and caller-id. In this case, the CUCM is sending it in bits and pieces (for lack of better term). I believe that is what causing us to choke on caller-id.
Is MTP setup on the CUCM? We typically see this behavior if MTP is not there.
Incidentally, MTP had been disabled on the SIP trunk because when it was enabled PSTN callers could not connect to the Lync dial-in conference because DTMF key presses were not recognized. Cisco TAC recommended that MTP be disabled and that resolves the DTMF issue for PSTN callers into dial-in conferences. More from Microsoft on this:
Not sure where that came from, we always recommend MTP set to PRACK. Lync has no problems with DTMF, we fully support it.
Reference: http://technet.microsoft.com/en-us/lync/gg131938.aspx
|
Cisco Unified Communications Manager
Cisco Unified Session Manager* |
Direct SIP |
UCM 8.5.1.12900-7 |
Configuration Notes:
1. On the Cisco IP-PBX, configure MTP to enabled and PRACK to enabled.
2. On Lync Mediation Server, Media Bypass is set to enabled. RTCP is set to disabled, as Cisco doesn't send RTCP messages. REFER should be set to enabled, as REFER is supported by this IP-PBX.
Known Limitations:
1. Comfort noise generation is not supported. As a result, comfort noise is not played on Microsoft Lync. When a Lync user configures call forward or simul-ring to a PSTN IVR number, the calling party will not hear early media played from the IVR.
* Note on Cisco Unified Session Manager: Cisco states that Unified Session Manager is based on the same SIP capability as Unified Communications Manager. As such, it is supported with the same capabilities as the qualified version of Unified Communications Manager. |
If you check out the referenced documentation there, here’s the blurb on MTP & DTMF:
The Media Termination Point Required option requires some explanation. In CUCM, MTP can be used to provide SIP Early Offer or DTMF Relay. Lync and CUCM both support RFC 2833 for DTMF Relay, so MTP is generally used for SIP Early Offer. Although Lync does not require Early Offer for call setup, Early Offer is required for media bypass in Lync. Also, there are some call flows and supplementary services that need an MTP to be inserted.
In this case, we selected Media Termination Point Required for best interoperability and call flow support.
Note. In CUCM 8.5, together with the Early Offer Support for voice and video calls (insert MTP if needed) option in SIP Profile configuration, you can clear the Media Termination Point Required option. Even with Media bypass, calls can be set up without MTP inserted.
Bottom line, you’re going to need that on.
One more follow up after some additional data analysis.
The Lync client gets a BENOTIFY packet from the FE server after it joins a meeting, and subsequent BENOTIFY packets when additional users are added to the conference. Within this BENOTIFY is the caller-id and other information of all other participants in the call. In the data from your PSTN user joins a conference scenario, we see that the BENOTIFY does not contain caller-id (Display-Text) information.
Tracking back, we have confirmed that Cisco is not using MTP. As a result, you have an sdp-less INVITE and that first INVITE does not contain the caller-id information. It comes in a subsequent UPDATE packet. This causes AVMCU not to process the displayname of caller-id when the conference is created (or updated). This is intentional and by design. Lync has chosen not to implement every possible aspect of the SIP protocol. Because we made the design decision to not process UPDATE packets, the AVMCU will not update the conference with any information sent in the UPDATE packet.
For interoperability we have worked with Cisco to jointly provide the guidance I listed below, MTP enabled tells Cisco to go ahead and include the caller-id with the initial INVITEs. Again that’s a joint recommendation worked out between our technical organizations. MTP solves the Caller-ID issue.
Hope this helps further explain what is going on and why we need MTP enabled.
The challenge is that once MTP is enabled, we are unable to test because PSTN callers attempting to enter the meeting entry code still is not recognized. Off to troubleshoot with Cisco.