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.
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:
- Inbound INVITE (EO)/200 OK/ACK from Service Provider
- Re-INVITE(EO – a=inactive)/200 OK/ACK from CUCM>CUBE>SP
- i.e Audio Termination
- Re-INVITE(DO)/200 OK/ACK from CUCM>CUBE>SP
- 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:
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/sdpv=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
