Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Add_workflow_for_techpubsAUTH2AUTH1REV5REV6REV3REV4REV1REV2

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

SDP Transparency

Session Description Protocol (SDP) is a set of rules defining how multimedia sessions are set up to allow all end points to effectively participate in the session.

Interactive Connectivity Establishment (ICE) is a protocol used by systems that cannot determine their own transport address as seen from the remote end, but that can provide several possible alternatives (see ICE-Lite Support below). The SDP transparency feature allows SDP and ICE media to pass through the 

Spacevars
0product
as-is to the far end.

SDP Transparency functionality includes:

  • All unknown SDP attributes are transparently passed.
  • All unknown components of known SDP attributes are dropped.
  • Any unknown audio codecs are dropped.
  • All known and unknown video codecs are transparently passed.

Note

When SDP Transparency is enabled, all IP Signaling Profile SDP-related flags are overridden.

For additional audio/video support topics, refer to:

Suppressing 183 Response Without SDP

The

Spacevars
0series4
supports suppressing the 183 response without SDP upon receipt of 3xx Redirect response for reasons such as:

  • An endpoint perceives a 183 without SDP response as being an extra message resulting in unexpected behavior.

  • Endpoints that behave irregularly upon receipt of a 183 without SDP response prior to cut-through.

Two IP Signaling Profile ingress flags are available to configure the

Spacevars
0product
 to suppress 183 response without SDP:

  • suppress183For3xxRedirectResponse

  • suppress183WithoutSdp

Code Block
languagenone
titleCLI Syntax
% set profiles signaling ipSignalingProfile <SIP profile name> ingressIpAttributes flags suppress183For3xxRedirectResponsek <disable | enable>
% set profiles signaling ipSignalingProfile <SIP profile name> ingressIpAttributes flags suppress183WithoutSdp <disable | enable>

The following table describes the effects of enabling/disabling these flags.

Caption
0Table
1Suppress 183 Response Without SDP Flags

Suppress 183 for 3xx Redirect Response

Suppress 183 without SDP

Action

Enabled

Enabled

  • If 183 without SDP is due to 3xx redirect response, it is suppressed due to “Suppress 183 for 3xx Redirect Response” flag.

  • If 183 without SDP is triggered for reason other than 3xx redirect response, it is suppressed due to “Suppress 183 without SDP ” flag.

Enabled

Disabled

3xx redirect response triggers 183 without SDP, and hence is suppressed

Disabled

Enabled

A '183 without SDP triggered due to 3xx redirect response' (or for any other reason) is suppressed.

Disabled

Disabled

Existing behavior persists.

For configuration details, refer to Ingress IP Attributes - SIP - CLI or Ip Signaling Profile - Ingress Ip Attributes (EMA).

Passing Audio Codecs in SDP Offer

The 

Spacevars
0product
supports passing the list of received audio codecs in the SDP offer to PSX in the policy request. The
Spacevars
0product
also passes the received audio codec information list as received in the ingress SDP to PSX in the policy request.

The

Spacevars
0product
uses the modified calling number returned by the PSX in the policy response in formatting the egress call leg request. The P-CDR information is written onto the
Spacevars
0product
accounting records, populating the “Egress External Accounting Data” field for STOP and ATTEMPT CDR records.

Note

This feature is not applicable when the

Spacevars
0product
is configured for ERE mode.

Late Media INVITE or Re-INVITE Support

Include Page
DeriveFromOtherLeg limitation
DeriveFromOtherLeg limitation

Div
classexcerptdiv
Excerpt

The sendAllAllowedCodecsForLateMediaInviteOrReInvite flag controls the handling of audio codecs that the

Spacevars
0product
offers in response to a late media INVITE or Re-INVITE without SDP for transcoded calls.

  • When  this flag is disabled for transcoded calls (default behavior), the
    Spacevars
    0product
    offers the codec used for transcoding on the leg.
  • When the flag is enabled for transcoded calls, the
    Spacevars
    0product
    offers multiple codecs which include:
    • The subset of the codecs that the associated peer supports.
    • The transcoded codecs that the associated DSP channel supports. This includes the codec currently being used for transcoding.

For pass-through calls, the

Spacevars
0product
always offers a subset of the codecs advertised by the associated peer. The
Spacevars
0product
Offer codec list is classified as a subset because the list can be subjected to codec policy filters.

Example 1: G711 pass-through call

  1. Ingress Offer: G711, G729
  2. Egress Offer: G711, G729, AMR, G726
  3. Ingress Answer: G711
  4. Egress Answer: G711

If a re-INVITE with no SDP is received on egress, the

Spacevars
0product
 generates an offer for G711, G729. The G726 and AMR are not offered because the call is marked as a relay call with DSP removed, and hence the transcoded codecs.

Example 2: G711 to AMR transcoded call

  1. Ingress Offer: G711, G729
  2. Egress Offer: G711,G729, AMR, G726
  3. Egress Answer: AMR
  4. Ingress Answer: G711

If a re-INVITE with no SDP is received on egress, by default, the

Spacevars
0product
 generates an offer for AMR. If the “Send All Allowed Codecs For Late Media Invite Or Re-Invite” flag is enabled then the
Spacevars
0product
 generates a codec list of G711,G729, AMR, and G726 in the Offer.

Refer to Common IP Attributes - SIP - CLI or Common Ip Attributes - Flags (EMA) for configuration details.

ANAT Support

Alternative Network Address Types (ANAT) semantics for the SDP grouping framework allows the expression of alternative network addresses (e.g. different IP versions) for a particular media stream. This ability is useful in environments with both IPv4-only hosts and IPv6-only hosts.

The 

Spacevars
0product
supports ANAT formatting within the SDP offer to facilitate both an IPv4 and IPv6 address types. In addition, the
Spacevars
0product
allows a configured address type preference whereby the user can configure which IP version takes precedence when multiple IP version types are supported. If the
Spacevars
0product
receives an ANAT offer and only a single IP version is supported on the received interface, that IP version is used regardless of the configured IP version type preference. Refer to SIP Trunk Group - Media - CLI or SIP Trunk Group - Media for configuration details.

AnchorIce-LiteIce-LiteICE-Lite Support Include PageICE-Lite_SupportICE-Lite_Support

Bundling of Streams

Spacevars
0product
supports bundling of various streams (audio/video) over the same IP/port pair using a SDP grouping framework extension named BUNDLE. The BUNDLE is used with the SDP OFFER/ANSWER mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media (bundled media) associated with multiple SDP media streams ("m=" lines ). The address:port combination used for sending bundled media may be the same as the BUNDLE address, used to receive bundled media, depending on whether symmetric RTP is used.

The SDP media-level attribute, "bundle-only", is parsed and used to identify that specific media is only used if bundled, and resides within a BUNDLE group. The "bundle-only" attribute is a property attribute with no value.

Note

The

Spacevars
0product
can accept a mixture of bundled and unbundled streams, but currently only single bundle is supported.

The use of a BUNDLE group and a BUNDLE address also allows the usage of a single set of Interactive Connectivity Establishment (ICE) candidates for multiple "m=" lines.
If RTP/RTCP multiplexing is used, the same address:port combination is used for all RTP and RTCP packets.

Single-bundle

The

Spacevars
0product
 accepts offers that express bundling with a single bundle. A bundle may have one or more streams.

Stream

  • A stream can be tagged as bundle-only and have a port set to 0.
  • The policers for the stream which represents the bundle reflect the total bandwidth for all streams within the bundle.
  • Only relay scenarios are supported, any interworking causes the streams to unbundle.

Bundle Only

The

Spacevars
0product
 accepts offers that include bundled streams with the bundle-only attribute set.

  • Offers with "m=" lines tagged as bundle-only with the port set to 0.
  • Non-compliant offers which associate bundle-only with a non-zero port, the "m=" line is also accepted; the stream is treated as a bundle-only stream.
  • Media attributes received with a bundle-only stream offer are handled considering that the stream is present and output in the outbound offer. (media codecs, fmtp options)

Bundle Group

The bundling of streams is negotiated using the "a=group:BUNDLE" attribute at the session level:

  • The OFFER contains the BUNDLE attribute followed by a list of streams which are part of the BUNDLE.
  • The OFFER contains unique address:port combinations for each stream as the peer may not support bundling the streams.

If the peer is able to support the bundle:

  • The ANSWER contains the BUNDLE attribute.
  • The ANSWER contains the same address:port combination for all streams within the bundle.

OFFER and ANSWER

The following is an example for OFFER and ANSWER mechanism.

OFFER

Code Block
languagenone
v=0
o=alice 2890844526 2890844526 IN IP4 10.32.241.3
s= 
c=IN IP4 10.32.241.3 
t=0 0 
a=group:BUNDLE audio video 
m=audio 10000 RTP/AVP 0  
a=mid:audio
a=rtpmap:0 PCMU/8000 
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 
m=video 10002 RTP/AVP 31 32
a=mid:video 
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 

ANSWER

Code Block
languagenone
v=0 
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 
s= 
c=IN IP4 biloxi.example.com 
t=0 0 
a=group:BUNDLE audio video 
m=audio 20000 RTP/AVP 0  
a=mid:audio
a=rtpmap:0 PCMU/8000 
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 
m=video 20000 RTP/AVP 32 
a=mid:video 
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 

RTP and RTCP Multiplexing

The

Spacevars
0product
 allows relaying multiplexed RTP and RTCP traffic.

Within a BUNDLE group, the offerer and answerer must enable RTP/RTCP multiplexing for the RTP-based media associated with the BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port combination is used for sending all RTP and RTCP packets associated with the BUNDLE group.  Each endpoint sends the packets towards the BUNDLE address of the other endpoint. The same address:port combination may be used for receiving RTP and RTCP packets.

The SBC has an existing flag for late media INVITEs or Re-INVITES to specify which codecs are included in the SDP offer, but the behavior differs based on whether the base call is a pass-through or transcoded call. For pass-through calls the codecs offered do not include those supported for transcoding. For certain scenarios the originator of the INVITE/Re-INVITE must know the full capabilities even for a pass-through call. This feature addresses the pass-through case where the full set of codecs is needed.

When the sendSBCSupportedCodecsForLateMediaReInvite  flag is enabled, the SBC sends all the codecs supported on a particular leg as an SDP OFFER in the 200 OK response to a late media Re-INVITE. The OFFER sent in the 200 OK contains all the pass-through and transcodable codecs supported on that leg. This behavior is applicable only for late media Re-INVITE requests. The flag does not have any impact on late media INVITE requests.

For example, an additional codec might be needed if one of the original parties in a pass-through two-way call attempts to bridge in a third party. For both transcoded and pass-through calls, when the sendSBCSupportedCodecsForLateMediaReInvite flag is enabled, the SBC responds in the 200 OK to a late media Re-INVITE request with the full set of codecs the SBC supports, including those available through transcoding. This flag takes precedence over the sendAllAllowedCodecsForLateMediaInviteOrReInvite flag and the sendOnlyPreferredCodec flag in the IP Signaling profile. The SIP trunk group media flag lateMediaSupport must be set to convert for the behavior enabled by the sendSBCSupportedCodecsForLateMediaReInvite flag to apply.

Refer to Common IP Attributes - SIP - CLI or Common IP Attributes - Flags (EMA) for configuration details.

Late Media Pass-through Calls over GW-GW

The SBC supports Late Media pass-through calls over GW-GW and also, handles Late Media (offer less) re-INVITE on either side. This functionality is supported when the flag lateMediaSupport is configured as passthru.

Code Block
set addressContext <addressContex name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> media lateMediaSupport passthru

When the flag lateMediaSupport is set as passthru, the Late Media INVITE/re-INVITE received on that leg is relayed to the other leg.

Info
titleNote

The SBC SWe Cloud does not support Late Media pass-through calls over GW-GW.


ANAT Support

Alternative Network Address Types (ANAT) semantics for the SDP grouping framework allows the expression of alternative network addresses (e.g. different IP versions) for a particular media stream. This ability is useful in environments with both IPv4-only hosts and IPv6-only hosts.

The 

Spacevars
0product
supports ANAT formatting within the SDP offer to facilitate both an IPv4 and IPv6 address types. In addition, the
Spacevars
0product
allows a configured address type preference whereby the user can configure which IP version takes precedence when multiple IP version types are supported. If the
Spacevars
0product
receives an ANAT offer and only a single IP version is supported on the received interface, that IP version is used regardless of the configured IP version type preference. Refer to SIP Trunk Group - Media - CLI or SIP Trunk Group - Media for configuration details.

Anchor
Ice-Lite
Ice-Lite
ICE-Lite Support

Include Page
ICE-Lite_Support
ICE-Lite_Support

Bundling of Streams

Spacevars
0product
supports bundling of various streams (audio/video) over the same IP/port pair using a SDP grouping framework extension named BUNDLE. The BUNDLE is used with the SDP OFFER/ANSWER mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media (bundled media) associated with multiple SDP media streams ("m=" lines ). The address:port combination used for sending bundled media may be the same as the BUNDLE address, used to receive bundled media, depending on whether symmetric RTP is used. The sdpAttributesSelectiveRelay  flag must be enabled for bundling.

The SDP media-level attribute, "bundle-only", is parsed and used to identify that specific media is only used if bundled, and resides within a BUNDLE group. The "bundle-only" attribute is a property attribute with no value.

Note

The

Spacevars
0product
can accept a mixture of bundled and unbundled streams, but currently only single bundle is supported.

The use of a BUNDLE group and a BUNDLE address also allows the usage of a single set of Interactive Connectivity Establishment (ICE) candidates for multiple "m=" lines.
If RTP/RTCP multiplexing is used, the same address:port combination is used for all RTP and RTCP packets.

Single-bundle

The

Spacevars
0product
 accepts offers that express bundling with a single bundle. A bundle may have one or more streams.

Stream

  • A stream can be tagged as bundle-only and have a port set to 0.
  • The policers for the stream which represents the bundle reflect the total bandwidth for all streams within the bundle.
  • Only relay scenarios are supported, any inter-working causes the streams to unbundle.

Bundle Only

The

Spacevars
0product
 accepts offers that include bundled streams with the bundle-only attribute set.

  • Offers with "m=" lines tagged as bundle-only with the port set to 0.
  • Non-compliant offers which associate bundle-only with a non-zero port, the "m=" line is also accepted; the stream is treated as a bundle-only stream.
  • Media attributes received with a bundle-only stream offer are handled considering that the stream is present and output in the outbound offer. (media codecs, fmtp options)

Bundle Group

The bundling of streams is negotiated using the "a=group:BUNDLE" attribute at the session level:

  • The OFFER contains the BUNDLE attribute followed by a list of streams which are part of the BUNDLE.
  • The OFFER contains unique address:port combinations for each stream as the peer may not support bundling the streams.

If the peer is able to support the bundle:

  • The ANSWER contains the BUNDLE attribute.
  • The ANSWER contains the same address:port combination for all streams within the bundle.

OFFER and ANSWER

The following is an example for OFFER and ANSWER mechanism.

OFFER

Code Block
languagenone
v=0
o=alice 2890844526 2890844526 IN IP4 10.32.241.3
s= 
c=IN IP4 10.32.241.3 
t=0 0 
a=group:BUNDLE audio video 
m=audio 10000 RTP/AVP 0  
a=mid:audio
a=rtpmap:0 PCMU/8000 
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 
m=video 10002 RTP/AVP 31 32
a=mid:video 
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 

ANSWER

Code Block
languagenone
v=0 
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com 
s= 
c=IN IP4 biloxi.example.com 
t=0 0 
a=group:BUNDLE audio video 
m=audio 20000 RTP/AVP 0  
a=mid:audio
a=rtpmap:0 PCMU/8000 
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 
m=video 20000 RTP/AVP 32 
a=mid:video 
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 

Interactions with Security

Bundling is only allowed when security is configured to be relayed, and:

  • DTLS-SRTP (and DTLS-SCTP for data) is relayed.
  • SDES SRTP is relayed

Limitations

  • Bundling can only be relayed and not inter-worked.
  • Configuration for LI or a call requiring transcoding, DTMF or security termination is unbundled.
  • Bundling is not supported over the GW protocol.

RTP and RTCP Multiplexing

The

Spacevars
0product
 allows relaying multiplexed RTP and RTCP traffic.

Within a BUNDLE group, the offerer and answerer must enable RTP/RTCP multiplexing for the RTP-based media associated with the BUNDLE group.

When RTP/RTCP multiplexing is enabled, the same address:port combination is used for sending all RTP and RTCP packets associated with the BUNDLE group.  Each endpoint sends the packets towards the BUNDLE address of the other endpoint. The same address:port combination may be used for receiving RTP and RTCP packets.

  • The
    Spacevars
    0product
     allows relay of multiplexed RTP and RTCP traffic only when the rtcp-mux is supported on both sides of the call.
  • The "a=rtcp-mux" attribute negotiates multiplexing when RTCP is enabled on both sides of the call.
  • The rtcp-mux attribute takes precedence over the "a=rtcp:" attribute when it has to accept SDPs from the peer.
  • When rtcp-mux is used within a bundle it must be enabled for all streams in a bundled or disabled for all.

Interactions with ICE

Using bundling of media streams and the support of RTCP multiplexing ensures that only a single ICE transaction on one port is required. This limits the occurrence of NAT traversal issues and reduces the time needed to establish a call.

For the OFFER:

  • The ICE data is unique for each stream.
  • A candidate is included for RTCP in the initial OFFER and for RTP.
  • A bundle-only "m=" line does not include ICE candidate or ufrag/pwd.

For the ANSWER:

  • The ICE data matches the chosen master stream.
  • A single ICE candidate line for the RTP component is only included.

RTCP Multiplexing to Non-RTCP Multiplexing Inter-working

The RTP contains two components:

  • a data transfer protocol and
  • an associated Real-time Control Protocol (RTCP).

With the increased use of Network Address Port Translation (NAPT), using separate UDP ports to transport RTP and RTCP has become problematic as maintaining multiple NAT bindings can be costly. To overcome these scenarios, the 

Spacevars
0product
supports RTP and RTCP flows on a single port to ease NAT traversal. This functionality is known as RTP and RTCP Multiplexing or RTCP-Mux.

Prior to 6.1.0 release, the

Spacevars
0product
supported RTCP-Mux in pass-through scenarios where the 
Spacevars
0product
was relaying media end to end. This support was sufficient for some limited use cases, such as WRTC-to-WRTC call scenarios where the endpoints terminated media encryption with no need for the 
Spacevars
0product
 to inter-work with any media attributes. 

The 

Spacevars
0series4
 is enhanced to support inter-working between RTCP-Mux to non-RTCP-Mux as well as in the reverse direction. In this scenario, both egress and ingress packet Service Profiles (PSPs) either support RTCP-Mux or fallback to transport RTP and RTCP streams using separate ports. The rtcpMux flag is added to the PSP to configure RTCP-Mux.
Multiexcerpt
MultiExcerptNameRTCP Mux

When RTP interception is triggered on an RTCP-Mux call (for example, lawful intercept), the 

Spacevars
0product
 forks the RTP and RTCP streams to a single port towards the mediation server. If the intercept is performed in an RTCP-Mux session, the stream sent towards the mediation server is also multiplexed with RTP and RTCP sent over the same port.

The
Spacevars
0product
supports RTCP-Mux for the following features/functionaltiy:

  • Multimedia calls
  • Monitoring calls
  • Both direct media and OMR call scenarios
  • DTLS and SRTP scenarios (irrespective of whether the encryption protocol terminates at the 
    Spacevars
    0product
    or is relayed transparently end-to-end)
  • Multiplexing RTCP and inter-working with non-RTCP Mux for both pass-through (with or without "RTCP termination" enabled) and transcoded calls
  • Bundled streams for WRTC calls
  • Tones and Announcements
  • Using SRTP and SRTCP (This is supported in both the cases of SRTP pass-through and SRTP to RTP inter-working.)

RTCP bandwidth requirements do not change with the use of RTCP-Mux. The 

Spacevars
0product
transmits bandwidth attributes (RR/RS) as per the existing configuration.

Info
titleNote

The rtcpMux flag is visible only when the rtcp control is enabled on the PSP.

 

The following table describes the RTCP-Mux to non-RTCP-Mux inter-working scenarios for offer/answer:

Caption
0Table
1RTCP-Mux to non-RTCP-Mux Interworking
Inter-working ScenariosOffer from IngressOffer to EgressAnswer from EgressAnswer to IngressRTCP Flow Ingress Port(s)  Egress Port(s)

RTCP-Mux enabled on both PSPs

 

 

 

 

“a=rtcp-mux"“a=rtcp-mux”“a=rtcp-mux”“a=rtcp-mux”(P1)→(P1)

“a=rtcp-mux”

“a=rtcp-mux"

No Mux

“a=rtcp-mux”(P1)→(P1,P2)

No Mux

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

(P1,P2)→(P1)

No Mux

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux enabled on ingress only

 

“a=rtcp-mux”

No Mux

No Mux

“a=rtcp-mux”

(P1)→(P1,P2)

No Mux

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux enabled on egress only

 

 

 

 

“a=rtcp-mux”

“a=rtcp-mux”

“a=rtcp-mux”

No Mux 

(P1,P2)→(P1)

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

No Mux

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

(P1,P2)→(P1)

No Mux

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux disabled on both PSPs

 

“a=rtcp-mux”

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)

No Mux

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)

In the offer, ““a=rtcp-mux”” is signaled in the SDP in all the media "m=" lines for which RTP/RTCP mux is required. If the answerer wishes to multiplex RTP and RTCP on a single port, it must generate an answer containing an "“a=rtcp-mux”" attribute for each media where it uses RTP and RTCP-Mux. If the answerer rejects the usage of RTP/RTCP-Mux, it must not associate an SDP "rtcp-mux" or SDP "rtcp" attribute in the answer. Based on the port number, the answerer uses the next higher (odd) destination port number for sending RTCP packets associated with the corresponding "m=" line towards the offerer.

RTCP-Mux to non-RTCP-Mux Inter-working for ICE Calls

When using ICE where RTP and RTCP are sent on separate ports, the 

Spacevars
0product
performs connectivity checks for each component. Some of these connectivity checks can be avoided by multiplexing RTP and RTCP on the same port, thus reducing the ICE overhead.

When the 

Spacevars
0product
offers the “a=rtcp-mux” attribute, it generates the offer that contains "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line (provided that the sendRtcpPortInSdp flag is enabled) to designate a fallback port for RTCP in case the answerer does not support RTP and RTCP-Mux. This response is performed for each media stream when RTP and RTCP-Mux is desired.

Info
titleNote

With an upgrade to

Spacevars
0product
software supporting RTCP-Mux, an existing user running WRTC calls must enable the control rtcpMux on both the PSPs to maintain backward compatibility. This is required when the sessions transparently relay DTLS and RTCP-Mux attributes using DTLS-SRTP relay control (dtlsSrtpRelay) in the PSP and the flag sdpAttributesSelectiveRelay is enabled.

Once the RTCP-Mux is negotiated, the subsequent reINVITE(s) sent from the 

Spacevars
0product
to the same endpoint does not re-negotiate the RTCP-Mux. However, the RTCP-Mux is re-negotiated with the target endpoints for the redirect calls or for the call transfer. The RTCP-Mux is also negotiated on a per leg basis, when the endpoint triggers the negotiation or the SDP change includes an address change. Thus, the 
Spacevars
0product
never restarts ICE on its own and waits for the endpoint to trigger an ICE restart. If a new media stream is added in an existing session, ICE is negotiated on that stream. If the existing streams are updated for codec changes, ICE is not re-negotiated. The RTCP-Mux re-negotiation is consistent for the 
Spacevars
0product
both for the ICE and the non-ICE scenarios.

Limitation

  • The
    Spacevars
    0product
    does not support pass-through for the rtcp-mux.

Asymmetric PRACK Inter-working

The 

Spacevars
0product
supports PRACK functionalities either on the ingress or on the egress leg. This enhancement is denoted by the phrase "Asymmetric PRACK Interworking". The flag sdp100relIwkForPrack supports Asymmetric PRACK Inter-working for the late media calls.

Note
iconfalse

To configure PRACK on both the legs, enable the existing flag endToEndPrack. For more information on endToEndPrack, refer to Flags - CLI.

Anchor
Supported Call Flow Scenarios
Supported Call Flow Scenarios

Supported Call Flow Scenarios:

The configurations for the existing flags associated with the flag sdp100relIwkForPrack, and the supported call flow scenarios, are summarized below:

Caption
0Table
1Parameter configurations for supported call flows
rel100Support flag on the ingress Trunk Grouprel100Support flag on the egress Trunk GrouplateMediaSupport flag on the ingress Trunk Groupsdp100relIwkForPrack flag on the egress Trunk GroupRelevant Call Flow Scenario
enableddisabled | enabledpassthruenabledScenario 1
enableddisabled | enabledconvertenabledScenario 2
disabledenabledpassthruenabledScenario 3

Info
iconfalse

For more information on the existing flags lateMediaSupport and rel100Support, refer to the following pages:

 

Anchor
1
1
Scenario 1: When PRACK is supported only on the ingress leg of the call, and the lateMediaSupport flag is set to passthru
Caption
0Figure
1Asymmetric PRACK Interworking - Supported Call Flow Scenario 1

Image Added

 

Anchor
2
2
Scenario 2: When PRACK is supported only on the ingress leg of the call, and the lateMediaSupport flag is set to convert
Caption
0Figure
1Asymmetric PRACK Interworking - Supported Call Flow Scenario 2

Image Added

 

Anchor
3
3
Scenario 3: When PRACK is supported only on the egress leg of the call, and the lateMediaSupport flag is set to passthru
Caption
0Figure
1Asymmetric PRACK Interworking - Supported Call Flow Scenario 3

Image Added

Multiple m-lines Support in SDP

The SBC can be configured to process multiple audio m-lines, or a combination of audio and image m-lines, in SDP. Multiple m-lines (media streams) is needed in call recording scenarios or to support some types of fax transmissions.

When support is enabled on both the ingress and egress legs of a call when multiple m-lines are present, the SBC determines a core stream among the m-lines. The core stream is the first m-line within the SDP which contains a codec supported by the SBC. The SBC applies the media parameters specified by merging together the ingress and egress Packet Service Profile (PSP) parameters, such as transcoding policy, to the core stream. For all other non-core audio or image media streams the SBC allocates resources for the stream and transparently relays the m-lines. If the first stream containing a supported codec is for fax (m=image), then the SBC treats the call as a fax and relays all other media streams.

Support for multiple m-lines is enabled or disabled using the multipleAudioStreamsSupport option within media parameters in SIP trunk groups.

If you enable multiple m-line support, you also have the option to enable a separate media option in SIP trunk groups which disables all SRTP (SAVP) streams present in incoming SDP. This enables deployments to disallow SRTP on the ingress call leg, but not on the egress leg. Enabling the option disallowSrtpStream means that for all SAVP streams in the incoming SDP, the SBC sets the port to zero, thus disabling the SAVP stream. The SBC handles any other streams in the SDP according to the multiple m-line handling just described. If the incoming SDP contains only one or more SAVP streams, the call is rejected. The option disallowSrtpStream can only be enabled when the multipleAudioStreamsSupport option is enabled.

The multiple m-line support applies only to cases where the m-lines present consist of all audio streams or a combination of audio and image media streams. The SBC maintains its default behavior if the non-core streams are video or other non-audio, non-image streams. Multiple m-line support must be enabled on both ingress and egress SIP Trunk Groups for the feature to apply.

When the multipleAudioStreamsSupport option is disabled, the SBC default behavior takes place.

For more information, refer to:

  • The
    Spacevars
    0product
     allows relay of multiplexed RTP and RTCP traffic for bundled and unbundled streams.
  • The "a=rtcp-mux" attribute negotiates multiplexing when RTCP is enabled on both sides of the call and the call is a pass-through call.
  • The rtcp-mux attribute takes precedence over the "a=rtcp:" attribute when it has to accept SDPs from the peer.
  • When rtcp-mux is used within a bundle it must be enabled for all streams in a bundled or disabled for all.

The above requirement also covers audio calls; the

Spacevars
0product
 supports RTP and RTCP multiplexing by relaying the rtcp-mux attribute for audio pass-through only flows. Pass-through only flows are flows where transcoding is not possible (no transcode codecs are a part of the outgoing offer).

For rtcp-mux to work on audio only calls, sdpAttributesSelectiveRelay must be enabled.

Interactions with ICE

Using bundling of media streams and the support of RTCP multiplexing ensures that only a single ICE transaction on one port is required. This limits the occurrence of NAT traversal issues and reduces the time needed to establish a call.

For the OFFER:

  • The ICE data is unique for each stream.
  • A candidate is included for RTCP in the initial OFFER and for RTP.
  • A bundle-only "m=" line does not include ICE candidate or ufrag/pwd.

For the ANSWER:

  • The ICE data matches the chosen master stream.
  • A single ICE candidate line for the RTP component is only included.

Interactions with Security

Bundling and/or multiplexing is only allowed when security is configured to be relayed, and:

  • DTLS-SRTP (and DTLS-SCTP for data) is relayed.
  • SDES SRTP is relayed
Note

If the

Spacevars
0product
performs security termination for any stream the call is forced to be unbundled.

Limitations

  • Multiple bundles are not currently supported
  • Bundling and rtcp-mux can only be relayed, not interworked.
  • Configuration for LI or a call requiring transcoding, DTMF or security termination is unbundled.
  • Bundling is not supported over the GW protocol.

RTCP Multiplexing to Non-RTCP Multiplexing Interworking

The Real-time Transport Protocol (RTP) contains two components:

  • a data transfer protocol and
  • an associated Real-time Control Protocol (RTCP).

With the increased use of Network Address Port Translation (NAPT), using separate UDP ports to transport RTP and RTCP has become problematic as maintaining multiple NAT bindings can be costly. To overcome these scenarios, the SBC supports RTP and RTCP flows on a single port to ease NAT traversal. This functionality is known as RTP and RTCP Multiplexing or RTCP-Mux.

Prior to 6.1.0 release, the SBC supported RTCP-Mux in pass-through scenarios where the SBC was relaying media end to end. This support was sufficient for some limited use cases, such as WRTC to WRTC call scenarios, where the endpoints terminated media encryption and the SBC need not inter-work with any media attributes. The SBC is enhanced to support inter-working between RTCP-Mux to non-RTCP-Mux as well as in the reverse direction. In this scenario, both egress and ingress packet Service Profiles (PSPs) either support RTCP-Mux or fallback to transport RTP and RTCP streams using separate ports. A new control rtcpMux is added to the PSP to configure RTCP-Mux.

The SBC supports RTCP-Mux for the following features/functionaltiy:

  • Multimedia calls
  • Monitoring calls
  • Both direct media and OMR call scenarios
  • DTLS and SRTP scenarios (Irrespective of whether the encryption protocol terminates at the SBC or is relayed transparently end to end)
  • Multiplexing RTCP and inter-working with non-RTCP Mux for both pass-through (with or without "RTCP termination" enabled) and transcoded calls
  • Bundled streams for WRTC calls
  • Tones and Announcements
  • Using SRTP and SRTCP (This is supported in both the cases of SRTP pass-through and SRTP to RTP inter-working)

When RTP interception is triggered on an RTCP-Mux call (for example, lawful intercept), the SBC forks the RTP and RTCP streams to a single port towards the mediation server. If the intercept is performed in an RTCP-Mux session, the stream sent towards the mediation server is also multiplexed with RTP and RTCP sent over the same port.

RTCP bandwidth requirements do not change with the use of RTCP-Mux. The SBC transmits bandwidth attributes (RR/RS) as per the existing configuration.

Note

The rtcpMux flag is visible only when the rtcp control is enabled on the PSP.

The following table describes the RTCP-Mux to non-RTCP-Mux inter-working scenarios for offer/answer:
Caption
0Table
1RTCP-Mux to non-RTCP-Mux Interworking
Inter-working ScenariosOffer from IngressOffer to EgressAnswer from EgressAnswer to IngressRTCP Flow Ingress Port(s)  Egress Port(s)

RTCP-Mux enabled on both PSPs

 

 

 

 

“a=rtcp-mux"“a=rtcp-mux”“a=rtcp-mux”“a=rtcp-mux”(P1)→(P1)

“a=rtcp-mux”

“a=rtcp-mux"

No Mux

“a=rtcp-mux”(P1)→(P1,P2)

No Mux

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

(P1,P2)→(P1)

No Mux

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux enabled on ingress only

 

“a=rtcp-mux”

No Mux

No Mux

“a=rtcp-mux”

(P1)→(P1,P2)

No Mux

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux enabled on egress only

 

 

 

 

“a=rtcp-mux”

“a=rtcp-mux”

“a=rtcp-mux”

No Mux 

(P1,P2)→(P1)

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

No Mux

“a=rtcp-mux”

“a=rtcp-mux”

No Mux

(P1,P2)→(P1)

No Mux

“a=rtcp-mux”

No Mux

No Mux

(P1,P2)→(P1,P2)

RTCP-Mux disabled on both PSPs

 

“a=rtcp-mux”

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)

No Mux

No Mux

No Mux

No Mux

(P1,P2)→(P1,P2)
In the offer, ““a=rtcp-mux”” is signaled in the SDP in all the media "m=" lines for which RTP/RTCP mux is required. If the answerer wishes to multiplex RTP and RTCP on a single port, it must generate an answer containing an "“a=rtcp-mux”" attribute for each media where it uses RTP and RTCP-Mux. If the answerer rejects the usage of RTP/RTCP-Mux, it must not associate an SDP "rtcp-mux" or SDP "rtcp" attribute in the answer. Based on the port number, the answerer uses the next higher (odd) destination port number for sending RTCP packets associated with the corresponding "m=" line towards the offerer.

RTCP-Mux to non-RTCP-Mux Inter-working for ICE Calls

When using ICE where RTP and RTCP are sent on separate ports, the SBC performs connectivity checks for each component. Some of these connectivity checks can be avoided by multiplexing RTP and RTCP on the same port, thus reducing the ICE overhead.

When the SBC offers the “a=rtcp-mux” attribute, it generates the offer that contains "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line (provided that the sendRtcpPortInSdp flag is enabled) to designate a fallback port for RTCP in case the answerer does not support RTP and RTCP-Mux. This response is performed for each media stream when RTP and RTCP-Mux is desired.

Note

With an upgrade to the SBC software which supports RTCP-Mux, an existing user running WRTC calls must enable the new control rtcpMux on both the PSPs to maintain backward compatibility. This is required when the sessions transparently relay DTLS and RTCP-Mux attributes using DTLS-SRTP relay control (dtlsSrtpRelay) in the PSP and the flag sdpAttributesSelectiveRelay is enabled.

Once the RTCP-Mux is negotiated, the subsequent reINVITE(s) sent from the SBC to the same endpoint does not re-negotiate the RTCP-Mux. However, the RTCP-Mux is re-negotiated with the target endpoints for the redirect calls or for the call transfer. The RTCP-Mux is also negotiated on a per leg basis, when the endpoint triggers the negotiation or the SDP change includes an address change. Thus, the SBC never restarts ICE on its own and waits for the endpoint to trigger an ICE restart. If a new media stream is added in an existing session, ICE is negotiated on that stream. If the existing streams are updated for codec changes, ICE is not re-negotiated. The RTCP-Mux re-negotiation is consistent for the SBC both for the ICE and the non-ICE scenarios.

Pagebreak