Page History

% set profiles signaling ipSignalingProfile <SIP profile name> ingressIpAttributes flags suppress183For3xxRedirectResponsek <disable | enable>
% set profiles signaling ipSignalingProfile <SIP profile name> ingressIpAttributes flags suppress183WithoutSdp <disable | enable>

Passing Audio Codecs in SDP Offer

The 

The

Late Media INVITE or Re-INVITE Support

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

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

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 

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.

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.

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 

Anchor
Ice-Lite Ice-Lite

ICE-Lite Support

Bundling of Streams

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

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

• 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

v=0
o=alice 2890844526 2890844526 IN IP4 10.32.241.3

Bundling of Streams

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

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

• 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

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 biloxi10.32.example241.com3 
t=0 0 
a=group:BUNDLE audio video 
m=audio 2000010000 RTP/AVP 0  
a=mid:audio
a=rtpmap:0 PCMU/8000 
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 
m=video 2000010002 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 

RTP and RTCP Multiplexing

The

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

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

   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.
  
  

• The

  Spacevars
  0 product

   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

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

Limitations