SDP Support

In this section:

SDP Transparency

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

Interactive Connectivity Establishment (ICE) is a protocol used by systems that cannot determine their 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

Unable to show "metadata-from": No such page "_space_variables"

as-is to the far end.

SDP Transparency functionality includes:

Passing all SDP attributes transparently
Dropping all unknown components of known SDP attributes.
Dropping any unknown audio codecs.
Transparently passing all known and unknown video codecs.

When SDP Transparency is enabled, the

Unable to show "metadata-from": No such page "_space_variables"

overrides all IP Signaling Profile SDP-related flags.

For additional audio/video support topics, refer to:

Suppressing 183 Response Without SDP

The

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

to suppress 183 response without SDP:

suppress183For3xxRedirectResponse
suppress183WithoutSdp

CLI 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.

Suppress 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, its suppression is due to “Suppress 183 for 3xx Redirect Response” flag. If 183 without SDP is triggered for reason other than 3xx redirect response, its suppressed is 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 suppression of 3xx redirect response' (or for any other reason).
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

Unable to show "metadata-from": No such page "_space_variables"

supports passing the list of received audio codecs in the SDP offer to PSX in the policy request. The

Unable to show "metadata-from": No such page "_space_variables"

also passes the received audio codec information list as received in the ingress SDP to PSX in the policy request.

The

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

accounting records, populating the “Egress External Accounting Data” field for STOP and ATTEMPT CDR records.

Note

This feature is not applicable when the

Unable to show "metadata-from": No such page "_space_variables"

is configured for ERE mode.

Late Media INVITE or Re-INVITE Support

Do not use deriveFromOtherLeg when configuring H.323 or SIP trunk groups to use INVITEs with no SDPs.

The sendAllAllowedCodecsForLateMediaInviteOrReInvite flag controls the handling of audio codecs that the

Unable to show "metadata-from": No such page "_space_variables"

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

When this flag is in disabled state for transcoded calls (default behavior), the
Unable to show "metadata-from": No such page "_space_variables"
offers the codec used for transcoding on the leg.
When this flag is in enabled state for transcoded calls, the
Unable to show "metadata-from": No such page "_space_variables"
offers multiple codecs which include:
- The subset of the codecs that the associated peer supports.
- The transcoded codecs that the associated DSP channel supports which includes the codec currently used for transcoding.

For pass-through calls, the

Unable to show "metadata-from": No such page "_space_variables"

always offers a subset of the codecs advertised by the associated peer. The

Unable to show "metadata-from": No such page "_space_variables"

Offer codec list is classified as a subset because the list applies the codec policy filters.

Example 1: G711 pass-through call

Ingress Offer: G711, G729
Egress Offer: G711, G729, AMR, G726
Ingress Answer: G711
Egress Answer: G711

If the

Unable to show "metadata-from": No such page "_space_variables"

receives the re-INVITE with no SDP on egress, it generates an offer for G711, G729. The

Unable to show "metadata-from": No such page "_space_variables"

does not offer G726 and AMR obecause the call is marked as a relay call with DSP removed, and hence the transcoded codecs.

Example 2: G711 to AMR transcoded call

Ingress Offer: G711, G729
Egress Offer: G711,G729, AMR, G726
Egress Answer: AMR
Ingress Answer: G711
If the
Unable to show "metadata-from": No such page "_space_variables"
receives an re-INVITE with no SDP on egress, by default, the
Unable to show "metadata-from": No such page "_space_variables"
generates an offer for AMR. If the “Send All Allowed Codecs For Late Media Invite Or Re-Invite” flag is in enabled state, then the
Unable to show "metadata-from": No such page "_space_variables"
generates a codec list of G711,G729, AMR, and G726 in the offer.

The SBC has an existing flag for late media INVITEs or Re-INVITES which specifies the included codecs 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, the

Unable to show "metadata-from": No such page "_space_variables"

might need an additional codec 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

Unable to show "metadata-from": No such page "_space_variables"

responds in the 200 OK to a late media Re-INVITE request with the full set of codecs the

Unable to show "metadata-from": No such page "_space_variables"

supports, including those available through transcoding. This flag takes precedence over the sendAllAllowedCodecsForLateMediaInviteOrReInvite flag and the sendOnlyPreferredCodec flag in the IP Signaling profile. You must set the SIP trunk group media flag lateMediaSupport to "convert" to apply the behavior enabled by the sendSBCSupportedCodecsForLateMediaReInvite flag.

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-INVITEs on either side. This functionality is supported when the flag lateMediaSupport is configured as passthru.

set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> media lateMediaSupport passthru

When the flag lateMediaSupport is set as passthru, a late media INVITE/re-INVITE received on one leg is relayed to the other leg.

Note

The cloud-based SBC SWe 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 (for example. different IP versions) for a particular media stream. This ability is useful in environments with both IPv4-only hosts and IPv6-only hosts.

The

Unable to show "metadata-from": No such page "_space_variables"

supports ANAT formatting within the SDP offer to facilitate both an IPv4 and IPv6 address types. In addition, the

Unable to show "metadata-from": No such page "_space_variables"

allows a configured address type preference where the user can configure the IP version that takes precedence when multiple IP version types are supported. If the

Unable to show "metadata-from": No such page "_space_variables"

receives an ANAT offer and only a single IP version is supported on the received interface, then it uses that IP version regardless of the configured IP version type preference. Refer to SIP Trunk Group - Media - CLI or SIP Trunk Group - Media for configuration details.

ICE-Lite Support

Overview

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.

Note

Implement SBC for ICE with endpoints connected to the SBC through the Ribbon WRTC gateway, as well as WRTC endpoints connected from a third-party WRTC Gateway to present ICE in their SDP.

Note

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:

- Decoding received messages on media port
- Validating the received messages
- Authenticating the received messages
- Encoding outgoing STUN Response messages and sending on allocated media port
- Encrypting outgoing STUN as per the configured username/password

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.

ICE-Lite Implementation

The ICE-Lite procedure starts with the offerer discovering all IP ports where it is reachable.These are known as local “candidates”. The “candidates” can be any or all of the following:

Host candidates (Local IP port)
Server Reflexive Candidates (External IP port allocated by NAT)
Relay candidates (IP port on a media relay)

Use STUN to discover the Server Reflexive and Peer reflexive addresses on the NAT. Use TURN 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 completes, the Full ICE Agent assumes 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. The SBC acts as a controlled agent, and responds to the STUN requests. Based on the success/failure of the connectivity check, the controlling agent selects a candidate pair to exchange the media, and 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”. The SBC, as a controlled ICE-Lite agent, cuts through the media after receiving USE-CANDIDATE on all components of the media stream (for example, if RTP and RTCP are required for a stream, the 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 the controlled agent (SBC) responds by sending its local candidate in the default IP port of the media line to complete the ICE-Lite procedure. Use the Full ICE agent (using the ICE Restart procedures) to restart the Ice-lite procedure if the Media ports change during a call.

The ICE-Lite procedure starts with the offerer discovering all IP ports where it is reachable

Bundling of Streams

The

Unable to show "metadata-from": No such page "_space_variables"

supports bundling of various streams (audio/video) over the same IP/port pair using an SDP grouping framework extension named BUNDLE. The

Unable to show "metadata-from": No such page "_space_variables"

uses thee BUNDLE 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. Enable the the sdpAttributesSelectiveRelay flag 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

Unable to show "metadata-from": No such page "_space_variables"

accepts a mixture of bundled and unbundled streams; however, only single bundled streams are currently 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 using RTP/RTCP multiplexing, use the same address:port combination for all RTP and RTCP packets.

Single-bundle

The

Unable to show "metadata-from": No such page "_space_variables"

accept offers that express bundling with a single bundle. A bundle may have one or more streams.

Stream

You can tag a stream as 'bundle-only' with the 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

Unable to show "metadata-from": No such page "_space_variables"

accepts offers including bundled streams with the bundle-only attribute set, including:

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
Unable to show "metadata-from": No such page "_space_variables"
treats the stream as a bundle-only stream.
The
Unable to show "metadata-from": No such page "_space_variables"
handles media attributes received with a bundle-only stream offer, taking into consideration the stream is present, as well as the output in the outbound offers (For example, media codecs and fmtp options).
The handles the media attributes received with a bundle-only stream offer taking into consideration that the stream is present and output in the outbound offers. For example; media codecs, fmtp options)

Bundle Group

The

Unable to show "metadata-from": No such page "_space_variables"

negotiates the bundling of streams 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 a unique address:port combinations for each stream as the peer may not support bundling the streams.

If the peer supports 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

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

Interactions with Security

Bundling is only allowed when security is relayed, and:

DTLS-SRTP and DTLS-SCTP for data are relayed
SDES SRTP is relayed

Limitations

You can only relay (not interwork) bundling.
Configuration for LI or a call requiring transcoding, DTMF, or security termination is unbundled.
Bundling is not supported over the gateway protocol.

RTP and RTCP Multiplexing

The

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

uses the same address:port combination to send all RTP and RTCP packets associated with the BUNDLE group. Each endpoint sends the packets towards the BUNDLE address of the other endpoint and uses the same address:port combination to receive RTP and RTCP packets.

The
Unable to show "metadata-from": No such page "_space_variables"
allows relay of multiplexed RTP and RTCP traffic only when it supports the rtcp-mux 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 the
Unable to show "metadata-from": No such page "_space_variables"
uses rtcp-mux within a bundle, rtcp-mux is enabled for all streams in a bundled or disabled for all.

Interactions with ICE

Using media stream bundling and 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 the RTP.
A bundle-only "m=" line does not include an ICE candidate or ufrag/pwd.

For the ANSWER:

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

RTCP Multiplexing to Non-RTCP Multiplexing Interworking

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 considering maintaining multiple NAT bindings is costly.To overcome these scenarios, the

Unable to show "metadata-from": No such page "_space_variables"

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 the 6.1.0 release, the

Unable to show "metadata-from": No such page "_space_variables"

supported RTCP-Mux in pass-through scenarios where the

Unable to show "metadata-from": No such page "_space_variables"

relays media in an end-to-end scenario. 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

Unable to show "metadata-from": No such page "_space_variables"

to interwork with any media attributes.

The

Unable to show "metadata-from": No such page "_space_variables"

is enhanced to support interworking 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 the

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

supports RTCP-Mux with the following functionality:

Multimedia calls
Monitoring calls
Both direct media and OMR call scenarios
DTLS and SRTP scenarios (irrespective of whether the encryption protocol terminates at the
Unable to show "metadata-from": No such page "_space_variables"
or relays transparently end-to-end)
Multiplexing RTCP and interworking 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 ( The
Unable to show "metadata-from": No such page "_space_variables"
supports this in both the cases of SRTP pass-through and SRTP to RTP interworking.)

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

Unable to show "metadata-from": No such page "_space_variables"

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 interworking scenarios for offer/answer:

RTCP-Mux to non-RTCP-Mux Interworking

Interworking 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)
RTCP-Mux enabled on ingress only	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)
RTCP-Mux disabled on both PSPs	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 whichit requires RTP/RTCP mux. 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 interworking for ICE Calls

When using ICE where the

Unable to show "metadata-from": No such page "_space_variables"

sends the RTP and RTCP are sent on separate ports, it checks the connectivity 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

Unable to show "metadata-from": No such page "_space_variables"

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 it desire the RTP and RTCP-Mux.

Note

With an upgrade to

Unable to show "metadata-from": No such page "_space_variables"

software that supports 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

Unable to show "metadata-from": No such page "_space_variables"

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 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

Unable to show "metadata-from": No such page "_space_variables"

never restarts ICE on its own and waits for the endpoint to trigger an ICE restart. If it add the new media stream in an existing session, ICE is negotiated on that stream. If the existing streams are updated for codec changes, ICE is not re-negotiated.

RTCP-Mux re-negotiation is consistent for both for the

Unable to show "metadata-from": No such page "_space_variables"

ICE and non-ICE scenarios.

Limitation

The
Unable to show "metadata-from": No such page "_space_variables"
does not support pass-through for the rtcp-mux.

Asymmetric PRACK interworking

The

Unable to show "metadata-from": No such page "_space_variables"

supports PRACK functionalities either on the ingress or on the egress leg and denotes it with the phrase "Asymmetric PRACK Interworking". The flag sdp100relIwkForPrack supports Asymmetric PRACK interworking for the late media calls.

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

Supported Call Flow Scenarios:

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

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

lateMediaSupport:
- SIP Trunk Group - Media - CLI
- SIP Trunk Group - Media
rel100Support:
- SIP Trunk Group - Signaling - CLI
- SIP Trunk Group - Signaling

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

Multiple m-lines Support in SDP

The

Unable to show "metadata-from": No such page "_space_variables"

can process multiple audio m-lines, or a combination of audio and image m-lines, from the SDP. The

Unable to show "metadata-from": No such page "_space_variables"

uses multiple m-lines (media streams) in call recording scenarios or several fax transmission types.

When the

Unable to show "metadata-from": No such page "_space_variables"

supports both the ingress and egress legs of a call when multiple m-lines are present, the

Unable to show "metadata-from": No such page "_space_variables"

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 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 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 disabling 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

Unable to show "metadata-from": No such page "_space_variables"

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

Unable to show "metadata-from": No such page "_space_variables"

rejects the call. 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

Unable to show "metadata-from": No such page "_space_variables"

maintains its default behavior if the non-core streams are video or other non-audio, non-image streams. To apply this feature, enable the multiple m-line support on both ingress and egress SIP Trunk Groups.

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

For more information, refer to:

Offer-Answer Timer Configuration

In specific call scenarios, the

Unable to show "metadata-from": No such page "_space_variables"

treats the Offer-Answer (OA) as a MODIFY Offer-Answer cycle, but the peer treats it as an INITIAL Offer-Answer cycle. According to RFC 3261, the response from the peer is expected within 300 seconds. The

Unable to show "metadata-from": No such page "_space_variables"

, however, assumes a 20-second response, and therefore any delay in the response from the peer which exceeds of 20 seconds causes call failure.

Currently, the internal Offer-Answer (OA) timer value is fixed and cannot be configured. To overcome this limitation, the

Unable to show "metadata-from": No such page "_space_variables"

is enhanced with a new parameter offerAnswerTimer to configure this OA timer.

Note

During switchover, the active calls use the old timer value at the start of the call. After switchover, the new calls use the latest configured value.

Call flow

The following figure depicts the call message flow diagram in the Offer-Answer cycle:

Message Flow Diagram in Offer-Answer Cycle

Space shortcuts

Page tree

SDP Transparency

Suppressing 183 Response Without SDP

Passing Audio Codecs in SDP Offer

Late Media INVITE or Re-INVITE Support

ANAT Support

ICE-Lite Support

Overview

ICE-Lite Implementation

Bundling of Streams

Bundle Group

OFFER and ANSWER

Interactions with Security

Limitations

RTP and RTCP Multiplexing

Interactions with ICE

RTCP-Mux to non-RTCP-Mux interworking for ICE Calls

Limitation

Supported Call Flow Scenarios:

Multiple m-lines Support in SDP

Offer-Answer Timer Configuration

Call flow