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? > OTOH, in the status server, we expire the nonce after 5 mins, hence we > may end up challenging re-SUBSCRIBEs regardless of whether we look for > the Proxy-Authorization header or not. > > I am doing the tests right now. Will update you on the results. > > 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
