> 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.
I think Dale had already figured that one out. One of the contacts is generated as a result of the call forwarding rule and as such, the resulting SUBSCRIBE has a sipX-authidentity of the original call target. In the Proxy, a properly signed sipX-authidentity has the same authentication "power" as a WWW-Authenticate header and any request bearing a valid sipX-authidenitify will not be 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. Suppressing the call forward is a band-aid on the problem but there may be other scenarios where some forks require authentication and some don't which would result in similar problems although I cannot think of one right now. _______________________________________________ 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/
