Transcoding Overview

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. SBC defines which audio and video codec pairs to transcode. Refer to Supported Codecs and Transcoding.

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.

Timestamp Continuity After Trancoding Modifications

In the event that transcoded call attributes are modified (see three scenarios below) resulting in a rebuilding of DSP resource chain, both the timestamp and sequence number of Egress RTP packet header maintain continuity before and after call codec is changed. This is not applicable if a call is pass-through and gets modified to transcode, and vice versa.

  • Codec of transcoded call changes to another type of transcoded call.

  • Change of packet size. The first RTP package after rebuilding DSP resource chain contains a timestamp incremented with packet size before the change. Afterwards, RTP timestamp reflects the new packet size normally. The sequence number advances consecutively from the sequence number before the call modification.

  • One leg of the call gets transferred which results in changing RTP sender of one side of the SBC. The other leg maintains continuity of RTP package. However, the leg that got transferred is not expected to retain RTP timestamp and sequence number. This is only applicable for a call that is transcoded before and after transfer (i.e. not pass-through in any case).
The timestamp and sequence number continuity is also preserved in a situation where a transcoded call uses tone announcements (which uses TNAPAD in resource chain).

When preserving RTP header continuity is applicable, the new sequence number and timestamp continue from the last RTP packet sent before the call is modified/transferred.

 

  • No labels