OK thanks that is what I thought the general way of doing it would be. But it seems a bit wasteful to have that SIP proxy there the whole time especially when I am using FS in the role of an SBC. The problem with the graceful restart of course is that you have to wait for the calls count to get to zero, which may never happen. It's 3:30am here in Sydney now and I just checked FS: 20 calls in progress still! So what I plan to do is add a '--upgrade' cmd line arg to FS. This will make the new instance contact the old one on a unix socket and receive a dup of its SIP socket fd(s) via a SCM_RIGHTS sendmsg. It will use those for sending and the unix socket for receiving. Meanwhile the old instance will pass any packets with unknown Call-Ids over the unix socket to the new instance, instead of handling them itself. When the old instance has no calls left, it shuts down. The new instance detects the unix socket is closed and switches to reading from the SIP socket (which would have buffered any unread packets - so nothing is lost). Sound good? I realise this will be 90% in libsofia but I've read teh code and it seems very do-able. Anyone interested in my changes will of course be most welcome to them. The runner-up approach I considered was to make a kernel module that extends iptables with a filter that can extract the Call-Id and look it up in a table that is somehow populated from FS. Maybe this exists already? Kind of a SIP proxy lite that can be enabled on the server machine when needed. Anyway that lost out as it's more work and even less portable. {P^/ John On Thu, 11 Jun 2009 at 11:54 -0500, Anthony Minessale wrote:
or you can put a sip proxy in front of 2 boxes where you can control the flow of traffic. when you want to upgrade one, take all the traffic off of it by forcing all calls to the other box, upgrade it then shift the traffic to the new one. if that goes well, upgrade the other one too.
On Thu, Jun 11, 2009 at 5:47 AM, Michal Bielicki <michal.bielicki@halo2.pl>wrote:
Am 11.06.2009 um 05:04 schrieb John Dalgliesh:
Hi,
I am slowly gaining confidence using FreeSWITCH in production, but there is one issue that I'm still wondering about: how are people upgrading their FreeSWITCH installation binaries without dropping all current calls?
So far I have been upgrading in the dead of night, after pausing for 5 minutes then dropping the stragglers, but this is hardly ideal.
What I would like to do is to run an upgraded instance of FreeSWITCH on the same machine, and have it handle all new call packets, whereas the old instance continues to handle the existing call packets, until there are no more old calls left.
I can think of about seven ways to accomplish this, but before I dive into the code I thought I'd better ask what everyone else has been doing :)
(The only standard way I can think of doing this is to have a SIP proxy sitting in front of FS the whole time, just to handle these upgrade windows. It seems like a bit of a waste.)
So how are you handling your FS software upgrades?
{P^/ John
We use freeswitch on solaris and just upgrade it to a new zfs which gets remounted to the old place and freeswitch gracefully restartet. On failure we can allways do a rollback, which takes between 2 and 10 seconds, so the dwntime is pretty acceptable.
Michal Bielicki Leiter der Niederlassung HaloKwadrat Sp. z o.o. Niederlassung Kleinmachnow Eingetragen im Handelsregister beim Amtsgericht Potsdam, HRB21422P Ust.Id.: DE261885536 Geschaeftsfuehrer: Aleksander Wiercinski Meiereifeld 2b, 14532 Kleinmachnow t. +49 33203 263220 f. +49 33203 263229 sip. info@halokwadrat.de e. michal.bielicki@halokwadrat.de | w. www.halokwadrat.de Hauptgeschäftsstelle: Halo Kwadrat Sp. z o.o. ul. Polna 46/14 00-644 Warszawa, Polen EIngetragen im HRB Warszawa, KRS 0000153539
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400