Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Add_docset_workflow
sgahlautbscogginssgahlautbscoggins
AUTH1bscoggins
DEV1
LDEV1
SVT1
LSVT1

Noprint
Panel
borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

Back to SIP Services

Back to SIP Signaling

...

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. See sipTrunkGroup media - CLI or SIP Trunk Group - Media for configuration details.

...

ICE-Lite Support

Include Page
ICE-Lite_Support

...

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 that is, 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 endpoints. With the implementation of this feature, SBC acts as an ICE-Lite Agent. Therefore, the endpoints using WRTC can be connected to the existing VoIP network through SBC by using the DTLS-SRTP protocol. While acting as an ICE-Lite endpoint, 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

SBC implementation for ICE can be used with endpoints that are connected to the SBC through Sonus WRTC gateway and also WebRTC endpoints that are connected from some 3rd party WebRTC Gateway and 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.

The key points of ICE-Lite are:

...

An ICE-Lite agent has a reachable public IP address and can work with other agents that use ICE and are behind the NAT.

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

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

  • 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 SBC 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 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.

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

ICE-Lite Implementation

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:

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

STUN is used to discover the Server Reflexive and Peer reflexive address 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.

...

  • .

Pagebreak