Yes, it might be a problem in our situation. We have three Asterisk boxes in a
'cluster'. The sip.conf is identical on all three. In that case, all three of
the Asterisk boxes in our cluster are going to send sip options messages to the
phones, which is silly.
Only the Asterisk box that a phone is registered on needs to send the sip
notify messages. The rest are a waste. I'm not sure how we'd work around this.
We may just have to make do with the caller of an unavailable phone getting
ringback until the dial timeout occurs.
Doug.
-----Original Message-----
From: Alexander Lopez [mailto:[EMAIL PROTECTED]
Sent: Mon 8/14/2006 9:46 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc:
Subject: RE: [asterisk-users] SIP Qualify
Qualify does what the name implies "qualifies the connection' It pools
every 60s but it calculates he time it took for the packet to reach the
end device. If the endpoint has a latentcy > than the qualify parameter,
* considers the endpoint unreachable. This does not however address the
point you made in another post about RINGING before the INVITE. It is
still possible to have a phone go dead in the 60sec between qualify
re-checks.
There are several post in history about qualify and it sending LARGE
amounts of traffic to endpoints. I think it was John Todd that was the
OP on the subject IIRC.
SNIP
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
