On Tue, 2010-03-02 at 16:39 -0600, Josh Patten wrote: > Is there or will there be any way in the future to set the call pickup > timeout to less than 1 second? Old school key system user get really > frustrated when they start talking immediately after dialing the pickup > sequence only to realize it takes a full second to connect the call. Is > there a technical reason why this can't be less?
There are some interactions between how we implement the feature and what it actually does for the user. The essence of the implementation is that when the INVITE for the call pick-up call gets to the Registrar, the Registrar sits on it. The Registrar then sends a SUBSCRIBE targeted to the number that is to be picked up. That SUBSCRIBE propagates through sipXecs to (hopefully) all the phones that are registered for the number. Each phone responds with a NOTIFY containing the details of all calls on the phone, and in particular, all calls ringing on the phone. Those NOTIFYs propagate back through sipXecs to the Registrar. After a selected time period, the Registrar collates all the information that it got from the NOTIFYs and selects the call which has been ringing the *longest*, and modifies the original INVITE to pick up that call, on the phone on which it is ringing. It then sends the INVITE onward, which completes the pick-up operation. The problem revolves around the specification of call pick-up to pick up the call that has been ringing longest. Because of that, the Registrar needs to have complete information about what calls are ringing on what phones with the given line number. Or at least, it needs to get complete information maybe 90% of the time. So it has to wait for some period of time -- it can't just jump on the first ringing call that it gets information about. Conversely, it takes a certain amount of time for the SUBSCRIBE and NOTIFY messages to propagate through sipXecs and be acted upon by the phones. Perhaps if we're lucky, 1/2 second is long enough, though. Can you please file an issue on this, so we have a place holder for the work needed to improve the feature? 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/
