Talk-off is an unintended command activation when the human voice is mistakenly detected as a DTMF control signal. DTMF tones are normally only generated when you press a key on the phone’s keypad. Talk-off is where the detector in the remote server or PBX gets triggered by similar frequencies in human speech.
This false triggering of the tone detector may not always cause the call to drop, but it is not unheard of for the signal to be misinterpreted as a request to end the call or put the call on hold. For example, a conference bridge might interpret * as meaning the user is leaving the conference.
With VoIP calls, it is possible for a connection to fail and for that failure to not be detected immediately. For example, if you trip over the cable and pull the power lead out of your phone then it never gets the chance to send an end-of-call signal. The SIP Session Timers (SST) mechanism is designed to prevent such “orphan” calls from persisting for an excessive length of time. “Keep-alive” messages are sent from one end-point to the other at regular intervals (e.g. every 15 minutes). If the expected message does not arrive “on time” then it is assumed the connection to the far end has failed and the call is ended.
It is not uncommon for SIP Session Timers to go wrong resulting in a false positive and the call being dropped. Of course, they should not go wrong, but they do. This is probably due to subtle incompatibilities in the way the mechanism was implemented in the end-point devices, especially if those devices are not from the same manufacturer.
Some VoIP servers may assume that a period of “no audio” means the connection to the far end has failed. This is another way that some VoIP equipment tries to detect an “orphan” call. It looks at the media stream (which uses the RTP protocol) and detects when no audio signal is present. Usually there would be enough background noise to prevent this happening, but a muted microphone might trigger a false positive. Another reason for this happening would be if the handset has “silence suppression” or “voice activity detection” (VAD) enabled. This is a mechanism that deliberately stops sending audio packets when the sound level at the microphone falls below a certain threshold. It is meant to reduce network bandwidth demand.
The SIP protocol requires that certain timeout periods are set, within which a response or acknowledgement message must arrive from the far end. It is possible for a call to start, apparently with everything ok, but to then end, say, 10 seconds or 20 seconds later because the SIP ACK (Acknowledgement) message failed to reach the intended destination within the timeout period.
Many service providers set a limit on the maximum duration for any call passing through their system. This is yet another way of protecting against so-called “orphan” calls which could otherwise persist on the service providers system for days. The maximum call duration would almost always be set to at least 1 hour, but in most cases it would be 2 or more hours. On a pre-paid system, the maximum permitted length of your call is likely to be linked to how much credit is in your account.
Just because you have a VoIP system, do not assume that all faults are VoIP related. Calls to or from mobile handsets (cell phones) will often drop simply because the signal on the mobile handset was lost. This type of problem happens for everyone and is no different for VoIP users than it is for users of legacy PBX’s. Consider also that your IP handset and IP-PBX depend on network connections. If any part of that network relies on Wi-Fi or other non-cable based connections, it could simply be a fault in the network equipment or something as banal as a loss of a Wi-Fi signal.
If you are clearly able to identify the cause of the problem, various remedies may be available to you. If the cause is unclear, a packet capture can often help to prove or disprove a tentative diagnosis. In some cases you can simply proceed on the basis of your best guess and see if things get better, or at least change, when you make certain adjustments. Sometimes, the solution may be out of your hands and you will have to work with the support department of your service provider.
With talk-off problems, reducing the gain on the handset’s microphone may help, but the real solution lies further downstream in the connection chain. If you have admin access to the PBX, look for settings that reduce the sensitivity during DTMF detection. On Asterisk or FreePBX systems try setting “relaxdtmf=no” for the relevant sip connections. It may also help if you change the method of detection, especially disabling so-called “in-band” DTMF detection. On Asterisk, look for the dtmfmode setting in the sip configuration:
If you suspect the problem is due to SIP Session Timers, then you may need to experiment with settings. Look for settings on your IP phones. If you cannot find them, try a Google search (e.g. “Snom 360 session timers”) and, if necessary, contact the support department of the manufacturer. If the problem happens with some phones, but not others, then try to duplicate the good phone’s settings on the bad handset. Try increasing the Min-SE value to determine if it alters the time before a call drops. On an Asterisk system, try setting “session-timers=refuse” in the sip.conf file or the advanced SIP settings of FreePBX – this will disable SST’s and may instantly solve your problem.
When it looks like the problem is an over-aggressive silence detection system, the culprit is likely to be the equipment you are calling. This means you may not be able to disable it or adjust the timeout. However, there may be remedies within your reach. Some phones have settings that allow you to enable or disable “silence suppression” or “VAD” (Voice Activity Detection). Try altering the settings to see if it makes a difference. You may even find a setting that is specifically there for this problem. On Snom phones with v8 firmware, it is called “Send silent RTP packets on mute” and is in the Advanced > Audio section. I recommend you switch it on.
If you have an Asterisk system and suspect it is disconnecting calls when the voice stream goes silent, then you should consider changing the RTP Timer settings. Here is an extract from the auto-generated sip.conf file of an Asterisk 1.6 installation:
;rtptimeout=60 ; Terminate call if 60 seconds of no RTP or RTCP activity on the audio channel when ; we're not on hold. This is to be able to hangup a call in the case of a phone ; disappearing from the net, like a power loss or grandma tripping over a cable. ;rtpholdtimeout=300 ; Terminate call if 300 seconds of no RTP or RTCP activity on the audio channel ; when we're on hold (must be > rtptimeout) ;rtpkeepalive=<secs> ; Send keepalives in the RTP stream to keep NAT open (default is off - zero)
If you think your problem fits the symptoms of the missing ACK message, I regret that I am unable to offer much self-help advice here. The first step would be to obtain a packet capture using a tool such as Wireshark. It is likely to be a bug in a SIP server and so would require expert help. However, you could also look at options on the IP phone related to NAT and see if they make a difference when tweaked. If you have a NAT firewall with a “SIP ALG”, then it nearly always helps to disable it.
« Go back
Loading knowledgebase suggestions...