locked
Media bypass with Cisco CUCM 8.6 RRS feed

  • Question

  • Hi all.

    I think I have a little trouble understanding exactly what Media Bypass is supposed to do. I understood it as when a client makes a call out a PSTN gateway, the mediation server would be bypassed and the RTP stream would flow directly from the client to the gateway. I am unsure how this is supposed to work if the call instead is passed to through a SIP trunk to a CUCM server where the gateway is registered. The gateway is only registered at the CUCM, there is no SIP trunk from the mediation server to this gateway, only to the CUCM server.

    When not enabling media bypass I would expect the RTP flow to go from Client - Mediation - CUCM - Gateway (and it does)

    and when media bypass is enabled, I would like the RTP flow to go directly from Client to Gateway.

    However when I enable media bypass in Lync, the RTP flow goes like this: Client - CUCM - Gateway, so the RTP flow only bypasses the mediation server, but still goes through the CUCM server.

     1. Is that the way it's supposed to work? I would've hoped the CUCM server get's bypassed as well, not just the mediation server.

    I have the "MTP required" checkbox set on the SIP trunk on the CUCM side, and I have a suspicion that this MTP is the CUCM itself, which is why the traffic flows to the CUCM server (if the CUCM server itself is the MTP. I think it is, but haven't verified it yet).

     2. Would it help, if the MTP was the gateway instead? Does anyone know if that would enable the direct Client - gateway RTP flow?

    When unchecking the "MTP required" checkbox, the RTP flow still goes from the client to the CUCM server.

    Thanks in advance for any input

    Wednesday, May 1, 2013 8:35 PM

Answers

  • Hi again

    Thanks for the thorough answer.

    As it turned out, I had already provided my own answer in my question. The MTP used in our calls was indeed the CUCM itself, which is why the RTP flow went to that server. Forcing the MTP to be the actual gateway instead made it work.

    So I guess if others read this post, don't worry, it's quite easy. Just make sure there is an MTP resource available, and that it is the gateway. If you don't have an MTP resource somewhere, it seems the call will terminate on the Mediation server, at least that's what I witnessed on inbound calls when the SIP trunk on the CUCM side did not have an MTP resource.

    Thanks again for the answer 

    Sunday, May 5, 2013 11:04 AM

All replies

  • Media bypass refers to removing the Mediation Server from the media path whenever possible for calls whose signaling traverses the Mediation Server. It is not responsible to bypass the CUCM Server.

    MTP can be used to provide SIP Early Offer or DTMF Relay. Lync and CUCM both support RFC 2833 for DTMF Relay, so MTP is generally used for SIP Early Offer. Although Lync does not require Early Offer for call setup, Early Offer is required for media bypass in Lync.

    Here is a document on integrating Microsoft Lync Server 2010 and Cisco Unified Communications Manager. You can find the detailed information about MTP.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, May 3, 2013 7:55 AM
  • Hi again

    Thanks for the thorough answer.

    As it turned out, I had already provided my own answer in my question. The MTP used in our calls was indeed the CUCM itself, which is why the RTP flow went to that server. Forcing the MTP to be the actual gateway instead made it work.

    So I guess if others read this post, don't worry, it's quite easy. Just make sure there is an MTP resource available, and that it is the gateway. If you don't have an MTP resource somewhere, it seems the call will terminate on the Mediation server, at least that's what I witnessed on inbound calls when the SIP trunk on the CUCM side did not have an MTP resource.

    Thanks again for the answer 

    Sunday, May 5, 2013 11:04 AM