You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Back to Table of Contents

Back to SIP Services

Back to SIP Signaling

In this section:

Related Articles

SDP Transparency

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

  • All unknown SDP attributes are transparently passed.
  • All unknown components of known SDP attributes are dropped.
  • Any unknown audio codecs are dropped.
  • All known and unknown video codecs are transparently passed.

When SDP Transparency is enabled, all IP Signaling Profile SDP-related flags are overridden.

For additional audio/video support topics, see:

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 SBC 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, it is suppressed due to “Suppress 183 for 3xx Redirect Response” flag.

  • If 183 without SDP is triggered for reason other than 3xx redirect response, it is suppressed 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 3xx redirect response' (or for any other reason) is suppressed.

Disabled

Disabled

Existing behavior persists.

For configuration details, see ingressIpAttributes - 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.

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

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

  • When  this flag is disabled for transcoded calls (default behavior), the SBC offers the codec used for transcoding on the leg.
  • When the flag is enabled for transcoded calls, the SBC offers multiple codecs which include:
    • The subset of the codecs that the associated peer supports.
    • The transcoded codecs that the associated DSP channel supports. This includes the codec currently being used for transcoding.

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

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

  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, SBC generates an offer for AMR. If the “Send All Allowed Codecs For Late Media Invite Or Re-Invite” flag is enabled then SBC generates a codec list of G711,G729, AMR, and G726 in the Offer.

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

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 whereby the user can configure which IP version 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, 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

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.

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.

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:

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

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

See Configuring SBC for WRTC for ICE configuration details.

  • No labels