> On Tue, 2010-04-27 at 15:56 -0400, Beeton, Carolyn (Carolyn) wrote: > > > > > > I think it was added as a best-effort fix for > > http://track.sipfoundry.org/browse/XX-5009. Before we set it > > explicitly to 60 seconds, it was being cancelled at 20 > seconds by some > > other part of the logic. That was so short that a cell > phone couldn't > > forward to its own voicemail. > > I think that we need to take that change out. > > The history on the XX-5009 is pretty tangled, and the issue > got morphed quite a bit along the way. > > The general problem of gateway redundancy is very very > difficult because of differences in PSTN interconnect > technologies (including especially how much call progress > information you get) and different implementations in > gateways. A single solution that will work across any > arbitrary combinations of gateways and connection types is > not possible (for example, a simple analog fallback gateway > without call progress detection will just immediately return > a 200 response and then play the PSTN audio - SIP cannot > detect that such a leg may never really be answered). > > The special case of this problem that apparently motivated > this patch was that the default failover time is short enough > that it will often not allow cell phone connections to pick > up when people forward to them using that default time. > Since cell phone connection times are highly variable and can > be quite long, this can be a problem, admittedly; however, an > individual user can already set a long expiration time (ring > time) on the forwarding to the cell phone - adding a time to > the default dial plan is not needed. > > In this case, I think the cure for the cell phone voicemail > problem is worse than the problem it causes with early media sessions.
I do not think so - see my post just after carolyn's. In the absence of the Expires=60 header addedd by Carolyn, calls to IVRs with early media will be cancelled in 20 seconds instead of 60 because of the 'default serial fork expiration' setting that the proxy has. So, I think I can safely say that the cure is 3 times better than the problem (but the patient died anyway) :) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
