Re: [Freeswitch-users] Live Upgrade Techniques
Yeah I was missing this word: SCM => Stateful Call Migration. _ From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Steve Kurzeja Sent: Monday, June 15, 2009 12:17 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Live Upgrade Techniques On Sat, Jun 13, 2009 at 4:54 AM, Michael Giagnocavo wrote: Well, Nextone for instance has a database the keeps most of the state of calls, and it's replicated between the two nodes. (I seem to recall the database was GNU dbm, but I might be mistaken.) However, as of 4.3 anyways, the CDRs still get truncated when there's any kind of switchover. BTW in Nextone v4.0.x the GNU db is used for storing configuration data like storing routes & other bits which is then loaded into memory. Nextone 4.3 and above uses postgres for this configuration data. The actual call state information is stored in memory and replicated to the standby box via some custom network protocol. Stateful call migration would be a very useful feature in FS but I imagine its way down the roadmap. But as to the original question of live upgrades, having some form of load balancing proxy and then bleeding off traffic from the box you want to upgrade is the most feasible approach, as others have mentioned. Steve ___ 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 Sat, Jun 13, 2009 at 4:54 AM, Michael Giagnocavo wrote: > Well, Nextone for instance has a database the keeps most of the state of > calls, and it’s replicated between the two nodes. (I seem to recall the > database was GNU dbm, but I might be mistaken.) However, as of 4.3 anyways, > the CDRs still get truncated when there’s any kind of switchover. > > > BTW in Nextone v4.0.x the GNU db is used for storing configuration data like storing routes & other bits which is then loaded into memory. Nextone 4.3 and above uses postgres for this configuration data. The actual call state information is stored in memory and replicated to the standby box via some custom network protocol. Stateful call migration would be a very useful feature in FS but I imagine its way down the roadmap. But as to the original question of live upgrades, having some form of load balancing proxy and then bleeding off traffic from the box you want to upgrade is the most feasible approach, as others have mentioned. Steve ___ 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
Michael: We are using 5.0, and i think we tested this feature quiet a while
ago and there was no CDR problem.
Raymond: Thanks for hint i'll try it...
On Fri, Jun 12, 2009 at 6:54 PM, Michael Giagnocavo wrote:
> Well, Nextone for instance has a database the keeps most of the state of
> calls, and it’s replicated between the two nodes. (I seem to recall the
> database was GNU dbm, but I might be mistaken.) However, as of 4.3 anyways,
> the CDRs still get truncated when there’s any kind of switchover.
>
>
>
> But Nextone is a closed system with limited services. As MikeJ mentioned,
> it was discussed for FS, but it’s a LOT of work to get that state
> synchronized. And, every custom app/module would have to register and
> support recreating their state.
>
>
>
> -Michael
>
>
>
> *From:* freeswitch-users-boun...@lists.freeswitch.org [mailto:
> freeswitch-users-boun...@lists.freeswitch.org] *On Behalf Of *Saeed Ahmed
> *Sent:* Friday, June 12, 2009 7:39 AM
>
> *To:* freeswitch-users@lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Live Upgrade Techniques
>
>
>
> No idea at all,
>
> It’s a commercial SBC.
>
> I wish if we can have same functionality in FS.
>
>
>
> - Saeed
> --
>
> *From:* freeswitch-users-boun...@lists.freeswitch.org [mailto:
> freeswitch-users-boun...@lists.freeswitch.org] *On Behalf Of *Even André
> Fiskvik
> *Sent:* Friday, June 12, 2009 3:04 PM
> *To:* freeswitch-users@lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Live Upgrade Techniques
>
>
>
> Can you comment some more on how this is configured?
>
> Would it be something that could be added to the wiki in the SBC setup
> page?
>
>
>
> Best regards,
>
> Even André Fiskvik
>
>
>
> On 12. juni. 2009, at 12.16, Saeed Ahmad wrote:
>
>
>
> I've experience with a commercial SBC, these are two machines running in
> cluster mode. In that case if one SBC is going down then other will take all
> new calls including the call which were active on broken SBC (SIP only).
>
> Thats quite ideal for wholesale traffic where the SBC will never be idle.
>
> On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh wrote:
>
> 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
>
>
> ___
> Freeswitch-users mailing list
> Freeswitch-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailma
Re: [Freeswitch-users] Live Upgrade Techniques
freeswitch-users-boun...@lists.freeswitch.org wrote: >> OTOH there will be a bit of trouble getting the internal state out >> of all those modules and libraries... in particular sofia :D > > We have talked quite some about this, its a major job, easily months > of work for multiple programmers. We would love to do it but > its not > on any roadmaps at this time. > Could this be also achieved in hardware via ATCA ? en.wikipedia.org/wiki/Advanced_Telecommunications_Computing_Architecture Internet Email Confidentiality Footer - La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. - ___ 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
Saeed Ahmed wrote: No idea at all, It's a commercial SBC. I wish if we can have same functionality in FS. You could accomplish parts of this with hearbeat and ldirectord the in-session calls aren't going to go anywhere, but if the server crashes, the second one can take over the ip of the first easily enough. -Ray ___ 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
Well, Nextone for instance has a database the keeps most of the state of calls,
and it's replicated between the two nodes. (I seem to recall the database was
GNU dbm, but I might be mistaken.) However, as of 4.3 anyways, the CDRs still
get truncated when there's any kind of switchover.
But Nextone is a closed system with limited services. As MikeJ mentioned, it
was discussed for FS, but it's a LOT of work to get that state synchronized.
And, every custom app/module would have to register and support recreating
their state.
-Michael
From: freeswitch-users-boun...@lists.freeswitch.org
[mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Saeed Ahmed
Sent: Friday, June 12, 2009 7:39 AM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Live Upgrade Techniques
No idea at all,
It's a commercial SBC.
I wish if we can have same functionality in FS.
- Saeed
From: freeswitch-users-boun...@lists.freeswitch.org
[mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Even André
Fiskvik
Sent: Friday, June 12, 2009 3:04 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Live Upgrade Techniques
Can you comment some more on how this is configured?
Would it be something that could be added to the wiki in the SBC setup page?
Best regards,
Even André Fiskvik
On 12. juni. 2009, at 12.16, Saeed Ahmad wrote:
I've experience with a commercial SBC, these are two machines running in
cluster mode. In that case if one SBC is going down then other will take all
new calls including the call which were active on broken SBC (SIP only).
Thats quite ideal for wholesale traffic where the SBC will never be idle.
On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh
mailto:jo...@defyne.org>> wrote:
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<mailto: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<mailto: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
No idea at all,
Its a commercial SBC.
I wish if we can have same functionality in FS.
- Saeed
_
From: freeswitch-users-boun...@lists.freeswitch.org
[mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Even
André Fiskvik
Sent: Friday, June 12, 2009 3:04 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Live Upgrade Techniques
Can you comment some more on how this is configured?
Would it be something that could be added to the wiki in the SBC setup page?
Best regards,
Even André Fiskvik
On 12. juni. 2009, at 12.16, Saeed Ahmad wrote:
I've experience with a commercial SBC, these are two machines running in
cluster mode. In that case if one SBC is going down then other will take all
new calls including the call which were active on broken SBC (SIP only).
Thats quite ideal for wholesale traffic where the SBC will never be idle.
On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh wrote:
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
___
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
Can you comment some more on how this is configured?
Would it be something that could be added to the wiki in the SBC setup
page?
Best regards,
Even André Fiskvik
On 12. juni. 2009, at 12.16, Saeed Ahmad wrote:
I've experience with a commercial SBC, these are two machines
running in cluster mode. In that case if one SBC is going down then
other will take all new calls including the call which were active
on broken SBC (SIP only).
Thats quite ideal for wholesale traffic where the SBC will never be
idle.
On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh
wrote:
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
___
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
I've experience with a commercial SBC, these are two machines running in
cluster mode. In that case if one SBC is going down then other will take all
new calls including the call which were active on broken SBC (SIP only).
Thats quite ideal for wholesale traffic where the SBC will never be idle.
On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh wrote:
> 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
>
___
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
Re: [Freeswitch-users] Live Upgrade Techniques
>> 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. Right, so if you have a proxy in front that is handling this, it should be no problem. ___ 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 Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote: 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. Clients that don't properly implement SRV/NAPTR and fail over need to be smacked. :) (not customers but software that fails to do that) 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. Turns out not all my endpoints support it :( AKA broken endpoints. :) I considered REFER too but there seems to be even less support for that. ACK really? thats sad! 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 Brian West br...@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com ___ 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
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.
Would it not be simpler to try to do something with re-invites or REFER,
assuming your endpoints support it?
-Michael
-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.
(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
___
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
That's exactly what I do. Between dispatcher and FLAGS/GFLAGS this is easy to do in OpenSIPS/SER. On Thu, Jun 11, 2009 at 12:54 PM, 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. > -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com ___ 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 Jun 11, 2009, at 2:24 PM, John Dalgliesh wrote: > 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 We have talked quite some about this, its a major job, easily months of work for multiple programmers. We would love to do it but its not on any roadmaps at this time. Mike ___ 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, Jun 11, 2009 at 11:24 AM, John Dalgliesh wrote: > 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! > It was a joke. :) ___ 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
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
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
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. :)
> -Michael
>
>
>
> *From:* freeswitch-users-boun...@lists.freeswitch.org [mailto:
> freeswitch-users-boun...@lists.freeswitch.org] *On Behalf Of *Anthony
> Minessale
> *Sent:* Thursday, June 11, 2009 10:55 AM
> *To:* freeswitch-users@lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Live Upgrade Techniques
>
>
>
> 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
>
>
___
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
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. ;)
-Michael
From: freeswitch-users-boun...@lists.freeswitch.org
[mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Thursday, June 11, 2009 10:55 AM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Live Upgrade Techniques
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<mailto:i...@halokwadrat.de>
e. michal.bieli...@halokwadrat.de<mailto:michal.bieli...@halokwadrat.de> | w.
www.halokwadrat.de<http://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<mailto: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<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net<http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org<mailto:googletalk%3aconf%2b...@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
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
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
smime.p7s
Description: S/MIME cryptographic signature
___
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
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
Re: [Freeswitch-users] Live Upgrade Techniques
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] 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
