Tag Archives: mtp

Forcing MTP Killed the Mid-Call

There’s a common misconception with Cisco SIP trunking that the desperate “Forced MTP” will always solve no audio, one-way audio, DTMF inter-working and every other media negotiation failure under the sun. This is unfortunately not always the case.

forced-mtp

On a deployment completed quite a while back, we faced a no-audio media issue in 9.1.x (determined to be due to CSCup07303) where I initially raised the white flag due to time constraints and forced the MTP on the SIP Trunk.  The issue arose due to a UCCX re-direct for an after-hours call flow.  Not the topic for discussion here, but just some background information (more on this later).


Fast forward 5 months, and 3 remote sites were deployed for the same system, following a CBO SIP Trunking solution via the Campus site.  After deploying the 3rd site, the client complained that inbound calls were failing and I was asked to investigate.

I reviewed the call flow to find a classic INVITE/UPDATE/Re-INVITE scenario, with CUCM ending the call with a BYE due to a frustrated end user hanging up (Reason: Q.850;cause=16).

The call flow was as follows:

  1. Inbound INVITE (EO)/200 OK/ACK from Service Provider
  2. Re-INVITE(EO – a=inactive)/200 OK/ACK from CUCM>CUBE>SP
    1. i.e Audio Termination
  3. Re-INVITE(DO)/200 OK/ACK from CUCM>CUBE>SP
    1. A classic CUCM Delayed Offer MOH media negotiation attempt

Unfortunately at this point the call had already failed, with many SIP messages still to follow (for another day) before the final BYE.

So, what is actually going on here?!?  Let’s look at the SIP Ladder:

inactive-media

The offending message is:

May 27 08:57:04.713: //1396205/8DF8940DA2FF/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.3:5060;branch=z9hG4bK5C8CBBB5
From: <sip:12341234567@172.16.1.3>;tag=815B2478-2382
To: <sip:22334455667@172.16.1.2>;tag=SDjuthc01-nz5qnrc7wqej3qxa.o
Call-ID: SDjuthc01-780d708b807543c356c407ad79c35b25-a848bn0
CSeq: 101 INVITE
Timestamp: 1432717024
Contact: Anonymous <sip:2345234523@172.16.1.2:5060;transport=udp>
Server: Sippy
Portasip-3264-action: answer 2
Content-Length: 245
Content-Type: application/sdp

v=0
o=Sippy 2031015826430718550 1 IN IP4 172.16.1.2
s=-
t=0 0
m=audio 62848 RTP/AVP 18 96
c=IN IP4 172.16.1.2
b=AS:8
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=ptime:20
a=maxptime:20

Root cause?

An RFC non-compliant upstream softswitch, sending a=inactive instead of a delayed media offer – in this case not conforming to 14.2 of RFC 3261.

A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session.

I raised a case with the service provider, who simply couldn’t resolve the problem, as the offending device was actually on an upstream inter-connect with another provider.  Chaos ensued explaining this to the client.

Luckily, Cisco has some methods to support this non-compliance – introduce Send sendrecv in Mid-Call INVITE

When Send “sendrecv” in mid call INVITE is enabled, this feature inserts an MTP into the media path between the calling and calling devices, allowing the media connection to be disconnected between the Unified CM device and the MTP, while establishing and maintaining media between the MTP and the held device with a=sendrecv. On call resumption, the MTP is removed from the media path.

Unfortunately, this fix meant I also had to downgrade MOH support to use G729 as well:

This feature addresses the mid-call Delayed Offer INVITE issue for audio direction, but it cannot resolve the issue of a device responding with its last used codec rather than the full list of all supported codecs. This issue can be problematic in cases where a codec change is required on re-establishment of media, such as placing a G.729 call on hold and connecting it to a music on hold source where G711 is preferred.

So.. why am I blaming the forced MTP?

Well, when it’s forced into the call to begin with, yes… it will result in early offer, but its always in the call, and media is therefore always set up and terminated with every mid-call Re-INVITE – via a=inactive SDP.  The end result is that setting Send “sendrecv” in mid call INVITE on the SIP Profile had absolutely no effect – I had to disable MTP on the trunk, set Early Offer from the SIP Profile adn finally set the sendrecv param on the SIP Profile as well.

#dontcalltac

Advertisements
Tagged , , , , ,

DTMF Interworking and the MTP

I came across this a while back when deep diving MTP when preparing for the lab.  I’ve pretty much got it down now, but I keep coming back to it as a reference point.

http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118708-technote-dtmf-00.html

I really struggled a lot with this at the CCNP level.  Not sure about MTPs conceptually?  Look no further!

Tagged , , , ,
Collaboration Engineer

All things Technology - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications

ccieme

my personal journey to ccie collaboration

Striving for greatness

Thoughts on emerging tech, open source, and life

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center

Warcop

Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626

Darkroomstory

Photography by Manos,

afterthenumber

Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.