[asterisk-dev] Proposal to seperate qualify & keep alive

[Loic DIDELOT]

Hi,
I actually like the idea of separating keep-alives from the qualify.
Defining the frequency of the packages is very important to adapt the
asterisk behaviour according to the customers one has. This would solve
many of our problems. Are there more people who need this? Is there a
way to get this developed and include it in asterisk 1.4? voipGATE would
be interested in cosponsoring this feature but only if it will be
included in the 1.4 stable release and if available for IAX as well.

Best regards,
Loic Didelot.


On Mon, 2006-06-26 at 13:06 -0700, John Todd wrote:
> At 8:32 PM +0200 6/26/06, Johansson Olle E wrote:
> >26 jun 2006 kl. 19.23 skrev John Lange:
> >
> >>In the current implementation, qualify sends out a SIP request at the
> >>specified interval and if it doesn't receive a reply within that same
> >>interval asterisk flags the peer as unreachable.
> >>
> >>This also acts as a sort of keep-alive for devices behind NAT when
> >>combined with the nat=yes parameter. The regular flow of SIP packets
> >>keeps the NAT connective alive for the device behind the firewall.
> >>
> >>The problem is, these are two very different concepts and at times it
> >>would be nice if we could separate the two.
> >>
> >>Specifically; we have some clients with devices behind nat and
> >>satellite. Their nat and satellite requires a more-or-less constant flow
> >>of packets to keep the connection alive.  However due to the quirky
> >>nature of satellite combined with long round-trip times the qualify
> >>option needs to be set high (5000ms) or Asterisk won't send calls to the
> >>client.
> >>
> >>In fact we would like to set qualify=no because often the client appears
> >>to be very lagged when the satellite perceives the connection to be idle
> >>(apparently it queues packets until it has a bunch and sends them in
> >>groups) but if you initiate a call the lag drops immediately to an
> >>acceptable level (800ms).
> >>
> >>But if we set qualify=no then the firewall closes the connection and
> >>they can't receive any calls.
> >>
> >>So, the question is; is it reasonable to undertake the implementation of
> >>a keep alive for sip clients?
> >>
> >>Any thoughts on how this should be done? SIP NOTIFY or would something
> >>else make more sense?
> >
> >I don't see a reason for changing method. We should propably find a way
> >to override and be able to dial out regardless of the monitoring status.
> >That seems like a simple fix.
> >
> >/O
> 
> I would actually agree that the two functions should be separated.  I 
> find myself often in the same position, where the use of "qualify=" 
> is used as a NAT mapping tool only, and I don't particularly care 
> about the actual milliseconds of response time to the request.  I 
> also think we would be well-served to make these timers a bit more 
> flexible, since right now everyone is in the "same bucket" as far as 
> timing goes for how frequently OPTIONS requests are sent.  I'd like 
> to be more aggressive for foolish people who have poorly-configured 
> firewalls that close NAT UDP sessions after 30 (or fewer) seconds, 
> and currently the only way to do this is to change the code to send 
> ALL of my OPTIONS requests much more frequently, which eventually 
> leads to a huge amount of nonsense noise on my network to solve for a 
> few poorly behaved clients.
> 
> SER sends "bogus" packets fairly frequently as part of it's NAT 
> module, and this seems to work well.
> 
> The current method in Asterisk has a few downsides:
> 
>    1) OPTIONS packets are larger than just simple UDP keepalives (but 
> not by much)
> 
>    2) OPTIONS requests require stateful storage of status, so if I 
> have 6000 SIP "peers" each using "qualify=", then Asterisk needs to 
> store a fairly large amount of memory aside to track each one of 
> those transmitted OPTIONS statements, and if at any time there are 
> 10% of those peers which are slow to respond (say, two cycles) then I 
> have a huge backlog of stateful requests in queue.  If a UDP packet 
> that did not require return receipt was sent just for NAT keepalives, 
> this would be much lighter weight, and we could move the "heavier" 
> OPTIONS request interval to a larger time value.
> 
>    3) The current OPTIONS request is bursty, and all of the OPTIONS 
> are sent in 60 second intervals using the same interval timer.  This 
> is really ugly, with big spikes of data every 60 seconds.  This 
> should be probably distributed so that each entry has it's own timer.
> 
> 
> I propose a different way to do this, with an example out of sip.conf 
> listed below.  I know that this will require the creation of memory 
> space for each of these timers (and a whole slew of timer-related 
> issues internally to Asterisk) but it does seem like it would be more 
> flexible to do it this way and may reduce the amount of processing 
> for the OPTIONS requests if just lightweight UDP can be sent for NAT 
> translations.  With this method, I could possibly crank up the 
> OPTIONS qualifiers to something like 5 minutes, but leave the NAT 
> translation keepalives down at 20 seconds and hopefully see less load 
> on my Asterisk servers and network with large numbers of REGISTER'ed 
> hosts.  This is all kind of pointless for 20 users, but Asterisk is 
> no longer being used only for sites with double or triple-digit 
> numbers of users, and it makes a difference at scale.
> 
> 
> ; Hypothetical sip.conf settings for "new" qualify/NAT timers
> ;
> ; Send OPTIONS requests to measure latency (450ms in this ex.)
> ;  every 120 seconds.  The qualifytime timer starts based
> ;  on the time the last REGISTER was successfully parsed, or
> ;  if a static IP host, then based on the time the entry was
> ;  parsed in this file plus a random number of seconds not
> ;  greater than the value in "qualify=".  If "qualify="
> ;  is non-zero but there is no "qualifytime=", then default
> ;  of qualifytime is 60 seconds.  If "qualifytime=" is
> ;  non-zero but there is no "qualify=", then qualifytime is
> ;  500 milliseconds.
> qualify=450
> qualifytime=120
> ;
> ; Send very minimal, one-way packets to hosts in order
> ;   to keep NAT translations open.  Send once every 20 seconds.
> ;   No default value.
> nat-keepalive=20
> ;
> 
> 
> JT
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev