Hi, Suppose you have 2 identical Asterisk servers and 1 alias IP address that you assign to either one, according to system failures, etc. Also suppose that all SIP clients register requests go to the alias IP address. Imagine server1 fails and server2 gets the alias IP address. Correct me if I'm wrong but I would have to wait at least 60 seconds before most SIP clients re-register to server2 and that server2 knows that they are actually "on-line" so calls can be routed to them. How can I minimize this time lapse? Can Asterisk "notify" all SIP clients in its sip.conf that they need to acknowledge being on-line or not (thus forcing re-registration in my scenario)? Thanks, Vieri
Tuesday, February 8, 2011, 5:07:29 PM, Vieri wrote:> How can I minimize this time lapse? Can Asterisk "notify" all SIP > clients in its sip.conf that they need to acknowledge being on-line > or not (thus forcing re-registration in my scenario)?If you have two identical servers online, it is better to make a HA sollution. Sorry, I haven't made HA Asterisk yet, I can not help more. -- Best regards, Gergo mailto:csibra at gmail.com
Hi,
Thats very simple.
Use sip realtime registration with mysql and heartbit to control switiching.
Regards,
Carlos M Cruz
Em 2011/02/08 16:07, "Vieri" <rentorbuy at yahoo.com> escreveu:
Hi,
Suppose you have 2 identical Asterisk servers and 1 alias IP address that
you assign to either one, according to system failures, etc.
Also suppose that all SIP clients register requests go to the alias IP
address.
Imagine server1 fails and server2 gets the alias IP address. Correct me if
I'm wrong but I would have to wait at least 60 seconds before most SIP
clients re-register to server2 and that server2 knows that they are actually
"on-line" so calls can be routed to them.
How can I minimize this time lapse? Can Asterisk "notify" all SIP
clients in
its sip.conf that they need to acknowledge being on-line or not (thus
forcing re-registration in my scenario)?
Thanks,
Vieri
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110208/ce9769a8/attachment.htm>
On Tue, Feb 8, 2011 at 8:07 AM, Vieri <rentorbuy at yahoo.com> wrote:> Suppose you have 2 identical Asterisk servers and 1 alias IP address that you assign to either one, according to system failures, etc. > Also suppose that all SIP clients register requests go to the alias IP address.This is a typical setup for two node HA. Just be careful when clustering only two servers.> Imagine server1 fails and server2 gets the alias IP address. > Correct me if I'm wrong but I would have to wait at least 60 seconds before > most SIP clients re-register to server2 and that server2 knows that they are > actually "on-line" so calls can be routed to them.It depends on your configuration. If you use Asterisk Realtime to store SIP registrations, then the database will contain information on how to contact the device (fullcontact, ipaddr, and port fields). Then on a failover, Asterisk will do a lookup for the peer in the database, find the needed information and dial the device. Of course any registrations that happen before being written right before the server fails may not work. Also make sure to use the latest version of Asterisk as there was a bug where fullcontact wasn't saved correctly.> How can I minimize this time lapse? Can Asterisk "notify" all SIP > clients in its sip.conf that they need to acknowledge being on-line > or not (thus forcing re-registration in my scenario)?In the above scenario, I can kill Asterisk, start it again, and place a call from two devices that have not registered again. So, the best timeout is your dead time detection and failover startup time. -Jonathan