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 > > However, regardless of the actual specifics of why the pickup is failing > in this case, I think the call pickup conceptually should not follow the > call forward tree. > > People invoke directed call pickup when they hear somebody's phone ring > or when they have a BLF key for another user and they see the call for > that user. The intention is to pick the call that appears on the sets of > a specific user right now. It is irrelevant that the call happens to > also ring phones belonging to 10 other people because of the user's call > forward rules. > Also if the call stops ringing the phone of the user in question and > rolls to the next destination in the forwarding tree - pickup should > fail. If the next target is user Y, then it should be able to pick this > call up using directed call pickup for user Y. > > My proposal is to restrict the target audience of the subscription to > only user's registered sets using "sipx-userforward=false" parameter in > R-URI.
I think that's worth trying, but I'm concerned that it's a very large change to make very late in the release cycle. It also may have significant backwards-compatibility issues in that it will change which phones are followed, and therefor may cause operations that worked before to stop working. I think that the configuration in XTRN-622 that caused the failure is pretty unusual (significantly more forks than most lines will have), so my inclination is to say that this should be deferred to 4.0.2. I like the suggestion [1] that the pickup redirector pre-construct the authentication (we do this in at least one other case that I know of), but I don't think it's urgent enough to do now. I also think that we should add an Expires header to the SUBSCRIBE so that all branches are cleared out quickly (N minus 1, where N is the pickup timer). [1] http://track.sipfoundry.org/browse/XTRN-622?focusedCommentId=39694&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_39694 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
