Scott Lawrence wrote: > On Tue, 2008-12-16 at 14:18 -0500, Arjun Nair wrote: >> Scott Lawrence wrote: >>> Well, if we're going to try to come up with the "right" solution (worth >>> discussing, certainly)... >>> >>> I think that HttpMessage (and therefor SipMessage) should provide two >>> methods: >>> >>> getAuthorizationHeader >>> that iterates over values of the Authorization header >>> for use by user agents. >>> >>> getProxyAuthorizationHeader >>> that iterates over values of the Proxy-Authorization >>> header for use by proxies. >>> >>> then something in sipXcommserverLib should provide higher level methods >>> that add the handling of a sipXecs PAI header on top of those: >>> >>> getAuthorization >>> For user agents. >>> >>> getProxyAuthorization >>> For proxies. >>> >>> These are also iterators, that return true/false to indicate if a "next" >>> identity is returned. Each should look first for a PAI header with a >>> valid sipXecs signature; if that is found, it's the only identity this >>> method will return. If no PAI is present, then they revert to iterating >>> over the appropriate header above. >> This will work for the dialog-initiating SUBSCRIBEs. In-dialog >> SUBSCRIBEs, however, will not have a PAI header (but, they will have >> the Proxy-Authorization header). Hence, the status server will be >> forced to challenge them.. Now, I am not sure if the phones would >> choke on that or not. > > If there's a valid Proxy-Authorization header, why doesn't the proxy add > a PAI? >
We only check for credentials, and apply the PAI header, if it is an out-of dialog SUBSCRIBE (SipRouter::isPAIdentityApplicable()). All in-dialog SUBSCRIBEs go through unchallenged. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
