Ok ... so the background to all this is that the 'Plain Old Telephone System' (POTS) was always intended to have people on either side of the connection and they would be able to determine when the conversation was finished and they could then hang up the telephone handset to clear the call.
Since the majority of telephone signaling was originally tone based (DTMF to make the call, ringbackl/busy/fastbusy/number unavailable etc) , people quickly learnt what all the tones indicated and what actions should be taken when particular tones were heard. Another fundamental design feature of the legacy telephone network is that it always expects the users to disconnect towards the network - the network has no control of the users actually placing the telephone back on hook.
When 'intelligent' (this point could be argued) telephony devices such as IVR's and voice mail systems began to be placed across telephone connections, some very basic problems became apparent. The major issue relates to disconnect of the call when the other party hangs up.
If the voicemail or IVR decides to clear the call, then it only has to open the physical loop and current stops flowing and the call is cleared. However, if the other party hangs up, the connection from them to their local exchange is cleared, but the connection from the IVR's local exchange is maintained until the IVR decides to hang up.
Unless the IVR gets some kind of signal that the call has ended, it will stay off hook and the connection to the local exchange will also stay up. This is the cause of common disconnect issues - the endpoint is not aware the other party has cleared the call so it keeps the connection up.
Even though the telephone network does not physically disconnect the connection to the IVR, it will still play a busy or disconnect tone to indicate the call has cleared.
Therefore, the telephony endpoint (IVR, voicemail, router etc...) needs to pick up these tones and interpret them in the same way a human being can.
On a router, these tones are called the CPtones (Call Progress Tones). They tell the DSP to generate or listen for particular tone combinations (frequencies) and tone durations (cadences) - these are then defined for different call states.
When you configure a specific CPtone on the voice port, you define a table of different frequencies and cadences. Following is the definition for the AU (Australia) and US tone plans -
UC_520#test voice tone AU show
Code: AU Country: Australia
DTMF freq.(Hz) Row / col: 697, 770, 852, 941 / 1209, 1336, 1477, 1633
Pulse dial: normal, Percent make: 35%, DTMF low Amp. = 65424, high Amp. = 65446, Pcm: a-Law
Tone NF FOF FOS AOF_FXS AOF_FXO AOF_EM AOS_FXS AOS_FXO AOS_EM ONTF OFTF ONTS OFTS ONTT OFTT ONT4 OFT4
BUSY 1 400 0 -120 -120 -120 0 0 0 375 375 0 0 0 0 0 0
RING_BACK 2 400 450 -120 -120 -120 -120 -120 -120 400 200 400 2000 0 0 0 0
CONGESTION 1 400 0 -150 -150 -150 0 0 0 375 375 0 0 0 0 0 0
NUM_UNOBTAINAB 1 425 0 -120 -120 -120 0 0 0 2500 500 0 0 0 0 0 0
DIALTONE 2 400 450 -150 -150 -150 -150 -150 -150 65535 0 0 0 0 0 0 0
DIAL_TONE2 2 400 450 -150 -150 -150 -150 -150 -150 65535 0 0 0 0 0 0 0
OUT_OF_SERVICE 1 950 0 -150 -150 -150 0 0 0 330 330 0 0 0 0 0 0
ADDR_ACK 1 600 0 -240 -240 -240 0 0 0 125 125 125 65535 0 0 0 0
DISCONNECT 1 425 0 -150 -150 -150 0 0 0 375 375 0 0 0 0 0 0
OFFHOOK_NOTICE 2 1400 2040 -240 -240 -240 -240 -240 -240 100 100 0 0 0 0 0 0
OFFHOOK_ALERT 2 1400 2040 -150 -150 -185 -150 -150 -185 100 100 0 0 0 0 0 0
UC_520#
UC_520#test voice tone US show
Code: US Country: United States
DTMF freq.(Hz) Row / col: 697, 770, 852, 941 / 1209, 1336, 1477, 1633
Pulse dial: normal, Percent make: 40%, DTMF low Amp. = 65446, high Amp. = 65467, Pcm: u-Law
Tone NF FOF FOS AOF_FXS AOF_FXO AOF_EM AOS_FXS AOS_FXO AOS_EM ONTF OFTF ONTS OFTS ONTT OFTT ONT4 OFT4
BUSY 2 480 620 -170 -170 -240 -170 -170 -240 500 500 0 0 0 0 0 0
RING_BACK 2 440 480 -160 -160 -190 -160 -160 -190 2000 4000 0 0 0 0 0 0
CONGESTION 2 480 620 -170 -170 -190 -170 -170 -190 250 250 0 0 0 0 0 0
NUM_UNOBTAINAB 2 480 620 -170 -170 -190 -170 -170 -240 250 250 0 0 0 0 0 0
DIALTONE 2 350 440 -165 -165 -185 -165 -165 -185 65535 0 0 0 0 0 0 0
DIAL_TONE2 2 350 440 -165 -165 -185 -165 -165 -185 65535 0 0 0 0 0 0 0
OUT_OF_SERVICE 1 950 0 -150 -150 -185 0 0 0 330 330 0 0 0 0 0 0
ADDR_ACK 1 600 0 -240 -240 -240 0 0 0 125 125 125 65535 0 0 0 0
DISCONNECT 1 600 0 -150 -150 -185 0 0 0 330 330 330 65535 0 0 0 0
OFFHOOK_NOTICE 2 1400 2040 -240 -240 -240 -240 -240 -240 100 100 0 0 0 0 0 0
OFFHOOK_ALERT 2 1400 2040 -150 -150 -185 -150 -150 -185 100 100 0 0 0 0 0 0
UC_520#
NF = number of frequencies
FOF = Freqency of first tone
FOS = Frequency of second tone
ONTF = On time (duration) of first tone
OFTF = Off time of first tone
ONTS = On time of second tone
OFTS = Off time of second tone
What all this means in theory is that if the voice port DSP picks up particular tone frequency/s and tone timings (cadence) as defined in the tone tables, it will be able to determine that the call has been disconnected and then clear the voice port towards the telephone network.
We all know that theory is wonderful. We also know that in practice, things are often very different.
Even though many country CPtones are based on relevant and publicly available specifications, what we are expecting and what other telephone systems are actually using can be very different.
For this reason, IOS gives the ability to customise specific tone settings to accomodate these frequency and cadence variations.
To determine these special tone settings, you need to capture and analyse the audio from the telephone network towards the router. The easiest way to do this is to obtain a wireshark trace of the network traffic when the call is cleared from the PSTN direction. Rather than hang up the IP phone, you continue to capture the media stream that contains the continual 'beep beep beep' tones.
Provided the traffic is using G711 as the codec, it is simple to save the RTP payload in wireshark as an .AU aduio file.
You can then use a shareware application like Cooledit96 to load up this captured audio file and display it's properties. Cooledit96 makes it easy to select the bursts of tone and measure the on time and off time - this determines the cadence. You then use the frequency analysis option to pick out the tone component frequencies. Once you have the cadence and frequency, you can use these to set the values of the custom tone class.
The tone/frequency deviation values allow the DSP to handle larger variations in the frequency and timing of the tones being monitored. In the case of the values you quoted, the frequency deviation would allow for around 20Hz (+/- 10hz) around the centre frequency, and the cadence deviation would allow 50msec (+/- 25 msec) around the tone timing.
