Thanks for the hint, we are doing this with SIP SRV records already. Concerning pause: There is a command to pause the media on a given channel. Is there another command to stop FS responding on requests?
Best regards Peter Michael Jerris schrieb: > How are your endpoints pointing to the 2 boxes? Using dns srv > records. I think the cleanest way is to change the srv records, do a > "pause" on freeswitch 1, wait for all calls and registrations to fall > off of box 1, all new registrations and calls will then be to box 2, > once it is clear you can take box 1 down for maint. > > Mike > > On Nov 20, 2008, at 12:23 PM, Peter P GMX wrote: > > >> Thanks, David, >> >> here are my coments: >> >> >>> (a) can you not do something where you deregister them one at a time, >>> >> or in batches, on FS1 >> >>> while registering them on FS2? >>> >> A batch is a good method, and reduces the downtime of course >> >> >>> (b) use method 1, but set a short period for re-registration >>> initially, >>> >> and then increase it once FS1's >> >>> taken down? >>> >> another good method, but forced to re-register all 5000 gateways, this >> produces a high load, and anyway FS is spreading re-registers over the >> expires time period (by trying out, this deos not seem to be >> documented >> somewhere?). >> >> <(c) use method 1, but take FS1 off the network before taking it down >> (e.g. ifdown eth0, route delete default..?) >> >>> so that its unregistration attempts don't reach the gateways? >>> >> This will drop existing calls. We thought about adding another >> firewall >> rule, but we would like to keep it simple and stable in a production >> environment. >> >> Best regards >> Peter >> >> David Knell schrieb: >> >>> Hi Peter, >>> >>> A quick brainstorm:- >>> (a) can you not do something where you deregister them one at a time, >>> or in batches, on FS1 >>> while registering them on FS2? >>> (b) use method 1, but set a short period for re-registration >>> initially, and then increase it once FS1's >>> taken down? >>> (c) use method 1, but take FS1 off the network before taking it down >>> (e.g. ifdown eth0, route delete default..?) >>> so that its unregistration attempts don't reach the gateways? >>> >>> Cheers -- >>> >>> Dave >>> >>>> I have the following scenario for a 2-server FS system with failover >>>> functionality: >>>> >>>> * I have a number of Gateways registered at FS1 >>>> * I have another number of Gateways registered at FS2 >>>> * In case I want to do maintenance on FS1 I would like all >>>> external gateways to be registered on FS2 and then shutdown FS1 >>>> * This is not of a problem if I have only a handful of gateways, >>>> but in our case they're about 10.000 >>>> * The goal is to minimze downtime, when I migrate e.g. 5000 >>>> gateways from FS1 to FS2 >>>> >>>> * 1st method: The normal way would be to register (via xml-rpc or >>>> socket) the new Gateway on FS2 and then deregister it on FS1. >>>> FS1 sends an unregister (register with expires=0) to the >>>> gateway though (after the register from FS2), so this Gateway >>>> unfortunately no longer sends calls to any of the 2 FS. >>>> * 2nd method: The other way is to deregister them first on FS1 >>>> and then register them all on FS2. Because deregistering and >>>> registering takes time with ~5000 Gateways (+ we have to ensure >>>> that the new register has to take place after unregister), this >>>> results in a significant downtime. >>>> >>>> So my question: Is there any way to suppress deregister messages to >>>> the gateway? >>>> >>>> Best regards >>>> Peter >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Freeswitch-users mailing list >>>> [email protected] >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>>> http://www.freeswitch.org >>>> >>>> >>> -- >>> David Knell, Director, 3C Limited >>> T: 020 8114 8901 F: 020 3002 7257 M: 001 415 630 3031 >>> http://www.3c.co.uk >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeswitch-users mailing list >>> [email protected] >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >>> >>> >> _______________________________________________ >> Freeswitch-users mailing list >> [email protected] >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> > > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
