Page History
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
| Spacevars | ||
|---|---|---|
|
...
| Info | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The
|
...
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 time stamp 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 time stamp timestamp incremented with packet size before the change. Afterwards, RTP time stamp 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 time stamp 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).
| Info |
|---|
| The time stamp 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 time stamp timestamp continue from the last RTP packet sent before the call is modified/transferred.
...
Overview
Content Tools