DTMF Tone problems over a Cisco VOIP system

We have a system that allows for incoming calls from an automated system.  It uses DTMF tones to transer data from the client to the server. The issue is that when we pass the DTMF tones through the Cisco switch and the cisco vg224 the tones are not regenerated correctly.  The tones are distorted which causes periodic failures in the client/server communications.   Does anyone know how to directly pass DTMF tones through a Cisco system without distorting the tones?
Who is Participating?
Joel_SiskoConnect With a Mentor Commented:

While rwotherspoon is working on the switch theory, the only thing I would say in regards to the switch is that it might introduce some jitter, but not distorted DTMF digits.

I have a question on which codec is being used? Since the tones are being passed in-band, it means the CODEC will have a direct effect on the tone being replayed at the far end. If you are using anything but G.711 then its Russian roulette. Here is the reason why? G.711 is uncompressed, so what goes in on one side, comes out in full on the other. If G.729 is used, an algorithm is used to calculate what part of the data can be removed and still not affect the overall quality of the call. This means what goes in and what comes out are different. I would need three pages to go more in depth on voice compression, but that is for another day.

I would recommend that you force all system components that handle the calls from your automated application to use G.711, also you might want to set a precedence bit to enable the packet to travel faster thru the network to be on the safe side.  

Also to clarify, the router and VG224 have FXO ports that connect to some type of loop start trunks/pbx extensions? The router and the VG224 are not connected back to back via the FXO ports? FXO ports cannot connect to another FXO port without an external talk battery source and ring generator. I would look at loop current on the inbound side of the FXO ports, high loop current causes distortion of all in-band signals. Anything over 27mA should be of concern.

Kindest regards
Cisco proprietary voice fragmentation was implemented on earlier releases of the Cisco MC3810 Multiservice Access Concentrator. This fragmentation type is used on data packets on a PVC that is also used for voice traffic. When the "vofr cisco" command is configured on a DLCI and fragmentation is enabled on a map class, the Cisco 7500 series router with a VIP can interoperate with Cisco 2600 series, 3600 series, 7200 series, and other 7500 series routers as tandem nodes (but cannot perform call termination) with Cisco MC3810 concentrators running Cisco IOS releases earlier than 12.0(3)XG or 12.0(4)T.
blackfox_01Author Commented:
This is a new install and it is using a Cisco 2651xm ROuter with 1 vic2-2FXO card and a vic4-4FXO card linked to a Cisco VG224. Just to be sure we are talking about the same equipment.  We are sending the DTMF tones in-band.  Do they still fragment the packets when it is set up this way? So the 2651XM takes the place of the MC3810 correct?   The VG224 and the 2651 are both running cisco IOS 12.3. Are you suggesting that we route these calls through a different router?
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

rwotherspoonConnect With a Mentor Commented:
apostle12 - please stop the copy/paste of outdated (3 year old) information from the Internet into this thread ... thanks.

Blackfox_01 -
Distortion of sound (tones) through Cisco voice equipment is most commonly attributed to the configuration of switch ports connecting the voice gateways to the network.  The system you have sends tones to the gateway (VG224) and the gateway converts them to IP packets which are routed to an appropriate phone extension.

Please let me know what version of CCM you are running and I will be able to help you out.
blackfox_01Author Commented:
I am using CCM 4.0.  This was a new install that was on 3.X and it was determined that we needed 4.0 to handle our calls appropriately.  I hope you can help, this has been the most frustrating part of the install.  
blackfox_01Author Commented:
Thank you for the response.  We finally had a cisco engineer come in and what they determined was that the T1 had to be converted to H323 in order for the call to complete.   This created some other issues that had to be resolved before the system would work but this solved that part of the problem and still allowed us to handle calls properly.  

Thank you for all the feedback.  I feel like I have a better understanding of how the voip works.  
Glad to hear it has been resolved for you. I would recommend to you a book called Newtons Telecom Dictionary, its about 3 inches thick and just about every term you will ever need to know about.

Kindest regards
Joel's answer is closest. The issue is that some CODECs don't carry DTMF digits very well. To solve this problem, you can either pick a CODEC that does carry them well (which is what Joel suggested), or use a Cisco feature called "out of band DTMF". This works as follows: DTMF digits are detected by the sending gateway and sent "out of band" with a special signalling packet, and then re-generated by the receiving gateway. In this way, the DTMF tones are not distorted by the CODEC. Some signaling protocols don't support the extensions to allow sendout out-of-band DTMF digits, but H.323 does.

So, the Cisco engineer's solution was to switch to H.323, which supports out-of-band DTMF digit carriage.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.