On Wed, 2009-05-27 at 15:57 -0400, Mark Gertsvolf wrote: > The current behavior of directed call pickup feature is to extend dialog > event subscription to all the registered sets of a user in question and > on top of that follow the whole call forwarding tree in parallel. So, if > user 200 has a rule to forward calls to user 201, then pickup plug-in > sends subscription to all the phones of user 200 and user 201, which > translates into all the phones of user 201 and so on. This is causing > issues as described in http://track.sipfoundry.org/browse/XTRN-622. The > subscription is also sent to the user's voicemail deposit URI, which is > yet another issue altogether: http://track.sipfoundry.org/browse/XX-4830
The failure mode in XTRN-622 is fairly complex. Unfortunately, it is not likely to be uncommon. The sequence of events is: - When the pickup call comes in, the registrar starts a subscription to the targeted phone. The registrar will wait 2 seconds to gather NOTIFYs from this subscription, and then from them will choose the call to pick up. - The initial SUBSCRIBE has no authentication, and will receive a 407 response from a number of forks. Unfortunately, among the forks is an Audiocodes gateway, which does not respond to the SUBSCRIBE at all. (This is a ridiculous error, as it would be easy enough to give a 405 or 489 response.) As a result, the proxy takes 3 seconds to time-out the transaction, and return a 407 response to the registrar. - The SUBSCRIBE is re-sent with authentication. Some of the forks get immediate responses. Some (e.g., the voicemail system) return error responses. But LG-Nortel phones take about 1 second to generate the initial NOTIFY. - Of course, by this time the registrar has given the failure response for the pickup operation, as it waits 2 seconds, but the resend of the SUBSCRIBE happens at T+3 seconds. This process is partly accelerated by the fact that the registrar strips "q" parameters off contacts provided for a SUBSCRIBE request, which makes the proxy handle the forking in parallel. This failure mode will be seen any time a phone has a forward to an element that does not respond to a SUBSCRIBE request. It would also show up if a registered phone does not respond to a SUBSCRIBE request. It is unlikely that any phone model our customers use does so, but if the phone had recently been powered off, this would happen. Of course, we should harass Audiocodes to fix their gateway. But that is not an immediate solution. We can significantly accelerate the operation if we can pre-authenticate the SUBSCRIBE, to avoid having to resend the SUBSCRIBE. Currently, this saves 3 seconds, but it would provide some improvement even in non-delayed cases. (As far as I can see, we can pre-authenticate to the SIP domain, and there are no other domains for which we have credentials. So we would never need to re-send the SUBSCRIBE.) Alternatively, we could add an Expires header to the SUBSCRIBE. That could reduce the time spent getting a response to the first SUBSCRIBE. (Adding Expires to the resent SUBSCRIBE would have no value, although it is probably unavoidable.) This is probably a workable timeline: Set "Expires: 1". The first SUBSCRIBE takes 1 second. The second SUBSCRIBE will be sent at T+1 second. Given the slowness of LG-Nortel phones, the last NOTIFYs will arrive around T+2 second. This is workable if we set the pickup wait at 3 seconds. Surprisingly, this problem is unaffected by the number of contacts for a phone per se, as long as the proxy is willing to fork to all of them in parallel. 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
