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.

  1. I had completely non related problem, but MTP required solved it all the same, thanks 🙂

  2. Tim says:

    Does MTP required force every call across the SIP trunk to use an MTP resource? The reason I ask is it sounds like that will solve some of our issues but am not sure if we have enough MTP resources available to handle the amount of calls across the SIP trunk.

    PS thanks for the posts, a couple of them are literally exactly what I’m dealing with right now and are very helpful.

  3. Aseem says:

    Awesome…All my doubts related to MTP are clear….

  4. Klasie CLoete says:

    From CCM 8.5 upwards this behavior can also be counter by enabling the new feature early offer in the sip profile of a trunk.

    It does not require a MTP to be present.

    Withe this feature enabled the SDP is added to the INVITE message.

  5. USFIT says:

    We had tons of issues with MTP required checked. We would get partial page faxes or no faxes at all through our VG224’s using MGCP in CUCM 8.6.

    We eventually worked with TAC to use Early Offer and check the Send Send Mid Invite option and this helped us with getting inbound calls to transfer w/o getting dropped and since we didn’t require MTP on each call, our faxes started working as expected.

  6. Gennaro says:

    great and usefull info!
    with mtp checked (on sip trunk) and early offer/send send Mid invite (on sip profile), everything is working now…
    thanks a lot guys

  7. Mike says:

    I am using CUCM 8.0.1
    MTP Required is selected
    G729b is chosen as the default codec, in the sip trunk settings.
    My service provider claims that they receive NO SDP from us on invite to the CUBE.
    Is there another option that I have to select in my SIP profile or the SIP trunk config in order to get SDP to send?

  8. Aravin says:

    Hi All,

    We have established a SIP trunk between Nortel PBX and CUCM as below,
    IP level connectivity between Nortel and CUCM and vice versa is fine.
    We are able to ping each other.
    But we are unable to make calls between the 2 systems
    Nortel uses g729 codec and CUCM using g711

    Nortel PBX —>SIP Trunk—>CUCM

    Please help to sort this problem

  9. Mark says:

    You either need to use a common codec between endpoints or transcode one side to a common codec in order for the call setup to be successful.

  10. Kevin says:

    This post helped solve an issue that Cisco TAC spent three months on and could not recommend a resolution besides upgrade to 8.x. We are running CUCM 7.1.5 integrated with Genesys GVP 8.x. If an agent answered a call and then transferred the call back into another IVR, you would hear a strange ‘piano tone’ on transfer, DTMF would not work and the call would disconnect intermittently. Checking that little box and resetting the SIP trunk fixed all three issues!!!!! Thank you so much.

  11. Frantz Desrivieres says:

    Cisco CUCM uses the SIP Offer/Answer model for establishing SIP sessions. Mark is absolutely correct as I too ran into the same issue. As more and more SIP Trunks turn up more calls from company to company go over IP if used by the same SP. The Offer typically defines the media characteristics supported by a device (media streams, codecs, directional attributes, IP address, and even ports to use). The device receiving the Offer sends an Answer in the SDP fields of its SIP response, with its corresponding matching media streams and codec, whether accepted or not, and the IP address and port on which it wants to receive the media streams. Unified CM uses this Offer/Answer model to establish SIP sessions.

    In the simplest terms, an initial SIP Invite sent with SDP in the message body defines an Early Offer, whereas an initial SIP Invite without SDP in the message body defines a Delayed Offer. Got that part.

    In an Early Offer, the session initiator (calling device) sends its capabilities (for example, codecs supported) in the SDP contained in the initial Invite (thus allowing the called device to choose its preferred codec for the session).

    In a Delayed Offer, the calling party does not send its capabilities (like its SDP) I think of early off as who is paying for the check at a restaurant. If you initiate the call with a SDP sent then the calling party is paying the bill if the calling party does not send its SDP the called party is paying the bill.

    Delayed Offer and Early Offer are the two options available to all standards-based SIP switches for media capabilities exchange. Most vendors have a preference for either Delayed Offer or Early Offer, each of which has its own set of benefits and limitations.

    Unified CM Delayed Offer trunks do not require an MTP for the SIP Offer/Answer exchange. For Unified CM Early Offer trunks, SIP Early Offer for voice and video (insert MTP if needed) is the preferred configuration option rather than SIP Early Offer using MTP Required because MTP resources are typically not required to establish calls over an Early Offer trunk.

    Again. Great Post Mark.

  12. Sara Lexington says:

    Great Post Mark. I too had the same issue with my telco and Frantz your post is spot on in regards to how MTP is used for SIP Early offer and Delayed Offer. Great post as well.

  13. Mark says:

    With CUCM 8.6 and higher it is possible to set Early Offer on the SIP Trunk in CUCM, but many telcos still recommend to turn it off. The Acme Packet SBC has always been able to do the Delayed/Early Offer conversion at the edge which is how most carriers prefer to see it handled. CUBE can do the conversion as well.

  14. Frantz Desrivieres says:

    Keep in mind it if your telco does not provide MTP service and your MTP Required option for your SIP Trunk does not work, then you can assign a local RSVP for end to end calls bypassing the telco and also sending a acknowledgement of all SIP provisional responses.

    This option would be within the SIP Profile near the bottom, with radio button of “Fall back to local RSVP” and right under that option you will see SIP Rel1XX Options. Select “Send PRACK if 1xx Contains SDP”. Then test your call to a number that is IP to IP and now your calls should be answered appropriately.

  15. SaifMusa says:

    We had a connection issue between CUCMv6 and Panasonic IPbpx kx-ns500. when establishing a call from CUCM —> IPbpx using sip trunk we only got fastbusy. while calls in the reverse way is successes. after enabling this littel box ( MTP required ) inside call manager everything goes fine.
    Great post Mark, thanks alot

  16. […] SIP Early Offer or MTP required to find remote Codec […]

  17. BitNet says:

    I have intermittent call dropping issues on SIP, when I spoke with Telco they said that we are not sending any codec information on the 3rd INVITE message. They see codec information on 1st and 2nd Invite but not on 3rd INVITE, do you think my checking the MTP and Resetting the trunk will resolve the issue?

    Thanks for your help!