> > On Sun, 2010-02-21 at 22:54 -0500, Dale Worley wrote: > > Let me propose an idea: We should consider SUBSCRIBE as a > "normally > > authenticated" request in much the same style as INVITE. > > > > Thus, we would "preemptively" perform the authentication > challenge in > > the Proxy if the request claimed to be from a sipXecs identity that > > possessed credentials. This challenge would be done > regardless of the > > event package to which the SUBSCRIBE was directed. > > > > This would eliminate the directed call pickup problem of XX-7668. > > > > I think that it would not cause much extra authentication > traffic, as > > all sipXecs-provided subscription servers require > authentication (or > > should do so). > > > > To improve efficiency, it would be helpful if sipXecs subscription > > clients would "preauthenticate" themselves, that is, > provide suitable > > authentication headers in the initial requests, thus avoiding the > > additional round-trip for authentication. > > To make that work, we would have to also enhance all our > SUBSCRIBE servers to use the PAI identity that the proxy > includes, so that no UA would get both a 407 from the proxy > and a 401 from the service (known not to work on at least > some of them).
Yes that would be ideal (in fact required to get around the Polycom bug I already mentioned in this thread). Unfortunately though, the PAI does not go beyond the proxy. We take it out of the message before it leaves the proxy to address http://track.sipfoundry.org/browse/XX-560. One possibility would be to assume that any SIP destinations that reside on one of the sipXecs servers in the cluster are part of our 'trusted domain' and that we leave the PAI in for those destinations. _______________________________________________ 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/
