VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
brian at freeswitch.org
Guest
|
 Posted: Thu Jun 11, 2009 10:58 pm Post subject: [Freeswitch-users] Live Upgrade Techniques |
 |
|
On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
| Quote: |
Hi,
On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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)
| Quote: |
| Quote: | 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.
| Quote: |
Turns out not all my endpoints support it 
|
AKA broken endpoints.
| Quote: |
I considered REFER too but there seems to be even less support for that.
|
ACK really? thats sad!
| Quote: |
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.
|
Brian West
brian@freeswitch.org (brian@freeswitch.org)
-- Meet us at ClueCon! http://www.cluecon.com |
|
| Back to top |
|
 |
mgg at giagnocavo.net
Guest
|
| Posted: Thu Jun 11, 2009 11:18 pm Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
| Quote: | | Quote: | 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 |
|
| Back to top |
|
|
johnd at defyne.org
Guest
|
| Posted: Fri Jun 12, 2009 1:29 am Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
| Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 |
|
| Back to top |
|
|
saeedahmad1981 at gmai...
Guest
|
| Posted: Fri Jun 12, 2009 5:19 am Post subject: [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 <johnd@defyne.org (johnd@defyne.org)> wrote:
| Quote: | On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
|
| Quote: | | Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 (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
|
|
|
| Back to top |
|
|
grevenx at me.com
Guest
|
| Posted: Fri Jun 12, 2009 8:05 am Post subject: [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:
| Quote: | 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 (johnd@defyne.org)> wrote:
| Quote: | On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
|
| Quote: | | Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 (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 (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
|
|
|
| Back to top |
|
|
saeedahmad1981 at gmai...
Guest
|
| Posted: Fri Jun 12, 2009 8:41 am Post subject: [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 (johnd@defyne.org)> wrote:
On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
|
| Quote: | | Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 (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 (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 |
|
| Back to top |
|
|
mgg at giagnocavo.net
Guest
|
| Posted: Fri Jun 12, 2009 11:59 am Post subject: [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-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 (johnd@defyne.org)> wrote:
On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
|
| Quote: | | Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 (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 (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 |
|
| Back to top |
|
|
intralanman at freeswi...
Guest
|
| Posted: Fri Jun 12, 2009 1:15 pm Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
Saeed Ahmed wrote: | Quote: | v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} <![endif]--> st1\:*{behavior:url(#default#ieooui) } <![endif]-->
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 |
|
| Back to top |
|
|
Claudio.Cavalera at it...
Guest
|
| Posted: Mon Jun 15, 2009 3:34 am Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
freeswitch-users-bounces@lists.freeswitch.org wrote:
| Quote: | | Quote: | OTOH there will be a bit of trouble getting the internal state out
of all those modules and libraries... in particular sofia 
|
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 |
|
| Back to top |
|
|
saeedahmad1981 at gmai...
Guest
|
| Posted: Mon Jun 15, 2009 7:03 am Post subject: [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 <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
| Quote: |
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 (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (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 (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 (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (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 (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 (johnd@defyne.org)> wrote:
On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote:
| Quote: | On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote:
|
| Quote: | | Quote: | On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote:
| Quote: |
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!
| Quote: | | Quote: | | Quote: | 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.
| Quote: | | Quote: | 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 (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 (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 (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
|
|
|
| Back to top |
|
|
steve.kurzeja at gmail...
Guest
|
| Posted: Mon Jun 15, 2009 11:19 am Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
On Sat, Jun 13, 2009 at 4:54 AM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
| Quote: |
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 |
|
| Back to top |
|
|
saeedahmad1981 at gmai...
Guest
|
| Posted: Mon Jun 15, 2009 11:32 am Post subject: [Freeswitch-users] Live Upgrade Techniques |
|
|
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 (mgg@giagnocavo.net)> wrote: | Quote: |
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 |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
