[asterisk-dev] more granular control of TImer T1

[Damon Estep]

From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Olle E. Johansson
Sent: Wednesday, November 13, 2013 1:30 AM
To: Asterisk Developers Mailing List
Cc: Olle E Johanson
Subject: Re: [asterisk-dev] more granular control of TImer T1


On 12 Nov 2013, at 17:34, Damon Estep <damon at soho-systems.com<mailto:damon at soho-systems.com>> wrote:


Originally posted to https://issues.asterisk.org/jira/browse/ASTERISK-22841

Feedback was that this is more of a dev discussion than a bug.

The definition of timer t1min is "Minimum roundtrip time for messages to monitored hosts" the key word is "monitored", which means qualify= is set to yes or a numeric value.

The value of t1min is being evaluated when the timert1 value for a non-monitored host is read from the configuration and a warning is logged and timert1 is set to global_timert1 if the configured timert1 value for the non-monitored host is less than t1min.

t1min should not apply to non-monitored hosts by definition and the user should be able to set a timer1 value that is less than t1min for a non-monitored host.

If T1 is set in the config for a monitored host it should be used instead of the last qualify result.

A case where this is needed is when there is a SBC in front of the monitored host. The SBC may answer the OPTIONS query directly and not pass it to the host which is behind the SBC. In this case the lastms is set to the RTT to the SBC, which is not indicative of the actual RTT for an INVITE which is proxied to the host (which adds additional delay).

Setting T1 to the last measured OPTIONS RTT is a problematic for another reason as well. Any amount of jitter in the network can result in unneeded retransmits. In practice T1 is set to the estimated RTT which is not always the last RTT but rather the average RTT plus an allowance for network jitter. There are many reasons when a user might want to adjust timer T1 on a peer by peer basis. They should not be forced to accept a global minimum or system calculated T1 regardless of whether qualify is on. Qualify is used in other ways by many users, not just as a means of setting T1.

The current timer configuration could be improved by adding a T1 jitter configuration value (in addition to or in place of T1min, which would be added to lastms to set T1. For example, if the lastms for a peer was 40ms and the T1jitter setting was 20, then T1 would be set to 60ms.

Comments or thoughts?

I don't really follow you here. Originally T1min was not used at all for non-monitored hosts - is it today?

T1min was used as the lowest possible value of T1 for a monitored host - with qualify=yes. If that's changed, we need to re-review that.

Now, the second part is more interesting. Setting T1 to the last value is better than nothing, but what you suggest are improvements to the code that I like.
Setting T1 to an average or implementing some sort of tolerance of jitter sounds like a good way forward. Looking forward to seeing code for this!

/O

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131113/0c99f4ee/attachment-0001.html>