In this section:
Modified: for 6.2.2
The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases. Refer to the SBC SIP Transparency Implementation Guide for additional information.
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 SBC as-is to the far end.
SDP Transparency functionality includes:
When SDP Transparency is enabled, all IP Signaling Profile SDP-related flags are overridden.
For additional audio/video support topics, refer to:
The SBC Core 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 SBC to suppress 183 response without SDP:
suppress183For3xxRedirectResponse
suppress183WithoutSdp
% 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.
Suppress 183 Response Without SDP Flags
Suppress 183 for 3xx Redirect Response | Suppress 183 without SDP | Action |
---|---|---|
Enabled | Enabled |
|
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).
The SBC supports passing the list of received audio codecs in the SDP offer to PSX in the policy request. The SBC also passes the received audio codec information list as received in the ingress SDP to PSX in the policy request.
The SBC 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 SBC accounting records, populating the “Egress External Accounting Data” field for STOP and ATTEMPT CDR records.
This feature is not applicable when the SBC is configured for ERE mode.
Do not use deriveFromOtherLeg
when configuring H.323 or SIP trunk groups to use INVITEs with no SDPs.
sendAllAllowedCodecsForLateMediaInviteOrReInvite
flag controls the handling of audio codecs that the SBC offers in response to a late media INVITE or Re-INVITE without SDP for transcoded calls.For pass-through calls, the SBC always offers a subset of the codecs advertised by the associated peer. The SBC Offer codec list is classified as a subset because the list can be subjected to codec policy filters.
Example 1: G711 pass-through call
If a re-INVITE with no SDP is received on egress, the SBC 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
If a re-INVITE with no SDP is received on egress, by default, the SBC generates an offer for AMR. If the “Send All Allowed Codecs For Late Media Invite Or Re-Invite” flag is enabled then the SBC 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.
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.
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.
The SBC SWe Cloud does not support Late Media pass-through calls over GW-GW.
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 SBC supports ANAT formatting within the SDP offer to facilitate both an IPv4 and IPv6 address types. In addition, the SBC 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 SBC 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.
Interactive Connectivity Establishment (ICE) is a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/answer model. ICE uses the Session Traversal Utilities for NAT (STUN) protocol and its extension Traversal Using Relay NAT (TURN). ICE uses STUN and TURN servers to overcome network address translation issues that can occur when an endpoint is situated behind a NAT device. ICE solves the NAT issues for media streams. Support of the ICE specification is required by WebRTC (WRTC) endpoints.
The SBC is capable of acting as an ICE-Lite agent to allow the WRTC endpoints to connect to the existing VoIP network through the SBC using the DTLS-SRTP protocol. While acting as an ICE-Lite endpoint, the SBC interconnects with endpoints that have either ICE-Lite or full-ICE implementations. ICE-Lite is a lite version of the ICE protocol, which is defined to exchange media with each other. The interconnect with ICE-Lite end points is only for the purpose of IPv4 to IPv6 inter-working and no NAT traversal procedures are supported for ICE-Lite to ICE-Lite.
SBC implementation for ICE can be used with endpoints that are connected to the SBC through Sonus WRTC gateway and also WRTC endpoints connected from a third-party WRTC Gateway thereby presenting ICE in their SDP.
As SBC is not required to act as an ICE client (it is not located behind a NAT in current deployment models), the initial support for ICE is limited to the SBC acting as an ICE-Lite endpoint.
ICE-Lite key points:
STUN message processing:
Reachable IP address: an ICE-Lite agent has a reachable public IP address and can work with other agents that use ICE and are behind the NAT.
The ICE-Lite procedure starts with the offerer discovering all the IP port where it is reachable. These are known as local “candidates”. The “candidates” can be any or all of the following:
STUN is used to discover the Server Reflexive and Peer reflexive addresses on the NAT and TURN is used to discover the Relay candidates on the TURN relay. After the local candidates are discovered, the offerer (Full ICE Agent) sends them in the session description protocol (SDP) offer to the remote endpoints. The remote end point (SBC) discovers its own local candidates (which are only host candidates) and sends in the answer SDP to the offerer.
Once the offer/answer exchange is completed, Full ICE Agent takes the role of ICE controlling agent and performs connectivity check between the candidate pairs (from local candidate to remote candidate) by sending the STUN messages. SBC acts as controlled agent and responds to the STUN requests. Based on the success/failure of the connectivity check, a candidate pair is selected by the controlling agent to exchange the media and it sends a connectivity check on the selected pair with USE-CANDIDATE attribute to let the controlled agent know about the selected pair. The connectivity check may lead to the discovery of new local candidates due to the presence of Restricted or Symmetric NAT. These local candidates are also included in the procedure and are known as “Peer Reflexive Addresses”. SBC being a controlled ICE-Lite agent cuts thru the media after receiving USE-CANDIDATE on all components of the media stream (for example, if RTP and RTCP are required for a stream then media is only cut-through when USE-CANDIDATE is received for both RTP and RTCP).
The controlling agent sends an updated offer by using the selected local candidate in the default IP port of the media line and controlled agent (SBC) respond by sending its local candidate in the default IP port of the media line to complete the ICE-Lite procedure. The Ice-lite procedure can be restarted by the Full ice agent using ICE Restart procedures, if the Media ports changed during a call.
SBC 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.
The SBC 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 SBC accepts offers that express bundling with a single bundle. A bundle may have one or more streams.
Stream
Bundle Only
The SBC accepts offers that include bundled streams with the bundle-only attribute set.
The bundling of streams is negotiated using the "a=group:BUNDLE" attribute at the session level:
If the peer is able to support the bundle:
The following is an example for OFFER and ANSWER mechanism.
OFFER
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
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
Bundling is only allowed when security is configured to be relayed, and:
The SBC 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.
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:
For the ANSWER:
The RTP contains two components:
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 with no need for the SBC to inter-work with any media attributes.
The SBC Core 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.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.The SBC supports RTCP-Mux for the following features/functionaltiy:
RTCP bandwidth requirements do not change with the use of RTCP-Mux. The SBC transmits bandwidth attributes (RR/RS) as per the existing configuration.
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:
RTCP-Mux to non-RTCP-Mux Interworking
Inter-working Scenarios | Offer from Ingress | Offer to Egress | Answer from Egress | Answer to Ingress | RTCP 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) |
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.
With an upgrade to SBC 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 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.
The SBC 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.
The configurations for the existing flags associated with the flag sdp100relIwkForPrack
, and the supported call flow scenarios, are summarized below:
Parameter configurations for supported call flows
rel100Support flag on the ingress Trunk Group | rel100Support flag on the egress Trunk Group | lateMediaSupport flag on the ingress Trunk Group | sdp100relIwkForPrack flag on the egress Trunk Group | Relevant Call Flow Scenario |
---|---|---|---|---|
enabled | disabled | enabled | passthru | enabled | Scenario 1 |
enabled | disabled | enabled | convert | enabled | Scenario 2 |
disabled | enabled | passthru | enabled | Scenario 3 |
Scenario 1: When PRACK is supported only on the ingress leg of the call, and the lateMediaSupport
flag is set to passthru
Asymmetric PRACK Interworking - Supported Call Flow Scenario 1
Scenario 2: When PRACK is supported only on the ingress leg of the call, and the lateMediaSupport
flag is set to convert
Asymmetric PRACK Interworking - Supported Call Flow Scenario 2
Scenario 3: When PRACK is supported only on the egress leg of the call, and the lateMediaSupport
flag is set to passthru
Asymmetric PRACK Interworking - Supported Call Flow Scenario 3