5.8. SDP Mediation

SDP mediation allows to manipulate how applications codecs will be selected during session negotiation.

5.8.1. Codec Signalling

In SIP call parties are free to negotiate their capabilities using the offer-answer model, see RFC 3264: The caller offers its capabilities such as supported codecs and the caller party matches those against its own. In some cases it may be reasonable to restrict the list of offered codecs. Mostly, this is done when there are bandwidth constraints.

If media anchoring is used, every single media stream enters and leaves the SBC. With the most common but “hungry” codec G.711, it means 172 kbps x 2 in each direction, which corresponds to a maximum of about five thousand calls on a gigabit link (the actual limit is in fact even lower due to packet rate constraints).

G.729 is probably the most widely used codec with lower bandwidth consumption. The bit rate for G.729 yields 62 kbps in each direction (the rate includes UDP, IP and Ethernet overhead).

For mobile clients, bandwidth hungry codecs with large packet size like G.711 can pose additional problems: Due to longer use of the wireless interface, battery life is reduced, and also the packet loss rate is greatly increased with the bigger packet sizes. On the other hand, CPU intensive codecs may also strain the battery on mobile clients if they are not implemented in hardware.

For these reasons, the ABC SBC offers you these functions

  • setting codec preferences (Set codec preference action). Specifies in descending order which codecs offered in SDP payload should be “picked”.
  • transcoding (Enable transcoding action) – allows to convert sender’s media from encoding the received does not support to encoding he does. See more in Section Transcoding.
  • codec white/blacklisting (Set codec whitelist and Set codec blacklist actions) explicitely specifies which codecs are permitted or not.

In order to save bandwidth and improve battery life and call quality, to mobile clients G.711 should not be used by using a Set codec blacklist action with “PCMU,PCMA” as blacklisted codecs.

Another example is emergency calls (911), where due to call quality concerns G.711 is the mandatory codec. If, for bandwidth saving reasons, the G.711 codec is usually blacklisted, it should be whitelisted for calls sent to an emergency gateway.

If codec restrictions result in a failure to find a common codec, the ABC SBC offers you to use built-in software based transcoding to increase interoperability.

Please refer to the Media processing section, see Sec. Media Handling for a complete reference of functionality the ABC SBC offers to restrict the set of used codecs, give certain codecs a preference or transcode between codecs.

5.8.2. Media Type Filtering

For an audio call, the media type in the SDP is “audio”. For a normal video call with audio, the two media types “audio” and “video” are negotiated, for other types of calls (“image”, screen sharing etc), other media types are possible.

Media types may be filtered using the actions

  • Set media blacklist  - remove all blacklisted media types from SDP
  • Set media whitelist  - remove all but whitelisted media types from SDP

The media blacklist/whitelist actions have as parameters a comma-separated list of media types (audio, video, image, ...) to be blacklisted. It is applied to all SDP messages exchanged at any time during the call. In the case that after applying the action no media type is left in the SDP message then the request will be rejected with a response message 488.

Example: Allow only audio payload to pass and prevent video streams to be negotiated; for the User Agents it will appear as if the other side does only support audio.


Figure 1: Remove video streams

Example: Let audio and audio/video calls through.


Figure 2: Allow only audio and video

Example: Remove “image” media type.


Figure 3: Do not allow exchange of images

5.8.3. CODEC Filtering

The actual audio or video content of a call can be encoded with different codecs, which have each different properties regarding:

  • audio or picture quality
  • bandwidth consumed
  • latency introduced
  • processing power required
  • resilience regarding packet loss

For example, the G.711 codec has “toll quality” (audio quality roughly equivalent to PSTN, 8khz sampling rate/narrowband) at 64kbit/s (roughly 80 kbit/s including headers in each direction), introduces low latency, requires little processing but is not resilient against quality degradation with packet loss. The G.729 codec has a bit less than “toll quality” at 8kbit/s, 6.4kbit/s or 11.8 kbit/s (depending on the used annexes) with modest latency introduced, some processing power required, and some resilience against packet loss.

In order for two endpoints to successfully establish a call, both endpoints need to support the same codecs. The codecs actually used in a call are negotiated using the SDP protocol and the SDP offer/answer method to the subset of codecs supported by both endpoints, and thus it is usually best to let the endpoints negotiate with the most options possible.

If for some reasons codecs need to be filtered, the actions

  • Set CODEC whitelist - remove all but whitelisted media types from SDP
  • Set CODEC blacklist - remove all blacklisted media types from SDP

are used. Each of these actions takes a comma-separated list of codecs to white- or blacklist, which must be the names of the CODECs as they are used in SDP [1] . Codec names are case-insensitive, a blacklist of “g729,ilbc” is equivalent to “G729,ILBC”. In the case that after applying the action no codecs are left in the SDP message then the request will be rejected with a response message 488.


Figure 4: Setting a whitelist


Figure 5: Setting a blacklist

All of the white- and blacklists applied for a call are executed one after another. For example, if one action sets the whitelist “PCMU,PCMA,SPEEX” and another action sets the whitelist “PCMA,G729”, it would result in only PCMA (G.711 alaw) be let through for the call.

The codec white and blacklists are applied on both legs, the incoming and the outgoing call legs, and on all SDP messages going in both directions (from caller to callee and from callee to caller) at any time during the call.

5.8.4. CODEC Preference

Codec negotiation in a SIP call usually works this way

  • the offerer (the caller in calls with normal SDP offer-answer negotiation; the callee in calls with delayed SDP offer-answer negotiation) lists the supported codecs for a call in preferred order, so the first codec in the SDP is the codec preferred by the offerer
  • the other party (the answerer) selects from this list the subset of codecs that it supports, and orders it according to its preference or local policy, it may for example accept the order that the offerer asked for
  • both parties encode and send media with the codecs that are in this subset, and usually the first codec in the answer is used, but (even without re-negotiation) any party may switch in-call to any codec in this subset

Because the User Agents usually respect the codec preference of the other side, the operator may influence the codec actually used for a call in the SBC by reordering the codecs as they are listed in the SDPs. Codec preferences may be influenced in order to

  • improve audio quality by preferring better performing codecs
  • save bandwidth
  • save processing power on the User Agents, e.g. especially if mobile/battery powered devices are used

The Set CODEC preferences action has as parameters two comma-separated lists of codecs, for the A (caller) leg and the B (callee) leg respectively. An entry may have the specific sample rate appended separated with a slash, e.g. speex/32000, speex/16000, speex/8000


Figure 6: Setting the codec preferences

Any codecs in this list found in the SDP messages exchanged in either direction are prioritised in the order listed, by placing them at the beginning of the codec list in the SDP document. It is a good practice to configure the same order for both legs.


Figure 7: Example: Prefer bandwidth-saving codecs (codecs that compress more): G.729,iLBC,speex,G.726


Figure 8: Example: Prefer codecs with high audio quality: OPUS,SILK,speex/32000,speex/16000,G.722,AMR-WB

Additionally codec attributes offered in SDP can be filtered out using actions Set SDP attribute whitelist and Set SDP attribute blacklist.

5.8.5. SDP Bandwidth attribute limiting

The SDP may contain a (session-level, or media-level) b=<modifier>:<value> attribute, which sets the bandwidth to be used (see RFC4566). Different types of bandwidth signaling are standardized, denoted by different modifiers; the most common being TIAS (RFC3890), AS (application specific, RFC4566) and CT (conference total, RFC4566). The action Set SDP bandwidth limit can be used to limit the signaled bandwidth: If there is a bandwidth attribute for the specified type, it will be set to the limit if it is signaled to be more than the limit. If there is no bandwidth attribute for the specified type, one will be added.

Especially when the actual RTP bandwidth available to a call is limited using the action Limit Bandwidth per call (kbps), using this action the SBC can signal the maximum available bandwidth to the endpoints.

If ‘Media type’ is not set, this action sets the session-level bandwidth attribute. If ‘Media type’ is set, it sets the media-level bandwidth attribute for that media type. E.g., if ‘video’ is set as Media type, then all m-lines with type ‘video’ will have a properly limited bandwidth attribute. ‘Media type’ can be set to only a single media type value (i.e. ‘video’ or ‘audio’), no list can be given here (i.e. ‘video, audio’ is wrong); if multiple media types should be limited, multiple actions must be used.


[1]e.g. PCMU for G.711 ulaw, PCMA for G.711 alaw. See http://www.iana.org/assignments/rtp-parameters and the IETF payload type specifications (RFCs) for the used names of the CODECs.