cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5236
Views
22
Helpful
8
Replies

Why do I need a DSP for TDM->Voip when both use G.711?

shahedvoicerite
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

8 Replies 8

Rob Huffman
Hall of Fame
Hall of Fame

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;

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a0080637427.html#wp1057930

Hope this helps!

Rob

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

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

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

HTH

java

if this helps, please rate

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.

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

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

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.

Getting Started

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: