On Wed, 2010-02-17 at 22:42 -0500, Dale Worley wrote: > On Wed, 2010-02-17 at 14:54 -0500, Joly, Robert AVAYA (CAR:9D30) wrote: > > Now that this is understood, there may be an easy way to fix the > > problem. It seems to be that following the call forwarding rules of a > > user is pointless in the case of subscribes. If the call pickup plug-in > > crafted the SUBSCRIBE with a sipx-userforward=false URL parameter in the > > R-URI, that would likely do the trick unless I'm missing something. > > Of course, that would change the intended behavior, in that a call sent > to 111 could not be picked up with *78-111, if phone 111 was forwarded > to 222. But that seems reasonable, since the call would actually be > ringing on 222, and people would use *78-222. > > But there still is the potential problem that a SUBSCRIBE that forks > could be challenged on one fork and not others. We should think about > the implications for our security strategy.
Robert seemed to find why some of the forks were challenged, but I don't understand why (if his explanation is correct) all of the forks were not challenged. This is something of a bug in SIP really (when there are challenges on some forks but not others, the UAC will never see the challenges if the unchallenged forks succeed) - it manifests in other ways too. I agree that not following user forwarding makes sense for pickup, and that the resulting behavior is ok, but I would like to make sure that we really understand what happened. _______________________________________________ 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/
