On Thu, 2010-02-18 at 10:23 -0500, Joly, Robert AVAYA (CAR:9D30) wrote: > > 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.
There are two interlocking problems. One is that we don't apply "sipx-userforward=false" to the SUBSCRIBE for call pickup. Doing this would improve the user experience. (Which reminds me that I need to vet the change on sipx-users.) This change would also make the symptom disappear. The second problem is that we've started demanding authentication of SUBSCRIBEs under certain circumstances. But most of our security architecture presumes that SUBSCRIBEs are never challenged, and so things don't work right. It seems that the new strategy is to challenge SUBSCRIBEs to event packages that are listed in SIPX_PROXY.205_subscriptionauth.PACKAGES_REQUIRING_AUTHENTICATION, but only if they aren't already authenticated with a header, and only if the request won't spiral. But that's a recipe for trouble. I think that we need to start treating SUBSCRIBEs that we may challenge like we treat INVITEs -- challenge them preemptively, when we first see them. Then we won't get these forking problems. In that context, the problem is being selective for the event package. Although it's not clear to me why we need to be selective for event packages -- there are only two popular event packages, dialog and message-summary, and they will both eventually be challenged. There's no loss if the proxy challenges them preemptively. 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/
