Tuesday, January 14, 2014

How Video Kills the Audio Call with Early Offer

This is a quick blurb regarding an issue someone emailed to me a few weeks ago. It is a pretty straightforward example of why one should pay attention to CUCM Region settings and interoperability parameters of your ITSP before you deploy Early Offer (EO).

Background

This particular environment leverages Cisco Unified Communications Manager (CUCM) with a SIP trunk connection to an ITSP by way of a Cisco Unified Border Element (CUBE) device. The user wanted to enable Early Offer (EO) via the SIP Profile and they couldn't get any calls to establish. However, when they forced the SIP trunk to use a MTP everything worked. 

The question posed to me was why would the MTP work while the SIP profile EO option failed? The implied assumption was that forcing MTP is essentially the same thing as enabling the EO option on the SIP profile. Well, that assumption is not entirely accurate. 

MTP on the SIP Trunk vs. EO on SIP Profile

Support for Early Offer in CUCM was added in CUCM version 8.5(1). I guess it is more accurate to say that Early Offer was enhanced with CUCM 8.5(1). In previous versions of CUCM the SDP offer was only provided in the INVITE when the SIP trunk was provisioned with forced MTP enabled. Note that forcing MTP means every session to/from that SIP trunk requires a MTP. Not ideal.

With the EO enhancements in CUCM 8.5(1), you do not need to insert a MTP in every call flow. While there are scenarios where a MTP may still be invoked, it is not necessarily required. Another difference is that the SDP offer can now present multiple codecs. When nailing up a MTP you could only offer one CODEC. 

It is the multiple codec support with EO on CUCM 8.5(1) and later that is of particular interest in the scenario I was asked about. To illustrate, let's look at the SIP invite messages for two sample sessions.

EO Using MTP on the SIP Trunk

The following trace message is from a configuration where we have configured the CUBE SIP trunk as follows:


  • Assigned a Media Resource Group List with an IOS software MTP resource that supports G711u codec
  • Enabled the option "Media Termination Point Required"
  • Set the MTP preferred Originating Codec to G711ulaw
  • Assigned a device pool with a region configuration that uses the default video bit rate (which is something other than none)

We are playing a call from a registered IP phone to a PSTN destination. 


*Jan 10 05:53:45.104: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+14105551212@11.11.11.1:5060 SIP/2.0
Via: SIP/2.0/TCP 11.11.11.73:5060;branch=z9hG4bK4de786dcbedf1
From: <sip:+12025551212@11.11.11.73>;tag=2235268~67b0b345-b765-4d66-9538-07198f89307d-37136296
To: <sip:+14105551212@11.11.11.1>
Date: Tue, 10 Dec 2013 05:55:39 GMT
Call-ID: d3be4500-2cf18b5b-41800-49d0080a@11.11.11.73
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 3552462080-0000065536-0000005848-1238370314
Session-Expires:  1800
P-Asserted-Identity: <sip:+12025551212@11.11.11.73>
Remote-Party-ID: <sip:+12025551212@11.11.11.73>;party=calling;screen=yes;privacy=off
Contact: <sip:+12025551212@11.11.11.73:5060;transport=tcp>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 212

v=0
o=CiscoSystemsCCM-SIP 2235268 1 IN IP4 11.11.11.73
s=SIP Call
c=IN IP4 11.11.11.1
t=0 0
m=audio 27964 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 

So, we can tell from the presence of the SDP header in the SIP invite that we are using Early Offer (EO) from the CUCM node 11.11.11.73. From the media description line we see that we are using G711 u-law (BTW, here is a good link for RTP/AVP audio and video payload types). 

Simple enough. Assuming the ingress voip dial-peer on the CUBE supports G.711u, we should be in business. In the environment I was looking at, this call setup completed as desired.

EO Using SIP Profile

So, what does the INVITE from CUCM look like when we enable EO on the SIP trunk via the SIP profile? For this configuration we are not forcing MTP. Instead, we are configuring the SIP profile assigned to the trunk to enable Early Offer support for voice and video calls. This parameter is located in the "Trunk Specific Configuration" section of the SIP profile configuration page.

We still have the SIP trunk provisioned to use a device pool that has a region configuration allowing video negotiation from the calling party (a Cisco 9971, IIRC). Once the phone places the call, we see the following INVITE from the CUCM to the CUBE:


*Dec  1 21:15:53.047: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+14105551212@11.11.11.1:5060 SIP/2.0
Via: SIP/2.0/TCP 11.11.11.73:5060;branch=z9hG4bK143c4167a0136
From: <sip:+12025551212@10.8.8.73>;tag=474189~67b0b345-b765-4d66-9538-07198f89307d-37044309
To: <sip:+14105551212@11.11.11.1>
Date: Tue, 10 Dec 2013 21:18:14 GMT
Call-ID: 155ef480-29b1a796-1086d-49d0080a@10.8.8.73
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 0358544512-0000065536-0000001557-1238370314
Session-Expires:  1800
P-Asserted-Identity: <sip:+12025551212@10.8.8.73>
Remote-Party-ID: <sip:+12025551212@11.11.11.73>;party=calling;screen=yes;privacy=off
Contact: <sip:+12025551212@11.11.11.73:5060;transport=tcp>;video;audio
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 702

v=0
o=CiscoSystemsCCM-SIP 474189 1 IN IP4 10.8.8.73
s=SIP Call
c=IN IP4 10.8.224.74
b=TIAS:1984000
b=AS:1984
t=0 0
m=audio 17662 RTP/AVP 104 105 0 8 18 101
a=rtpmap:104 G7221/16000
a=fmtp:104 bitrate=32000
a=rtpmap:105 G7221/16000
a=fmtp:105 bitrate=24000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 30014 RTP/AVP 97
b=TIAS:1920000
a=label:11
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42E01F;packetization-mode=0;max-fs=3601;level-asymmetry-allowed=1
a=imageattr:97 recv [x=[32:1:1280],y=[18:1:720],par=1.7778,q=1.00]
a=content:main
imageattr payload found, specific is 97


Well, this SDP is all about choice. Just like the previous example, the CUCM is using Early Offer by sending the SDP header in the SIP INVITE. The obvious difference is that we are offering a wide variety of audio codecs and we have a media description line offering H.264 video. 

What happens next will depend on a variety of factors. In this particular case, the call flow goes like this:


SIP EO with Video Codec results in SIP 488 Not Acceptable Here


As indicated by the SIP 488 message, some aspect of the SDP offer has been identified as incompatible. In other words, capabilities exchange or media negotiation has failed. Since the SIP 488 message doesn't give specifics about what the ITSP is all worked up about we can take a quick look at the SIP INVITE from the CUBE to get a clue.


*Dec  1 21:15:53.059: //27382/155EF4800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+14105551212@11.11.11.62:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.61:5060;branch=z9hG4bK197C87A
Remote-Party-ID: <sip:2025551212@11.11.11.61>;party=calling;screen=yes;privacy=off
From: <sip:2025551212@11.11.11.61>;tag=3F11C260-C42
To: <sip:8007271212@11.11.11.62>
Date: Tue, 10 Dec 2013 21:15:53 GMT
Call-ID: 982B4DAD-5A0411E3-9AC8EF7C-85248138@11.11.11.61
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0358544512-0000065536-0000001557-1238370314
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
CSeq: 101 INVITE
Timestamp: 1385932553
Contact: <sip:2025551212@11.11.11.61:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 406

v=0
o=CiscoSystemsSIP-GW-UserAgent 449 4632 IN IP4 11.11.11.61
s=SIP Call
c=IN IP4 11.11.11.61
t=0 0
m=audio 16628 RTP/AVP 0 101
c=IN IP4 11.11.11.61
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
m=video 16630 RTP/AVP 119
c=IN IP4 11.11.11.61
b=TIAS:1920000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42E01F;packetization-mode=0;max-fs=3600

The above SIP INVITE is coming from the CUBE to the ITSP. We are sending a SDP header in the invite (EO from the CUBE). We also see that there is a media description line for audio and video. The audio description line is offering a single codec. So, we know that the CUBE is most likely configured with G711u on the various voip dial-peers involved in the call. We also see the video codec offered by the CUCM is being "passed through" to the offer from the CUBE to the ITSP. 

If we know that the ITSP expects G711u, which it does in this case, then we can safely assume that the video codec is the curve ball eliciting the 488 response from the ITSP. 


The Fix

Well, we know that the ITSP doesn't want anything other than voice codecs in the mix. So, we can fix the issue by creating a custom region for the ITSP trunks and make sure that all inter-region associates set video BW to None. This region can be associated with a device pool that is assigned to the ITSP SIP trunk in CUCM. 

Once we apply the changes, everything is as right as rain. 

Conclusion

The obvious lesson here is that there is definitely a difference between nailing up a MTP on a SIP trunk to force EO and enabling EO from the SIP profile. We also demonstrated a way to resolve codec negotiation issues (they are always fun). The most important lesson here is that SIP traces are your friend. Get to know them. Give them nicknames if you want but if you do, be creative - because no one likes boring nicknames.


Thanks for reading. If you have time, post a comment!

8 comments:

  1. Nice!

    I only have a doubt if we can take off the video codec on the CUBE, I'll take a look later.

    thanks for sharing

    Happy 2014!!

    ReplyDelete
  2. I've seen the same when routing to a PRI via an H.323 gateway. The capabilities sent to the carrier resulted in a rejection from the carrier. Moving the gateway into a region with zero voice bandwidth fixed the problem.

    I think the moral of the story is "When routing to a voice carrier, regardless of the protocol, use a region that only allows voice bandwidth."

    ReplyDelete
  3. Hi Bill,

    this all makes sense now. We enabled EO without MTP (to conserve resources) and all of a sudden our SP (Verizon) started rejecting calls. Raising it with them got us to the conclusion that they can only read 16 SDP attributes and we had close to 30 due to the many extra codec ptime and fmtp lines. All within rfc which is why cisco refused to do anything to reduce these (been told there is no way and they themselves were not aware of the MTP vs no-MTP EO difference). Verizon ended up taking 6 months to apply a patch to allow some extra lines which finally resolved the issue.

    would have been good to have had a heads up in the release notes somewhere!

    ReplyDelete
  4. Hi!

    I just wanted to say thank you!
    This helped me very much last night while implementing a new SIP-strunk for telephony access to an ITSP. While having attended a few courses about the Cisco UC platform it's all relatively new when coming from the Tandberg Telepresence world.

    Anyway, we couldn't figure out why it worked with the software MTP enabled but otherwise failed. We didn't get any rejection from our ITSP, they just sent an 200 OK but with only the audio media description. The CUBE/SBC then hung up and showed an error message in it's logs complaining that it didn't get any connection information in the SDP, just because in it's own initiating invite it had sent both audio and video media description in the SDP

    So nice to get this working, thanks!

    ReplyDelete
    Replies
    1. Michel,

      You are most welcome. Thanks for reading and sharing.

      -Bill (@ucguerrilla)

      Delete
  5. Hi Bill,
    I have a problem. video call (9951) from CUCM to CME is not working, though audio is working fine. My guess is MTP is checked in SIP trunk, probably this is the reason. Please advice.... thanks in advance.

    ReplyDelete
  6. Sadia,

    There are a couple of things you should look at.

    First, make sure you have the 9951 phone in CME configured to allow video and use of the camera:

    voice register global
    mode cme
    [...configs...]
    video
    camera
    !
    voice register pool [index]
    [...configs...]
    video
    camera
    !

    Second, you should also look at the voip dial-peer on the CME side. Try allowing SDP pass through at the dial-peer or at the voice service voip context of the configuration:

    dial-p v 199 voip
    [...config...]
    pass-thru content sdp
    !
    OR
    voice service voip
    sip
    [...config...]
    pass-thru content sdp

    Also, you should note that Cisco 9951/9971 phones use RTP payload value of 97 for video. This conflicts with Cisco fax relay ACK. So, if the pass-thru content sdp doesn't solve your problem then you may need to configure the CME voip dial-peer to map the codecs "correctly":

    dial-p v 199 voip
    [...config...]
    rtp payload-type cisco-codec-fax-ack 111 <-- 111 is bogus, do this first
    rtp payload-type cisco-codec-video-h264 97
    !

    HTH

    -Bill (@ucguerrilla)

    ReplyDelete
  7. Had the same issue with dialing certain on-net numbers through the provider. I added a few lines to my sip-profile on the CUBE at the dial-peer to remove video on the way out the door and calls started working.

    request INVITE sdp-header Video-Attribute remove
    request INVITE sdp-header Video-Media modify "m=video(.*)" ""
    request INVITE sdp-header Video-Bandwidth-Info remove

    ReplyDelete