The SBC Core supports setting the media (including codec) policy on a call-by-call basis. Media parameters are defined in the Packet Service Profile (PSP) which can be attached to an IP trunk group or IP Peer. For each call, an ingress PSP and an egress PSP is determined, and then these PSPs are “combined” to arrive at a set of media parameters for the call.

The PSP includes the following configurable features:

  • allowed codecs (ordered list)
  • packetization parameters
  • fax handling
  • modem handling
  • DTMF handling
  • transcoding combinations

The Packet Service Profile supports up to four audio codecs using ERE. Compression algorithms available for assignment to these are shown below.

Note

The PSX supports configuring up to 12 codecs in the Packet Service Profile and Preferred Packet Service Profile. The SBC supports receiving all 12 codecs from the PSX in the PSP and Preferred PSP. This applies to interworking with an external PSX (Advanced ERE deployment scenario). See Routing and Policy Management for deployment scenario details.

Additionally, the SBC supports up to 12 codecs over Gateway links to SBCs and/or GSXs.

Note

An SBC-POL-RTU license is needed to enable more than four codecs.

When call endpoints do not share a common codec, or to preserve different packet sizes, silence suppression and/or DTMF relay methods on each call leg, the SBC performs media translations (transcodings) necessary for the endpoints to connect.

Transcoding between any two supported compressed audios requires two DSP channels. Two channels each transcoding between G.711 (or IDP) and one compression codec are bound together in tandem to support a compressed-to-compressed transcoding. The SBC defines the audio pairs that are transcoded. For more information, refer to Audio Codecs and Video Codecs.

The SBC SWe uses software implementation to strictly check amplitude levels and frequency while detecting inband DTMF digits. The inband DTMF digits amplitude generated from the SBC SWe for G.726 codec is considered bit-less. This may impact scenarios such as an SBC SWe sending inband G.726 digits to a second SBC SWe which is trying to detect tones. In this situation, the SBC SWe inherits the same behavior as the software implementation for detecting inband DTMF digits. This implementation of DTMF functionality is as per standard. The SBC SWe supports detecting inband DTMF digits at power levels above -25 dBm and no frequency detection below -55 dBm.

Pass-Through of Unknown Codecs

Modified: for 12.1.4



The SBC is enhanced to handle codecs not defined in its profiles by passing them through in the outgoing SDP if the codecs are present in the offer SDP in transcoder-free transparency mode. This feature ensures that other call setup parameters like ptime, silence suppression, and comfort noise settings remain unchanged, unlike in transcoder-free operation. The SBC supports all codecs regardless of the configured profile and filters only specific ones, while also ensuring that “ptime” and “a= line silence-suppression or CN” are sent across if received. Additionally, the new flag “relayPtimeMaxptimeIfReceived” ensures that both “ptime” and “maxptime” are included in the outgoing SDP if they are present in the incoming SDP, taking precedence over existing flags.

Note

When Transcoder Free Transparency (TFT) is not enabled, only the selected codec is sent in the outgoing 200OK in answer path. 

Note

All EPs must handle dtmf events 0-15. The SBC can send out the fmtp line (when not received from ingress) even when TFT is enabled. Since all implementations MUST have the ability to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL.

"Unknown codecs" refers to SBC-aware codecs that are not configured in the SBC's Packet Service Profile (PSP).



Additional topics in this section: