Page History
| Add_workflow_for_techpubs | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Noprint | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
...
| Panel | ||||
|---|---|---|---|---|
In this section:
|
...
| Info | ||||
|---|---|---|---|---|
| ||||
...
...
...
|
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 below). The SDP transparency feature allows SDP and ICE media to pass through the
| Spacevars | ||
|---|---|---|
|
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.
| Note |
|---|
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
| Spacevars | ||
|---|---|---|
|
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
% 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.
| Caption | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
For configuration details, see
...
Passing Audio Codecs in SDP Offer
The
| Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
The
| Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
| Note | ||||
|---|---|---|---|---|
This feature is not applicable when the
|
Late Media INVITE or Re-INVITE Support
| Include Page | ||||
|---|---|---|---|---|
|
| Div | ||
|---|---|---|
| ||
|
Example 1: G711 pass-through call
- Ingress Offer: G711, G729
- Egress Offer: G711, G729, AMR, G726
- Ingress Answer: G711
- 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
- Ingress Offer: G711, G729
- Egress Offer: G711,G729, AMR, G726
- Egress Answer: AMR
- 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
...
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
| Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
...
SIP Trunk Group - Media - CLI or SIP Trunk Group - Media for configuration details.
| Anchor | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
Bundling of Streams
| Spacevars | ||
|---|---|---|
|
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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
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.
| Pagebreak |
|---|
Overview
Content Tools