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 <m...@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-boun...@lists.freeswitch.org [mailto: > freeswitch-users-boun...@lists.freeswitch.org] *On Behalf Of *Saeed Ahmed > *Sent:* Friday, June 12, 2009 7:39 AM > > *To:* freeswitch-users@lists.freeswitch.org > *Subject:* Re: [Freeswitch-users] Live Upgrade Techniques > > > > No idea at all, > > It’s a commercial SBC. > > I wish if we can have same functionality in FS. > > > > - Saeed > ------------------------------ > > *From:* freeswitch-users-boun...@lists.freeswitch.org [mailto: > freeswitch-users-boun...@lists.freeswitch.org] *On Behalf Of *Even André > Fiskvik > *Sent:* Friday, June 12, 2009 3:04 PM > *To:* freeswitch-users@lists.freeswitch.org > *Subject:* Re: [Freeswitch-users] Live Upgrade Techniques > > > > Can you comment some more on how this is configured? > > Would it be something that could be added to the wiki in the SBC setup > page? > > > > Best regards, > > Even André Fiskvik > > > > On 12. juni. 2009, at 12.16, Saeed Ahmad wrote: > > > > I've experience with a commercial SBC, these are two machines running in > cluster mode. In that case if one SBC is going down then other will take all > new calls including the call which were active on broken SBC (SIP only). > > Thats quite ideal for wholesale traffic where the SBC will never be idle. > > On Fri, Jun 12, 2009 at 8:25 AM, John Dalgliesh <jo...@defyne.org> wrote: > > On Thu, 11 Jun 2009 at 22:57 -0500, Brian West wrote: > > On Jun 11, 2009, at 10:35 PM, John Dalgliesh wrote: > > >> On Thu, 11 Jun 2009 at 16:33 -0400, Michael Giagnocavo wrote: > >>> > >>> Well, if you're running multiple machines, waiting for it to drainstop > >>> isn't that big of a deal unless you're in some sort of hurry, right? > >>> Give it an hour or so to drainstop, then kill 'em. > >> > >> Yes that's exactly what I'm trying to do. The problem is some people > will > >> only try one IP address. > > > > Clients that don't properly implement SRV/NAPTR and fail over need to be > > smacked. :) (not customers but software that fails to do that) > > Yes I'm sure much of their software can do this but it has been set up for > static numeric IPs. And getting the IP changed is a week-long process for > some customers! > > > >>> Would it not be simpler to try to do something with re-invites or > REFER, > >>> assuming your endpoints support it? > >> > >> That was actually plan A. I already added a property in sip_profile > called > >> failover_redirect, which specifies another server to try if FS can't > >> allocate any more sessions (e.g. too busy, paused, shutdown asap, etc.), > >> by sending back a SIP 302 Moved Temporarily response, instead of 503 Max > >> Calls In Progress. > > > > You can't send a 302 to a call thats already established. > > Yes and I don't want to touch established calls - those calls can stay > there until they drop. This is sent to new requests when > switch_core_session_request fails in mod_sofia. > > > >> Turns out not all my endpoints support it :( > > > > AKA broken endpoints. :) > > Some are broken. Some just have this feature disabled. For 'security > reasons'. You know the drill. > > > {P^/ > John > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > 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