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/
