[Freeswitch-users] Live Upgrade Techniques

[Saeed Ahmad]

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 at 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 at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Saeed Ahmed
> *Sent:* Friday, June 12, 2009 7:39 AM
>
> *To:* freeswitch-users at 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 at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Even André
> Fiskvik
> *Sent:* Friday, June 12, 2009 3:04 PM
> *To:* freeswitch-users at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090615/e08ebdf7/attachment-0002.html