Perhaps this is one thing that just won't work when a proxy is down, like everything that runs on the master proxy. From an end user perspective the less time spent waiting for the pickup function to do it's job, the better. Even a 1 second delay is too much (I really wish I could set this to half a second)
I propose having the option to choose the strategy for call pickup (except for call park scenarios): longest ringing, or first response. In many cases when doing a call pickup on a standard extension there is only one ringing call. The "first response" method would shorten the pickup time by essentially ignoring or acknowledge-but-discard any responses after the first valid response. Did any of that make sense? Am I talking nonsense and proposing an impossible solution? Josh Patten Assistant Network Administrator Brazos County IT Dept. (979) 361-4676 On 5/11/2010 1:17 PM, WORLEY, Dale R (Dale) wrote: > The sipXecs Registrar executes a call pickup by sending a SUBSCRIBE message > to the targeted extension. It then waits a configured period of time > (default 2 seconds), then examines all of the NOTIFY responses it got to the > SUBSCRIBE to determine what calls are ringing on the UAs for the targeted > extension. Among those calls, the Registrar chooses the call that has been > ringing the longest to be picked up. > > As issue XX-8372 shows, this strategy does not work well in an HA > environment: if the SUBSCRIBE goes to a proxy which is down, the Registrar's > SIP stack takes 2.5 seconds to fail over to the other proxy. By that time, > the Registrar has given up waiting for NOTIFYs from the SUBSCRIBE, and > reports the pickup as failing. Conversely, if we raise the wait time to 4.5 > seconds, all pickup operations are unduly delayed. > > We need a new strategy for the call pickup delay. > > In most cases, the SUBSCRIBE will reach all intended destinations within a > few seconds, and all destinations will produce responses. These responses > are combined at the various forking steps, and eventually are combined into > one response that is seen by the Registrar. The NOTIFYs will arrive before > the response or very shortly after it. > > The bad case is if a downstream element receives a SUBSCRIBE and sends a 100 > response but does not proceed to provide a response. It will take a long > time (15 seconds, IIRC) before the upstream element will synthesize a 408 > response. > > I think we can handle both cases with the following algorithm: > > - send SUBSCRIBE > - wait for a response to the SUBSCRIBE, but give up waiting after a > relatively long time (e.g., 5 seconds) > - after the response arrives, wait a short time (e.g., 0.5 sec) for NOTIFYs > - choose the call to pick up > > However, there might be a problem with a NOTIFY being routed to the failing > proxy (e.g., if the phone has an outbound proxy set). > > Comments? > > Dale > _______________________________________________ > 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/ > _______________________________________________ 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/
