[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
