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