Summary:	ASTERISK-03025: [patch] Permit retransmission interval to be configured
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2004-12-17 19:27:39.000-0600	Date Closed:	2011-06-07 14:05:01
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20041217__sip_retrans.diff.txt ( 1) Debug_session_1215_1920.acp
Description:	Adds option "retransmit" to peers that allows number of ms before a retransmit is attempted to be specified. ****** ADDITIONAL INFORMATION ****** This is specifically needed for a system whose primary link is over a satellite, where the ping time is normally 540ms and the loss of a single packet (along with timeout) drops the pingtime to 2500 ms, which is normally unacceptable.  Note that this is somewhat dangerous, for example, if the retransmit time is lower than the time it takes for a packet to complete a roundtrip, but it is vital for systems which have such a long latency.
Comments:	By: Tilghman Lesher (tilghman) 2004-12-17 23:42:25.000-0600 Disclaimer on file. By: Mark Spencer (markster) 2004-12-18 09:04:35.000-0600 This would seem only to make the change for a poked peer.  I think this timer will have to be a parameter supplied to user, peer, pvt, and possibly global (e.g. trustrpid for example).  drumkilla has a patch which is going to change those structures to change lots of ints into bitfields though, so one of you will likely break the patch of the other :) By: Tilghman Lesher (tilghman) 2004-12-19 11:49:46.000-0600 It's possible that this patch, set to retransmit=600 or the existing option qualify=5000 causes CPU usage to go to 100%.  I'll update this bug with further information as I find it. By: cloudsurfer (cloudsurfer) 2004-12-19 12:20:09.000-0600 I live in Samoa where we are only able to get to the outside world by satellite.  I am a subscriber of Australian Technology Partnership (ATP) which uses Asterisk.  My ISP has blocked pings but I reliably receive responses to my packets in about 1150 ms.  Since a recent upgrade of their software I have been unable to make outbound calls.  I have attached a trace of one session made with "Analyzer" by NetGroup, Italy (Debug session 1215 1920.acp).  This can be read with a text editor but the times are encoded and not legible.  Obviously I do not have access to the code to know what version of Asterisk ATP is running.  Is this likely to be the same bug?  A reliable sequence would appear to be: I send an INVITE, a second later I have heard nothing so send another. with my RTT of 1150ms I then get a 407 Prox Authority Required.  I send an ACK and a new INVITE. Approximately 1 second after receiving the 407 Prox I get a 503 Unavailable with a CSeq of the INVITE which caused the 407 Prox. Next I get another 407 Prox timed as if it is a response to my second INVITE.  I do not reply to that as I have already sent a new sequence of INVITES. With the second sequence of invites the same timeout occurs and this is then repeated until the call times out.  Very occasionally I get through. So, is this the same bug or is mine new? edited on: 12-19-04 22:13 By: Olle Johansson (oej) 2004-12-22 12:49:43.000-0600 Corydon: Please, please also update sip.conf.sample By: Mark Spencer (markster) 2004-12-26 18:57:00.000-0600 What's our story here, is there an update? By: Tilghman Lesher (tilghman) 2004-12-26 21:40:43.000-0600 I'm closing this bug pending further tests to resolve the problem of CPU going to 100%.