CUCM (Call Manager) SIP Trunk and the “Missing” CODEC in SIP INVITE Messages

When configuring a CUCM for SIP Trunk there may not be an SDP listed in the initial SIP Invite as it egresses the network.  If this is the case then the far end SIP endpoint receiving the call from CUCM will try and establish the codec type by including SDP in the 200 OK message sent back to CUCM.  This is the behavior experienced if MTP Required is not selected on a SIP Trunk.  This can impose problems when placing calls to either the PSTN through an ITSP, calls to another CUCM cluster, or another IP PBX platform.  Keep in mind that if you are using an ITSP for PSTN access and you place a call to another IP PBX which is using the same ITSP, you may end up with CUCM/CUBE trying to negotiate directly with the other IP PBX instead of the provider’s equipment without even realizing this is happening since both CUCM and the other system are on the same provider’s network.  Often times an on-net call within the same SIP Trunk provider’s network will render direct media negotiation between the two IP PBX platforms.  Since CUCM only allows one codec to be configured on a SIP Trunk, the codec used on CUCM may not match the other IP PBX.  Without MTP Required selected, CUCM sends a SIP Invite without SDP and it is up to the other system to send its chosen codec in the 200 OK response. Also, the far end IP PBX will dictate the DTMF payload type.  If this is different than CUCM’s SIP Trunk settings the media negotiation will fail and you will hear fast busy.  To avoid this, it is best to select MTP Required so SDP is included with the SIP Invite initiated by CUCM. If the router running CUBE is running IOS 15 you may enable SDP transparency under voice services voip so the SDP is passed as-is to the far end rather than using CPU cycles on the CUBE router to reconstruct the SDP (this would be classified as a back to back user agent function).

The screenshot below is an example of a SIP Invite sent by CUCM (calling party) and there is no SDP since Media Termination Point Required is unchecked on CUCM’s SIP Trunk

The screenshot below shows the far end SIP Endpoint (called number) replying with 200 OK which supplies a preferred codec and sets the DTMF (rtpmap telephone-event) payload value

By selecting MTP Required on CUCM’s SIP Trunk (using software MTP in this case) all SIP Invites sent by CUCM include the supported codec for the SIP Trunk and the DTMF payload type

Taking a closer look at these captures it is easy to see that when CUCM doesn’t include SDP the far end wants to negotiate G729 even though CUCM is configured to use G711 on the SIP Trunk.  There is no way for the far end system to know that CUCM only supports G711 so it sends the codec that it wants to use. This creates a media negotiation failure between the two systems and the call is aborted.  By enabling MTP Required on CUCM’s SIP Trunk the Invite includes G711 in the SDP which alleviates the media negotiation failure between the two systems since the far end system has the ability to support G711.

Adjusting Cisco IOS SIP Invite Timers and Retry Values (sip-ua) for Failure Recovery

Posted: 9th February 2011 by Mark in Cisco

1

Cisco IOS contains a configurable object called SIP User Agent (sip-ua) where several different SIP settings may be altered from their default behavior.  The focus here are the settings for SIP Retry Invite and SIP Timers and why it makes sense to change the default settings on the router if calls should reroute over another path if the SIP Trunk is unavailable. We are looking at this scenario from the perspective of the router running CME and the CME users dialing the CUCM site 1XXX. Through the use of dial-peers calls will first be routed over the data network to reach the SIP Trunk configured on CUCM.  In the event the SIP Trunk in unavailable the call should automatically reroute over the secondary dial peer which in this case is a PRI, but may also be another SIP Trunk or H323 Gateway or Gatekeeper.

The issue with SIP dial peers is the sip-ua has a default SIP Invite Retry value of 6. If the first Invite does not receive a response then the counter in between each newly generated Invite increases thus causing an even longer delay between each new Invite. This will cause

unacceptable post dial delay and more than likely users will abandon the call before it is rerouted over the PRI. The following are the appropriate dial peers to support SIP as the primary call path using 4 digit dialing. If the SIP Trunk is in an outage state the router will use the PRI and automatically prefix the full string of dialed digits required by the Telco that owns the PRI circuit.

dial-peer voice 1000 voippreference 1destination-pattern 1…$session protocol sipv2session target sip-servervoice-class codec 1dtmf-relay rtp-nteno vad

dial-peer voice 1001 potspreference 2destination-pattern 1…$ < 1 is explicitly matched in this pattern so 1 must be added again in the prefixport 0/0/0:15prefix 14082021

sip-uaretry invite 2timers trying 150sip-server dns:cucm-hq.markholloway.com

The first thing to note is the SIP Trying timer, which is reflective of SIP 100 Trying (try debug ccsip messages to see this) has been reduced to 150 milliseconds. This is a more than adequate time frame for CUCM to reply to a SIP Invite.  The next item that has been changed is the number of retry invites.  Under this configuration there will be a total of three SIP Invites generated by CME.  The intial Invite plus two retries if the first invite does not receive a response within 150 ms.  Given this set of values – if CUCM is either unreachable or the CUCM SIP Trunk is down – the CME router will route the call over the PRI in less than one second from the time the first Invite was sent and users should not experience post dial delay. This is a significant improvement over the default behavior where the default SIP Timer value is 1500 ms (1.5 seconds) and six Invite retries.