> -----Original Message----- > From: Worley, Dale AVAYA (BL60:9D30) > Sent: Thursday, February 18, 2010 11:12 AM > To: Joly, Robert AVAYA (CAR:9D30) > Cc: Lawrence, Scott AVAYA (BL60:9D30); sipX-dev > Subject: RE: [sipX-dev] XX-7668 Directed call pickup of a > user doesnotworkif he has configured 'User Call Forwarding' > > 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_AUTHENTICAT ION, 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.
I it not 100% true to say that we challenge INVITEs preemptively. We only preemptively challenge INVITEs that appear to be from users that have credentials on our system. All the INVITEs that do not come from such users are allowed to spiral and eventually challenged by the auth plug-ins only if required. Indeed, preemptively challenging UACs that do not have credentials on our system would be really bad for external users as they would simply see their INVITEs challenged by us and would not have credentials to retry the INVITEs so they would just go away. No make matters worse, even if we decided that preemptively challenge SUBSCRIBE, that would not get us out of the woods, the reason being that SUBSCRIBES to RLS would get double-challenged: once preemptively by proxy (407) and a second time by the RLS (401). It has been observed in the past that phones such as Polycom cannot cope with the double-challenges. Although this may be fixed by now, still the double-challenge pushes the envelope and exposes us to more potential interop issues. > > 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. The event package selectivity is a configurable parameter in the subscribe auth and we can surely extend it to handle more packages but I'm not sure it will address any of our problems. _______________________________________________ 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/
