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

   Spacevars
   0 product

   receives an re-INVITE with no SDP  on egress, by default, the

   Spacevars
   0 product

    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

   Spacevars
   0 product

    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

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.

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 

Anchor
Ice-Lite Ice-Lite

ICE-Lite Support

Bundling of Streams

The

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 using RTP/RTCP multiplexing, use the same address:port combination for all RTP and RTCP packets.

Single-bundle

The

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 

• 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 

  Spacevars
  0 product

  treats the stream as a bundle-only stream.
• The 

  Spacevars
  0 product

  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 

• 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

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

• The

  Spacevars
  0 product

   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

  Spacevars
  0 product

  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
  
  

Asymmetric PRACK interworking

The 

Spacevars
0 product

supports PRACK functionalities either on the ingress or on the egress leg and denotes it with the phrase "Asymmetric PRACK The 

Spacevars
0 product

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.

Note
icon false
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:

Caption0Table1Parameter configurations for supported call flows

below:

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

Info
icon false
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

0Figure1Asymmetric PRACK Interworking - Supported Call Flow Scenario 1

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

Image Modified 

0Figure1Asymmetric PRACK Interworking - Supported Call Flow Scenario 2

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

Image Modified 

0Figure1Asymmetric PRACK Interworking - Supported Call Flow Scenario 3

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

Image Modified

Multiple m-lines Support in SDP

The 

Spacevars
0 product

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

Spacevars
0 product

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

When the 

Spacevars
0 product

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

Spacevars
0 product

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 

Spacevars
0 product

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 

Spacevars
0 product

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 

Spacevars
0 product

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:

• SIP Trunk Group - Media - CLI
• SIP Trunk Group - Media

Offer-Answer Timer Configuration

In specific call scenarios, the 

Spacevars
0 product

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

Spacevars
0 product

, 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 

Spacevars
0 product

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

Info
icon false title 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:

Caption0Figure1Message Flow Diagram in Offer-Answer Cycle

Image Modified