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
|