[Freeswitch-users] How to tell if 100 Trying received
Hi, I am trying to use FS to make outgoing SIP calls. I have a number of gateways that can make the call. However, if one of them is down or has some other problem then I would like to detect that quickly. I intended to use the provisional '100 Trying' message for this... if it hasn't been received in a couple of seconds then go on and try the next gateway. But I can't find a flag/event/state which corresponds to receipt of this message. Can anyone tell me where I should be looking? I put a debug print in sofia_event_callback for every event but there doesn't seem to be one fired for this condition. Thanks in advance. {P^/ John ___ 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
Re: [Freeswitch-users] How to tell if 100 Trying received
Hi Anthony, Thanks for the reply! While waiting for my question to appear on the list yesterday (6H delay at yoda.ostag.org... is first post moderated?) I went deep into the SIP stack and figured out the solution: You just have to give NTATAG_PASS_100(1) as one of the tags for nua_create. Then you get a sofia event for it. I guess the author has made it easier since your last discussion. I have changed my mod_sofia to do this. I also added a channel flag which is set if any response has been received from the remote end (be it 100, 18X, 2XX, etc.). The flag is now tested by switch_ivr_originate to time-out a call quickly. Would you/anyone be interested in a patch to do this? If so please let me know the procedure for posting patches etc. {P^/ On Tue, 21 Apr 2009 at 10:03 -0500, Anthony Minessale wrote: > > That 100 trying is handled deep in the sip stack. > The author of sofia said it would be a big job to bring that up to the even > callback. > Someone may be able to persuade him to allow you to pass a global timeout > waiting for 100 > or something but no solution exists atm > > > On Tue, Apr 21, 2009 at 3:32 AM, John Dalgliesh wrote: > >> >> Hi, >> >> I am trying to use FS to make outgoing SIP calls. I have a number of >> gateways that can make the call. However, if one of them is down or has >> some other problem then I would like to detect that quickly. >> >> I intended to use the provisional '100 Trying' message for this... if it >> hasn't been received in a couple of seconds then go on and try the next >> gateway. >> >> But I can't find a flag/event/state which corresponds to receipt of this >> message. Can anyone tell me where I should be looking? I put a debug print >> in sofia_event_callback for every event but there doesn't seem to be one >> fired for this condition. >> >> Thanks in advance. >> >> {P^/ >> John ___ 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
[Freeswitch-users] Live Upgrade Techniques
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 ___ 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
Re: [Freeswitch-users] Live Upgrade Techniques
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 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. i...@halokwadrat.de e. michal.bieli...@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 153539 ___ 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_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.org pstn:213-799-1400 ___ 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
Re: [Freeswitch-users] Live Upgrade Techniques
I assume he's talking about hardware failures here :P But to answer the question: crashes are easy to deal with. With a crash you have lost the calls that are in progress anyway; you don't have to manage a gradual transition. Currently, since FS is quite quick to start up, I am just relaunching it immediately. But when I have a second box up and running what I'll do is just add the IP of the dead machine as another IP of the second box, and then it will take all the old machine's traffic. That is the plan anyway. I've seen some commercial boxes that use a similar trick. (I've only seen one crash that wasn't my fault. Something to do with terminating a bridge: when the first leg gets a hangup it hangs up the other leg on its own thread... which can cause problems if the other leg was doing something funky at the time. Leads to a heap corruption. Doesn't happen with MALLOC_CHECK_ set so I'm just leaving it set for now :) {P^/ On Thu, 11 Jun 2009 at 00:41 -0400, Mathieu Rene wrote: > > By reporting it on Jira so it doesn't crash anymore :D > > > On 11-Jun-09, at 12:04 AM, Michael Giagnocavo wrote: > >> How are you handling your FS box crashing? >> >> -Original Message- >> From: freeswitch-users-boun...@lists.freeswitch.org >> [mailto:freeswitch-users-boun...@lists.freeswitch.org >> ] On Behalf Of John Dalgliesh >> Sent: Wednesday, June 10, 2009 9:04 PM >> To: freeswitch-users@lists.freeswitch.org >> Subject: [Freeswitch-users] Live Upgrade Techniques >> >> >> 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 >> >> ___ >> 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 >> >> ___ >> 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 > > > ___ > 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 > ___ 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
Re: [Freeswitch-users] Live Upgrade Techniques
On Thu, 11 Jun 2009 at 10:42 -0700, Michael Collins wrote: On Thu, Jun 11, 2009 at 10:33 AM, Michael Giagnocavo wrote: Exactly. You probably want to have something like this anyways, so that when someone accidentally unplugs the system, or the disks/CPU/RAM crash, you’re not stuck. That is, until FreeSWITCH can record its internal state to some inter-machine memory so we can have hot failover. ;) I think that's going to be in 1.0.5. :) I'm still too much of a noob to be certain that's a joke :) ... but FS core already does record much of its internal state... to a DB, right? It just has to not clear that out on startup and problem solved! OTOH there will be a bit of trouble getting the internal state out of all those modules and libraries... in particular sofia :D {P^/___ 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
Re: [Freeswitch-users] Live Upgrade Techniques
Hi, On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote: > > Well, if you're running multiple machines, waiting for it to drainstop > isn't that big of a deal unless you're in some sort of hurry, right? > Give it an hour or so to drainstop, then kill 'em. Yes that's exactly what I'm trying to do. The problem is some people will only try one IP address. > Would it not be simpler to try to do something with re-invites or REFER, > assuming your endpoints support it? That was actually plan A. I already added a property in sip_profile called failover_redirect, which specifies another server to try if FS can't allocate any more sessions (e.g. too busy, paused, shutdown asap, etc.), by sending back a SIP 302 Moved Temporarily response, instead of 503 Max Calls In Progress. Turns out not all my endpoints support it :( I considered REFER too but there seems to be even less support for that. If I can't get the socket-sharing upgrade working then I will fall back to this - and peers which don't support the 302 response (or more likely, don't authorise it) will just get no service during the upgrade. > -Michael {P^/ > -Original Message- > From: freeswitch-users-boun...@lists.freeswitch.org > [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of John > Dalgliesh > Sent: Thursday, June 11, 2009 12:14 PM > To: freeswitch-users@lists.freeswitch.org > Subject: Re: [Freeswitch-users] Live Upgrade Techniques > > > I assume he's talking about hardware failures here :P > > But to answer the question: crashes are easy to deal with. With a crash > you have lost the calls that are in progress anyway; you don't have to > manage a gradual transition. > > Currently, since FS is quite quick to start up, I am just relaunching it > immediately. > > But when I have a second box up and running what I'll do is just add the > IP of the dead machine as another IP of the second box, and then it will > take all the old machine's traffic. That is the plan anyway. I've seen > some commercial boxes that use a similar trick. > ... ___ 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
Re: [Freeswitch-users] Live Upgrade Techniques
On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote: > On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote: >> On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote: >>> >>> Well, if you're running multiple machines, waiting for it to drainstop >>> isn't that big of a deal unless you're in some sort of hurry, right? >>> Give it an hour or so to drainstop, then kill 'em. >> >> Yes that's exactly what I'm trying to do. The problem is some people will >> only try one IP address. > > Clients that don't properly implement SRV/NAPTR and fail over need to be > smacked. :) (not customers but software that fails to do that) Yes I'm sure much of their software can do this but it has been set up for static numeric IPs. And getting the IP changed is a week-long process for some customers! >>> Would it not be simpler to try to do something with re-invites or REFER, >>> assuming your endpoints support it? >> >> That was actually plan A. I already added a property in sip_profile called >> failover_redirect, which specifies another server to try if FS can't >> allocate any more sessions (e.g. too busy, paused, shutdown asap, etc.), >> by sending back a SIP 302 Moved Temporarily response, instead of 503 Max >> Calls In Progress. > > You can't send a 302 to a call thats already established. Yes and I don't want to touch established calls - those calls can stay there until they drop. This is sent to new requests when switch_core_session_request fails in mod_sofia. >> Turns out not all my endpoints support it :( > > AKA broken endpoints. :) Some are broken. Some just have this feature disabled. For 'security reasons'. You know the drill. {P^/ John ___ 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