> 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).
The NOTIFY should be sent based on the Record-Route so things should be fine there. Why not have a time-out value of 7 seconds between the tx of the Subscribe and the Rx of the Notify instead of having a two-stage time-out. The 7 seconds is broken down as follows: - 2.5 seconds allocated for HA fail-over of the SUBSCRIBE - Another 2.5 seconds allocated for HA fail-over of the NOTIFY (in case the Record-Route carries our SIP domain - we want to get there one day) - 2.0 seconds for the network delays and app response time (time allocation of the current design) Of course, this assumes that the HA is composed of only two sipXecs nodes. For arbitrary large HA deployments, this time-out is going to be too short but the user will probably give up around 10 seconds anyways. _______________________________________________ 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/
