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