Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Sending DTMF Tones

I has a strange experience recently that I can't explain. We're running CCM 3.3.2c. The PSTN gateway is over a 6608 PRI. Everything was working fine.

I swapped another blade in the 6509 (actually the ethernet blade that the CMs were connected to) but did not reset the switch. The CMs were disconnected for a few minutes during the board swap, but were also not restarted. The PRIs remained connected to the 6608. When everything was connected back together, everything appeared to work correctly (calls completed as expected incoming and outgoing).

But it soon became apparent that DTMF tones from the 7960's to the PSTN were not being sent DURING calls when 0-9, #, or * were pressed. The call would complete, but if buttons were pressed during the call, no tones. I tried this to PSTN POTS lines and spoke while pressing keys. My voice was sent fine, but no tones. This was true for all IP phone users. G.711 everywhere. I eventually reset the whole switch and all was well. No errors in the switch log.

I'm at a loss to explain why I saw this behavior. Any idea what would account for this?


Re: Sending DTMF Tones

Since, after swapping the blade, the switch was not reset, it could not recognise it immediately. And whenever a new module or blade is inserted in the switch, it should be restarted to initialise the system.


Re: Sending DTMF Tones

That's not necessarily so. The 6500 is fully capable of hot-swap operation, and functionality should come back just fine without a system reset.

It's hard to say exactly what happened; it's probably a bug of some sort. Passing DTMF digits uses a function called DTMF relay, wherein the devices on each end of a VoIP call recognize DTMF digits and pass that information as out-of-band data. The reason for this is that DTMF digits can be garbled beyond recognition by low-speed codecs. For whatever reason, this mechanism between CCM and your 6608 blade broke down after communication between them was disrupted by your hot-swap. It could probably have been resolved by resetting the blade in CCM, or at most power-cycling the 6608 blade only (you can do this from the CatOS or Native IOS CLI), but the system reset obviously accomplished it as well.

If you're concerned about it in the future, you can ask TAC if there's a bug. It's also a good idea to be running the latest service release for CallManager; there are a number of 6608 bugs fixed. Also apply the latest OS patches if you haven't already, there are lots of security fixes. They can be downloaded from here:

CreatePlease to create content