In this section:

Overview

When RTP proxy is enabled and properly configured, SIP signaling is processed by the SBC Edge and the audio packets are switched through the SBC without being processed by one of the SBC's DSPs. 

The RTP Proxy function enables endpoints on either side of the SBC to negotiate codecs and media capabilities directly between themselves. In RTP Proxy, the SBC is unaware and does not need to support the communications codecs.

This feature is customizable through SIP Signaling Groups and Call Routing.

Only SIP-to-SIP calls can use the RTP Proxy feature. SIP-to-telephony and telephony-to-SIP calls require the use of a DSP.

How Proxy Mode Works

In RTP Proxy Mode, RTP packets between endpoints are switched internally within the SBC: the SBC updates IP address and port numbers, but the remainder of the RTP packet is switched unmodified from the input leg to the output leg.

A combination of the Signaling Group and Call Route configuration determines whether DSP or RTP Proxy mode will be used. As an example:

RTP Proxy mode is used for a call if:

  • Both the ingress and egress Signaling Groups have Audio/Fax Steam Proxy Mode - Enabled
  • The call route is configured for Audio/Fax Stream Mode Proxy or Proxy Preferred Over DSP

DSP mode is used for a call if:

  • One of the Signal Groups has Audio/Fax Stream Proxy Mode - Enabled
  • The other Signaling Group has Audio/Fax Stream Proxy Mode - Disabled
  • Both have Audio/Fax Stream DSP Mode - Enabled
  • The call route is configured for Audio/Fax Stream Mode - DSP Preferred Over Proxy

In the configuration above, setting the call route Audio/Fax Stream Mode to Proxy would create an unworkable combination. Configuring Audio/Fax Stream Mode to Proxy means that only Proxy mode is valid for that call route. Since one Signaling Group is set to DSP only, the call route will be skipped.

Overall, the configuration of the Signaling Group’s Audio/Fax Stream Proxy and DSP Modes controls which modes are available to the endpoints.  The call route controls which modes can be used for calls between specific endpoints.

When to Use RTP Proxy Mode

  • Use RTP Proxy Mode when the two endpoints use a codec which is not supported by the SBC. 
    • Proxy Mode permits the endpoints to directly negotiate the codec between themselves without the SBC interfering. In other words, if the endpoints would be able to make a direct call to each other, then RTP Proxy Mode should permit the endpoints to make a call through the SBC.

  • Proxy Mode may also be used in cases where the SBC does support the codecs used by the two endpoints.
    • Calls in Proxy Mode will not receive transcoding, ringback, or music-on-hold support from the SBC.  These features require a DSP.

It is advisable to use DSP mode when the call codec is one which is supported by the SBC.  Doing so will decrease installation and interoperability problem.

Do not use Proxy Mode for Lync calls.  Lync calls require that the SBC provide ringback.

 

Advantages of Using RTP Mode

  • Allows the SBC to establish calls for codecs that it does not support.

  • Improves the calls per second (CPS) of SBC 1000/2000.

  • RTP Proxy calls use use no DSPs or SDP licenses.

  • Improves call quality.

  • Reduces internal call processing.

DSP vs. Proxy in the Call Route

  • Call routes will default the Audio/Fax Stream Mode setting to DSP.  This mode should be used unless you have a specific reason for not using the SBC’s on-board DSP resources.

  • Configure the call route Audio/Fax Stream Mode to Proxy if:
    • If the SBC does not have DSPs. 
    • The endpoints share a common codec that the SBC does not support. 
    • It may also be used for situations where the endpoints and the SBC all support a common codec, but for specific reasons, use of the on-board DSP resources is not desired. Be aware that the endpoints or upstream devices are responsible for providing ringback.

  • Use the call route Proxy Preferred over DSPconfiguration:
    • In an environment where the Signaling Groups have a mixture of Audio/Fax Stream Mode configurations and the RTP Proxy mode is the desired preference. This will permit the call route to prefer the Proxy mode over DSP mode based upon the combination of Stream Mode settings in the ingress and egress Signaling Groups.

  • Use the call route DSP Preferred over Proxy configuration:

    • In an environment where the Signaling Groups have a mixture of Audio/Fax Stream Mode configurations and DSP mode is the desired preference. This will permit the call route to prefer the DSP mode over  the Proxy mode based upon the combination of Stream Mode settings in the ingress and egress Signaling Groups.

      Note that if inbound and outbound SG don’t have common media mode the call will be rejected in any media mode of operation defined in the routing entry.

  • Once the media mode is determined, the call will be set to either DSP or RTP Proxy mode.  The media mode cannot be changed once it has been initially established.

  • If RTP Proxy mode is desired, RTP Proxy Preferred mode should be used in configurations where a call route can be used by different call types (calls that are not exclusively SIP-to-SIP).

Limitations

  • The voice metrics will be collected only in the DSP mode; audio metrics will not be collected for any call routed in the Proxy or Direct Media mode.

     

  • Dynamic switching between DSP and Proxy modes is not supported. The RTP mode cannot be changed on a call once it has been selected.

  • RTP Proxy does not provide transcoding. Codec mismatches between endpoints will result in call failure.

  • All Forked responses are sent to the caller. Endpoints may not handle it very well.

  • In RTP Proxy, the SRTP mandatory/optional, crypto keys, RTP payload packet size, order of codecs, are all negotiated by the endpoints.

  • Calls will not work between endpoints that cannot create direct calls. (e.g., RTP Proxy does not work between Lync client and Tenor).

  • Transferred calls are not supported.

  • Endpoint-to-endpoint issues, such as one-way audio and no audio, usually manifest as call failures.

  • In RTP Proxy, there is no support for local ring back, music on hold, etc. (these require a DSP).

  • RTP Proxy does not support communications between RTP and SRTP endpoints. RTP to SRTP requires DSP transcoding.

 

  • No labels