Summary:	ASTERISK-05739: [request] T1/A timers tweakable on a per-peer basis
Reporter:	twisted (twisted)	Labels:
Date Opened:	2005-11-29 23:54:27.000-0600	Date Closed:	2006-02-09 08:23:29.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I recently spent a couple hours debugging why another sip server on the same lan as asterisk would fail to pass calls, and noticed that we based our t1 timer off of our qualify time, or, if none was there, 4ms.  If this was tweakable in the sip stack, we could alot for db access times etc, especially when our network latency (again, the qualify/t1 time) is less than 20ms or so.   For example, in this scenario, the qualify response time was 1ms.   Since the DB lookup for auth, and the md5 check, and the response generation took more than 1 ms, and even more than 64ms (6th retransmit), we timed out the call and shut it down.   Qualifying peers is a necessity if you're going to be doing failover routes, and redundant servers with asterisk acting as the controller, so we absolutely want to keep that in place.  The only way to get around this was to either adjust the t1 timer in the code, or to disable qualify, which only barely fixed the problem (responded within the 3rd retry).   If this were tweakable within the configs, and perhaps only as an advanced option, we could ignore the timer as set by the qualify statement, and use our own, to allow for such transactions to take place. What i'm proposing is we create the following tweakable timer options in sip.conf: timer_t1 = x and timer_a = x This way we can still go by the t1 timer for latency, but allow for a longer lag based on our activity, or, just allow for a longer timer for activity, but also alot for possible intermittant latency between qualification, by altering our modifier timer.   I don't know in what time I will have to devote to this, nor do I have a very good test environment to set this up in, so I'm gonna let this sit for a couple days, and if anyone thinks this is a good idea besides myself, and has the time/resources to devote to it, feel free to impliment and post the patch here for review/testing.
Comments:	By: Olle Johansson (oej) 2005-12-01 17:43:02.000-0600 Good suggestion. Will look at this, but not at top priority. Default T1 is actually 1 sec. By: Brett Nemeroff (brettnem) 2005-12-05 12:14:23.000-0600 For what it's worth RFC 2543 states: Default values for T1 and T2 are 500 ms and 4s, respectively. Clients MAY use larger values, but SHOULD NOT use smaller ones. Since Asterisk bases T1 off qualify time, doesn't this suggest that it is VERY LIKELY that T1 will be < 500ms? Should this be reported as a new bug? By: Olle Johansson (oej) 2005-12-05 14:59:21.000-0600 RFC 2543 is deprecated and very old. Please don't use that as a reference. RFC 3261 states: "The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED ) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used." So we need a lower treshold general setting as well a per-peer settings. However, the SHOULD NOT is changed to NOT RECOMMENDED. Having lower values in most cases improves your communication. By: Brett Nemeroff (brettnem) 2005-12-05 15:03:44.000-0600 So what happens when T1 is 1ms? That's what happened to me; based on a really low qualify. By: twisted (twisted) 2005-12-05 18:14:10.000-0600 That's why we need the configurable option: to follow the RECCOMENDED increase in the T1 timer, based upon the fact that we KNOW it will take longer than 1ms to generate and recieve the response. By: Brett Nemeroff (brettnem) 2005-12-05 18:23:36.000-0600 Although I think tweakable T1 timers are a good idea, shouldn't the "automatic" T1 that is set per the qualify time have a minimum value of 500ms and a maximum of the Max for an OPTIONS reply (I think that's 2000ms). Seems like a shorter qualify shouldn't go UNDER the RFC's RECOMMENDATION. Wasn't the original idea (and the idea the RFC suggests) that if we KNOW we have a high latency link, we can INCREASE T1 accordingly? The way it is now, also allows it to shorten T1 which can frequently go against the RFC's RECOMMENDATION. By: Brett Nemeroff (brettnem) 2005-12-12 13:05:26.000-0600 All, I patched my chan_sip so that basically if qualify time was less than 100ms that it'd just use 100ms as T1. This was important because calls being sent to SER would return OPTIONS in about 2ms. But an INVITE would take about 120ms (several database dips involved). What I'm looking for is a little feedback on my solution. I'd like to submit a usable patch. I was thinking of just making the 100ms a defined constant at the top of the file. Then I thought, I might try to make it defined in sip.conf. I'm not much of a coder, but I thought I'd give it a whirl and see if I can. This way, we can let Asterisk cleverly adjust T1 for slower peers, but won't let it get out of hand for faster peers. Thoughts? By: Clod Patry (junky) 2006-01-03 20:43:07.000-0600 Feel free to submit your patch, at least what you have, and you'll probably get any feedbacks on your code. By: Olle Johansson (oej) 2006-01-26 02:26:01.000-0600 brettnem: As a policy we do not change default behaviour in a release. So Adding a "min-T1" option to sip.conf is a good thing, but the source needs to default to wherever it is now. Take a try at coding this, if you have any questions or want feedback, I am usually available in the IRC channel, European time :-), or on e-mail. By: Olle Johansson (oej) 2006-01-30 12:51:42.000-0600 Added a minimum T1 timer as a global channel setting in svn trunk. peer/user option is still missing. Keeping report open while waiting for patch :-) By: Olle Johansson (oej) 2006-02-09 08:22:59.000-0600 Added some functionality to svn trunk. Closing this for now. Will happily re-open when there's a patch available. Thanks.