Proposal to seperate qualify & keep alive

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
_______________________________________________
--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

On Mon, 2006-06-26 at 20:32 +0200, Johansson Olle E wrote:

> 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.

That seems reasonable. The only comment I have is that
solution makes
things a bit messy. Already qualify= when combined with nat=
is being
used for a purpose that it wasn't originally intended which
has lead to
some confusion over its purpose and how it works.

If you are proposing something like ignorequalify=yes then
we end up
with:

nat=yes
qualify=200
ignorequalify=yes

which is counter intuitive.

Perhaps the answer is to make nat= into an integer
(nat=yes/no/integer)
for keep alive?

So then we have:

nat=200
qualify=yes

would mean, send out a keep-alive (of some kind) every 200ms
and qualify
would be unchanged.

The only "gotcha" is this means only devices
behind nat could be "kept
alive" because you could never have nat=no and still
send keep-alives. 

This is fine if nat is the only reason why we would ever
want to send
keep-alives.

Just sort of brain storming here. Comments are welcome.

John


_______________________________________________
--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