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. 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
