cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1437
Views
0
Helpful
6
Replies

VoIP support for Cisco 3845

support
Level 1
Level 1

If I want to deploy IP Telephony to my office and use SIP trunks from my 3845 router, what hardware (DSP, etc) needs to be purchased and installed? I am a bit confused on the need of a DSP module or not. My understand of it, is that it offloads the processing of codecs from the router's CPU. However, is it required to have in order to deploy call manager express and SIP trunks?

1 Accepted Solution

Accepted Solutions

Question #1: Yes, and you don't even need DSP resources for that. During call setup, the end device negotiate the codec. You can configure the call controller (CUCM, CME, Asterix, whatever) to limit that codec to g.729 on external calls during setup, so no transcoding is required.

Question #2: It depends on who you talk to, but I think g.729 is a great codec. It does sound a little different, but still clear and understandable. The key to g.729 is re-encodings. g.729 quality goes down when it needs to be transcoded to another codec or channelized to the PSTN. The quality really goes down if it needs to be re-encoded multiple times. For PSTN calls over the WAN (via SIP) it should be serviceable. For IP-to-IP calls over the WAN, when it can stay g.729 end to end, it is ideal.

View solution in original post

6 Replies 6

The DSP resources are only required for packetizing voice (from TDM to VoIP and vice versa), for transcoding from one codec to another, or for conferencing. They would not necessarily be required to support SIP trunks, assuming everyone can agree on a codec. However, meet-me style conferences and music-on-hold would likely not be available without DSP resources.

And it should be said, DSP's do not "offload" the codec processing from the CPU. Cisco router CPU's cannot process codecs at all. They can route voice traffic and handle call control functions (with CME) but the router cannot terminate or modify the voice stream without DSP resources.

Ok, so I would need at least some DSP resources installed on our router to be able to let people, even within our intra-office, have conference calls (3 or more people)? What module do you think I would need to support 5 or so conference calls?

Sorry if that seems like a dumb question, but the DSP modules are expensive, and I want to budget properly. My cisco vendor is confusing me, and I think they are just pushing the "sell" by saying this -

"As a rule of thumb, we recommend maxing out the DSP capabilities if the router will support voice. The 3845 can take 4xPVDM2-64 meaning (4) 64 channel fax and voice DSP modules." Our company has 100 employees. Is this overkill?

I don't have access to the DSP Calculator on CCO right now, but it works out to something like this. Each DSP resources can support 1 G.729 conference or 4 G.711 conferences, each with up to 8 people in the conference. That PVDM2-64 has 4 DSP resources.

So fully loaded, those 4xPVDM-64's can support (theorically; there is a software limit also) 64 seperate conferences with 512 people. Yeah, that might be overkill.

Thanks for all your help thus far. Here are a couple more for you. :)

Assume I have enough DSP resources, would I be able to use G.711 over the LAN, but G.729 over my SIP trunk to my provider over my WAN?

Second question: Assume latency and jitter are at tolerable levels between use and our SIP trunk provider, how good or bad of a codec is G.729? Is it worth the bandwidth savings?

Question #1: Yes, and you don't even need DSP resources for that. During call setup, the end device negotiate the codec. You can configure the call controller (CUCM, CME, Asterix, whatever) to limit that codec to g.729 on external calls during setup, so no transcoding is required.

Question #2: It depends on who you talk to, but I think g.729 is a great codec. It does sound a little different, but still clear and understandable. The key to g.729 is re-encodings. g.729 quality goes down when it needs to be transcoded to another codec or channelized to the PSTN. The quality really goes down if it needs to be re-encoded multiple times. For PSTN calls over the WAN (via SIP) it should be serviceable. For IP-to-IP calls over the WAN, when it can stay g.729 end to end, it is ideal.

Thank you very much for all of your feedback. This has been a lot of help in my research!