Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Sending DTMF Tones

Unanswered Question
Oct 6th, 2003
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
a-vazquez Fri, 10/10/2003 - 11:17
User Badges:
  • Silver, 250 points or more

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.

jasyoung Sat, 10/11/2003 - 20:20
User Badges:
  • Gold, 750 points or more

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:



This Discussion