Come in….

Welcome….

To Call flow Mystery Theatre…… (Anyone remember Mystery Theatre? – yes, I am old)

<Cue creepy music>

 

A while back I came across this issue:

 

Lync Client (2010 but 2013 client had similar issues) to Lync 2010 server/mediation (collocated and standalone tested) to Cisco Call Manager 8.6.2/9.1.2 tested).

1. Lync calls Cisco Endpoint, call connects successfully.

2. Since Media Bypass is enabled, signaling flows as expected from Lync Client to Mediation to CUCM, media goes from Lync Client to CUCM.

3. Lync client places call on hold. (hold it now!)

4. Lync Client resumes call and call drops because REINVITE fails.

Thats not very cool now is it?

 

And so the troubleshooting begins – to BING we go!

 

But first, the environmental Checks:

All the typical (and hopefully correct) settings for interop with CUCM were verified:

On CUCM – MTP Enabled, PRACK enabled, Early Offer Enabled

On Lync 2010, Media Bypass enabled Globally in network configuration and in the trunk config

REFER Disabled (LOL – you said REEEFER 🙂 though I believe CUCM supports REFER), Session Timer Enabled, RTCPActiveCalls disabled and RTCPCallsOnHold disabled

 

 

Some Example Traces from the issue:

 

Invite v=0 o=- 0 2 IN IP4 10.2.1.10 s=session c=IN IP4 10.2.1.10 b=CT:99980 t=0 0 m=audio 8774 RTP/AVP 0 8 101 a=maxptime:200 a=inactive a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=x-bypass

After hold v=0 o=- 0 3 IN IP4 10.2.1.10 s=session c=IN IP4 10.2.1.10 b=CT:99980 t=0 0 m=audio 8774 RTP/AVP 101 a=maxptime:200 a=x-bypass

P-ASSERTED-IDENTITY: <sip:8476410202;phone-context=CLW@nofqdnforyou.com;user=phone> ms-diagnostics: 10040;source=”Lync-02.contoso.net”;reason=”Unexpected call termination from gateway side, ITU-T Q.850 Cause resource unavailable class”;component=”MediationServer”;sip-reason=”Q.850;cause=47″ ms-diagnostics-public: 10040;reason=”Unexpected call termination from gateway side, ITU-T Q.850 Cause resource unavailable class”;component=”MediationServer”;sip-reason=”Q.850;cause=47″ Reason: Q.850;cause=47 

Additional searching on the issue led to this Linkedin post by Suresh Sundararaman (thanks for posting this by the way) which described the issue perfectly but no real resolution was found. Ultimately it was determined that Lync was not sending back a correct b=CT:64 line which CUCM couldn’t interpret correctly so the call was dropped.

So PSS was contacted and after some time and testing, we were provided with the following LUA script (whatever that is)

 

M = {} function M.outbound_ANY(msg) local sdp = msg:getSdp() if sdp then local b_CT_line = sdp:getLine(“b=CT”,”64″) if b_CT_line then b_CT_line = b_CT_line:gsub(“64”, “1000”) sdp = sdp:modifyLine(“b=CT”, “64”, b_CT_line) msg:setSdp(sdp) end end end function M.outbound_ANY_ANY(msg) local sdp = msg:getSdp() if sdp then local b_CT_line = sdp:getLine(“b=CT”,”64″) if b_CT_line then b_CT_line = b_CT_line:gsub(“64”, “1000”) sdp = sdp:modifyLine(“b=CT”, “64”, b_CT_line) msg:setSdp(sdp) end end end

return M

Unfortunately the project was put on hold before we could verify this script worked to resolve the issue. Sad face. But wait…

Funny how things work sometimes…..

I’m on an escalator at Lync Conference 2014, talking with no other than @kenlasko and I don’t even remember how it came up, but he was talking about the exact same issue he was having. So I provided him with the above script and poof! success!

Hope this helps anyone coming across this issue. And many thanks to  for the linked in post.

Additionally, there are additional discussions on this subject by Michael Greenlee here and it looks as though this could be resolved on the Lync side via MSPL, but since Lync is perfect, why not let just let the Cisco boys do the work 🙂

I will consider this post a work in progress, please let me know if you have similar issues and your results are different.