ISSUE ALERT: Cisco Gateways with Lync Media Bypass Inbound Call Failures

This was an interesting issue this week that was being encountered by one of the companies I work with. Thanks to the help from some of the guys at Microsoft Global Voice Practice (big thanks to Doug and Taimoor) we were able to find the issue. Also thanks to Eddie who's continual harassment lead me to reach out to Doug and Taimoor for more help.
The Issue
The issue only surfaces for inbound calls when media by pass is turned on the Mediation Server for Cisco Gateways. In the case we were working on the call would make the client ring but the client could not answer and the call would fall back to Exchange Unified Messaging. Although Exchange UM could answer the call the Lync client could not.
Below is the SDP sent by the Cisco gateway that indicates comfort noise payload type 19. 19 was reserved for an IETF draft that was eventually replaced by RFC 3389. RFC 3389 describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN).
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 6674 1741 IN IP4 10.10.125.10
s=session
c=IN IP4 10.10.125.10
t=0 0
m=audio 17544 RTP/AVP 0 101 19
c=IN IP4 10.10.125.10
a=rtcp:17545
a=x-bypassid:bc5cdacd-0c16-47e5-8213-97808ff94bbf
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
a=x-mediasettings:signalboostunsupported rtcpunsupported holdrtcpunsupported
As you can see the gateway signals the wrong comfort noise format for G.711 and the Lync client is unable to answer the call. Not sure why Cisco are still using 19 format as default since the RFC was written in 2002 but it is what it is. There is an expectation in the RFC of backward compatibility   also so this may be more than the wrong default at play here so I am not about to point a finger.
The Fix
There are in fact two fixes that are pretty easily configured on the gateway. First off you can disable Voice Activity Detection all together on the outbound dial peer. The second option is to change the payload type for comfort noise to the correct format. Its pretty common for people to turn VAD off by default so some people may not have realized this issues existed. Previous Cisco documentation for OCS R2 has VAD enabled which it is by default so people migrating to Lync hoping to take advantage of media bypass might be caught out.
Option 1
dial-peer voice 1999 voip
 tone ringback alert-no-PI
 description TO Lync
 destination-pattern 55555
 session protocol sipv2
 session target ipv4:192.168.1.250:5068
 session transport tcp
 dtmf-relay rtp-nte
 codec g711ulaw
 fax protocol none
no vad
 
Option 2
 
dial-peer voice 1999 voip
 tone ringback alert-no-PI
 description TO Lync
 destination-pattern 55555
 session protocol sipv2
 session target ipv4:192.168.1.250:5068
 session transport tcp
 dtmf-relay rtp-nte
 codec g711ulaw
 fax protocol none
rtp payload-type comfort-noise 13
 
Hopefully this helps some poor sole stuck on the problem and now they can move on with their lives.
Comments welcomed.
VoIPNorm

6 comments:

  1. Chris NormanFebruary 7, 2011 at 6:30 PM

    I noticed that the formating is a bit messed up in RSS feed. The text is white and for some reason it wasnt converted to the correct colour in the RSS feed. Appoligies to those that had this issue.

    Cheers
    Chris

    ReplyDelete
  2. AnonymousFebruary 8, 2011 at 11:18 AM

    Chris, we are also testing some features of Lync with inbound calling in a very similar topology. Only our issue appears to be that media-bypass is not supported with a SIP delayed offer. We have tested this several times and can confirm that inbound call to Lync, routed via CUCM, requires that MTP be required on the SIP trunk between CUCM and Lync in order for Media-Bypass to function.

    We do not see any issue with the exact same topology on calls originated by Lync -> CUCM -> PSTN; media-bypass works.

    So curious if you have seen this. No where have I seen on any blog or technet article call out that early-offer is required for media bypass to work on inbound calls.

    Thanks!

    ReplyDelete
  3. AnonymousFebruary 9, 2011 at 8:54 AM

    One other comment/question, you said UM can answer the call, which I assume all things being equal means UM supported CN type 19 in the SDP. Can you confirm that to be true? If so, then I would suggest MS is at fault for not maintaining the same support in Lync. Not as if a majority of interest here is integration of CUCM and Lync....

    ReplyDelete
  4. Chris NormanFebruary 9, 2011 at 9:30 AM

    That is true. Exchange has no problem answering the call. Like I said I wasnt pointing fingers and this maybe another issue which could be a issue with the Lync client but fact remains by default the ISR doesnt comply with the RFC. You need to make a change to have it comply. Something to keep in mind.

    ReplyDelete
  5. ChuckOctober 16, 2012 at 9:13 AM

    Was any of the above with CUBE in the picture? Or not at all? :-/

    ReplyDelete
    Replies
    1. Chris NormanOctober 16, 2012 at 9:23 AM

      Hi Chuck

      CUBE or not the issue is the same as it affects all IOS versions. So you will need either to use option one or two and have the dial peer pointed at Lync us one of the options above.

      Delete

Note: Only a member of this blog may post a comment.

Subscribe to: Post Comments (Atom)