Is there a way to make the 794x phones generate a sustained DTMF tone? For example, I need the "*" key to generate a constant tone for 650ms; however, it is only generating a 10 to 20ms tone even though I'm depressing the key. Thanks.
Sorry, there is no way, in the cisco architecture DTMF duration is always normalized.
I'm afraid you will have to use one of these small DTMF dialers, that are quite hard to find now.
If you have CUCM, and depending on your protocol, you may be able to change this.
For instance, you can change a service parameter regarding H323 to make the DTMF duration longer.
There are ways to do it, but it is dependent on the protocols and devices in your call flow.
The thing is that users want to send long digits only when necessary by the connected IVR application.
They do not want to change the default digit duration for all calls.
I still wouldn't underestimate the creativity you can do with the settings that exist. The default DTMF duration is adjustable in many places, and there's still a good chance you can get this to work. As well - I don't think very many people would ever notice that all of their DTMF is 650ms. From my experience, the average user's natural duration is somewhere between 200-400ms anyway.
I think I have not explained myself correctly.
This is not about changing defaults, that are fine.
Some IVR applications require you to enter long tones for certain functions, E.g. with certain long distance calling card, you enter a "longpound" to recall a dialtone at any stage of the call.
The natural way to do this is keeping the key pressed, unfortunately that doesn't work with cisco phones and users are disappointed.
May be the OP could clarify if my understanding is correct.
That's interesting - I've done quite a bit of DTMF work but never heard of an application that required a particularly long tone. +5 for this.
There's a whole spec lined out in ITU Q.24 which specifies the minimum length, frequency accuracy, etc. Technically any device that requires anything else would be out of specification.
Here a page from Cisco TLC/IVR that describes how to intercept (and generate) long tones and act appropriately.
Why this is necessary? Because when using calling card services we want:
1. to only make a single call to the access number, no matter how many card calls are then made.
2. to be able to use regular dtmf for any IVR we may call into.
3. To have a safe way to be returned to the main prompt, even if the called party doesn't hang-up (stuck call).
Hence the need for long tone, usually pound.
That is not against the specifications because the standard dictated a minimum duration for the digit to be recognized during dial phase, not what you do with tones after the call is made.
We have a specific transfer need. An internal user (User-I) is talking to an external user (User-E), and User-I wants to transfer User-E to another company on the PSTN. Our carrier will recognize a DTMF tone that is 650ms or longer and give User-I a second dial tone. User-I can then dial the other company and complete the transfer. This service is called Transfer and Release (TnR). Unfortunately, the carrier will not accept a sequence of different DTMF tones. Thanks for all of the input so far.
I think this can be done with a TCL/IVR script. In turn this require you to run H.323 or SIP to the GW.
If you are interested in having it custom developed, contact me at the address present in my profile.
Unfortunately, I won't be able to release the b-channels from the original call unless I can issue the DTMF tone during that call...the carrier switch listens for the DTMF tone and pulls the call into a virtual trunk group for transfer.
Yes, I think it can be done with an appropriate script. Are the calls to be TnR incoming, outgoing or either for user-I ?
Let us know.
Although I'm not sure what is the advantage of doing this type of transfer over a regular ones, beside not tying up channels.
What's the topology? You may be able to avoid a custom TCL script by changing DTMF durations for your calls.
Me and Paulo will disagree on this one because of our experiences - but I really try to avoid running custom TCL whenever possible. It opens up a world of possibilities in terms of new problems. On the other half, it also lets you do some cool things. Most people err on the side of caution with their voice networks.