Summary:	ASTERISK-16668: ACK tone interupted - Jitterbuffers do not function properly as AlarmReceiver App does not send RTP regularly
Reporter:	Grant Crawshay (saltydog256)	Labels:
Date Opened:	2010-09-12 04:08:48	Date Closed:	2012-09-05 11:04:07
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_alarmreceiver
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-16694 [patch] ACK tone not reliable on embedded platform with low CPU power is related to ASTERISK-18417 app_alarmreceiver hanging forever in send_tone_burst/ast_waitfor()
Environment:		Attachments:
Description:	The SIP service provider added jitterbuffers, and since then the Alarm does not recognize the ACK tone.  Dialing manually and listening to the tone ones hears an interruption (high speed stutter). The Alarm keeps resending data until it times out.  Data is received correctly and the checksum is good. Wireshark was used to inspect a normal incoming voice SIP call - Asterisk sends back 20mS RTP timestamps regularly and the voice is uninterrupted.  When AlarmReceiver answers a call the RTP timestamps are erratic or non-existent. The ACK tone is badly distorted (as the packets are not assemble correctly by the jitterbuffers). ****** ADDITIONAL INFORMATION ****** Changing to another SIP service provider cure the problem. There is no way to disable the SIP Service Provider's jitterbuffer. This is independent of firewall, location (internet connection) or Asterisk installation. This originally happened on an Asterisk 1.4 install, but a clean install of 1.6 gave the same issue.
Comments:	By: Grant Crawshay (saltydog256) 2010-09-12 04:18:55 The original AlarmReceiver application ran fine for 2 years prior to the Service Provider adding jitterbuffers. Jitter is actually very low, and did not affect the ACK tone being recognized by the alarm. By: Leif Madsen (lmadsen) 2010-09-13 10:41:30 This may be an issue that we can look into, but the priority of it is extremely low. I'd suggest the quicker route to resolution is going to be using a different SIP provider, or hiring a consultant to look into this issue and supply a patch. By: Leif Madsen (lmadsen) 2010-09-21 12:37:46 The issue I've just marked as related appears to try and resolve an issue similar to this one. You may wish to test the patch there and report back if it helps your situation. By: Grant Crawshay (saltydog256) 2010-09-21 18:31:16 Tested the suggested 0018010 [patch] as a possible solution, but there was no change.  The patched version still works on a SIP connection without jitter buffers. Asterisk was restarted after the patch was applied. I have changed Service Provider but this is a costly option and requires all the alarms to be reprogrammed, many which cannot be done without a visit. The use of jitter buffers is becoming more prevalent as ISPs shape their bandwidth more - so a solution would have value.  Until recently it has worked faultlessly for several years and is a good app. By: Fred van Lieshout (lieshout) 2010-09-22 10:08:05 You could try and set the transmit_silence parameter in asterisk.conf to yes. This way Asterisk will transmit a continuous stream of RTP audio frames, instead of the 100 ms tone bursts as it does with the default configuration. This may less 'confuse' the SIP provider's jitter buffer. By: Grant Crawshay (saltydog256) 2010-09-22 16:39:25 I had previously tried this with version 1.4, so I have tried again with 1.6 and it has not remedied the problem.  Can the tone burst interval be reduced to 20 ms, because this might work if it can? By: Fred van Lieshout (lieshout) 2010-09-23 13:01:38 Probably not; The alarm panel interface requirements are quite strict on the timing. Perhaps the SIP provider can be tricked by sending comfort noise frames instead of perfect silence? Have reported the issue to the provider? Because Asterisk plays it all by the rules, i.e. the timing, timestamps and sequence numbers are all ok. By: Jean-Philippe Lord (jplord) 2011-04-06 18:43:07 I started having this issue as a result of upgrading an old ATA to a newer model. The ACK tone started to be interrupted as a result. I have done extensive testing on this issue and the linked issue. 1. Made a change to the alarmreceiver app to use ast_generate_silence when waiting for tones from the panel. The RTP flow was consistent with to and from packets after this change, but the ACK tone kept being interrupted with all ATAs and the Cisco phones I have. 2. I have done a retrofit of the patch in the linked issue into 1.4.40 replacing the sendtoneburst function with built in ast functions as done in the above patch. This has fixed the ack tone ! Tested with my local DSC panel connected on LAN via my new and old ATAs. Also tested with another panel connected to an ATA remotely - remote asterisk - tun interface - IAX2 - asterisk with patched alarmreceiver. Works perfect. Can this bug be fixed into 1.4