12-31-2008 09:43 AM - edited 03-15-2019 03:17 PM
Very basic question , but I cant seem to see why a full DSP resource is required
when sending voip calls over a Digital trunk.
Assuming that both sides use G.711 and no transcoding is required what role does the DSP perform ?
Is it just to add the IP/UDP/RTP Packet headers ?
I mean no sampling / quantaziation or encoding is being done...
If so, cannot this be done just in s/w ?
(Perhaps the obvious answer is no, and that is why a DSP is required)
Or am I missing somethig more ?
Thanks
Solved! Go to Solution.
01-02-2009 10:53 AM
Both G711 and T1's use 64kb/sec uncompressed formatting. This boils down to Nyquist's theorem with the maximum sample size for the frequency range. It's estimated that human voice can reach 4000 Hz so we sample the voice at 8000 Hz (forgive me if these numbers are a bit off).
The DSPs also do a great number of other things. The echo cancellation, creating of playout delay buffers, input gains, output attenuations, DTMF detection, and other tone detection (fax/modem) is all done through the DSP. If you use SIP for instance, and the gateway receives a RFC 2833 DTMF packet, something on the router must generate the DTMF tone in the circuit switched world. The DSP in this case is what is used to change a RFC 2833 packet into DTMF.
The ulaw/alaw is normally done on the TDM side as well as the IP side, so the DSPs aren't generating this as much as they are normally passing it on (but they can transcode this as well).
The RTP packet headers are going to be built in IOS, but the payload of the packets is going to be processed in the DSP as long as there is an RTP packet that needs to be built.
hth,
nick
12-31-2008 09:57 AM
Hi Shahed,
This relationship is described nicely in the SRND Guide.
Voice termination applies to a call that has two call legs, one leg on a time-division multiplexing (TDM) interface and the second leg on a Voice over IP (VoIP) connection. The TDM leg must be terminated by hardware that performs coding/decoding and packetization of the stream. This termination function is performed by **digital signal processor** (DSP) resources residing in the same hardware module, blade, or platform. All DSP hardware on Cisco TDM gateways is capable of terminating voice streams, and certain hardware is also capable of performing other media resource functions such as conferencing or transcoding.
CCM SRND;
Hope this helps!
Rob
12-31-2008 11:12 AM
Hi Shahed,
To clarify this for you: TDM trunks do not have a codec, because they use exactly that - Time Division Muliplexing. Codecs and packetization only happens on VoIP links. Analog/Digital circuits have no packets, but dedicated time segments instead.
Now, one situation where you can avoid using DSPs is if a call comes into one circuit, and goes back out another (or the same) circuit. In this case, the gateway is able to 'hairpin' the TDM and it isn't necessary to convert the TDM voice into RTP packets.
We also use DSPs for doing SLAs with voice packets. Basically the DSPs are the ones responsible for creating RTP packets and compressing/decompressing the different codecs.
hth,
nick
12-31-2008 11:22 AM
Ok, but I frequently come across that
CAS trunks use G.711 64K uncompressed audio on a DS0 channel
So although its TDM, the voice payload is still encoded using some sort of coding .. correct ? And is that coding not the same as G.711 ?
I understand that the DSP's put the RTP header and that is why they are required....
Thx
01-01-2009 05:32 PM
ok, so you can understand this.
analog <-> DSP <-> VoIP
the DSP is the one that takes care of taking analog data into digital and viceversa.
TDM is 8 samples of 8 bits per second, but ANALOG. so you need something to take that into DIGITAL. that's the reason you need DSPs because VoIP is DIGITAL and traditional trunks are ANALOG.
HTH
java
if this helps, please rate
01-02-2009 09:00 AM
Actually, java, replace 'ANALOG' with 'circuit-switched' and 'DIGITAL' with 'packet-switched'.
TDM trunks are still digital. The difference is that the voice traffic is channel-based (i.e. circuit-swicthed) and not packetized.
01-02-2009 10:15 AM
Yes, I agree..
This thread has been most informative.
To summarise, what I think I have learnt is that :-
Audio over TDM channels uses TDM/PCM format.
Its still G.711 but over a TDM.
The DSP's then PACKETIZE the audio by adding the RTP/UDP and IP headers.
So when conveting calls from PSTN to VoIP (g.711),
the DSP's do mostly packetizing as no transcoding is necessary.
They may also be involved in other stuff like ech cancellation / dtmf processing etc..
Anyone like to add to this ?
Thanks
01-02-2009 10:53 AM
Both G711 and T1's use 64kb/sec uncompressed formatting. This boils down to Nyquist's theorem with the maximum sample size for the frequency range. It's estimated that human voice can reach 4000 Hz so we sample the voice at 8000 Hz (forgive me if these numbers are a bit off).
The DSPs also do a great number of other things. The echo cancellation, creating of playout delay buffers, input gains, output attenuations, DTMF detection, and other tone detection (fax/modem) is all done through the DSP. If you use SIP for instance, and the gateway receives a RFC 2833 DTMF packet, something on the router must generate the DTMF tone in the circuit switched world. The DSP in this case is what is used to change a RFC 2833 packet into DTMF.
The ulaw/alaw is normally done on the TDM side as well as the IP side, so the DSPs aren't generating this as much as they are normally passing it on (but they can transcode this as well).
The RTP packet headers are going to be built in IOS, but the payload of the packets is going to be processed in the DSP as long as there is an RTP packet that needs to be built.
hth,
nick
01-02-2009 11:02 AM
Thanks Nick,
>>The ulaw/alaw is normally done on the TDM side as well as the IP side, so the DSPs aren't generating this as much as they are normally passing it on
>>(but they can transcode this as well).
I think you have confirmed what I was not too sure about.
Also thanks for expanding on the other aspects of DSP processing.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: