Resend due to membership expired...
> I assume that you verified (I have not, yet) that all the moving around of code you did that is not related to the > domain name change is logically equivalent? There are a lot of flags getting set... > It looks to me as though you unconditionally remove any PAI header in the message, and then later check to see if the > message is authenticated and add one. If the header is already there and signed, it seems to me we should just leave it > alone. Am I missing something? In the patch, PAI header is removed only if it is not signed/authenticated. > If there is a PAI header that is not our domain, I think that the proxy should leave it alone (that is, leave it in the > message). This is the backwards-compatible behavior, and if there is an outside caller sending a PAI header in, some > sipXecs service or other downstream party may want to know. > I agree it is probably premature to remove PAI header that not > inserted by sipXecs. We should allow co-exsistence of PAI header that inserted by other parties, but just not to trust it within our domain. I will revise the patch for that. Now, I have to take back what I said that I would agree not to remove the PAI header that not inserted by sipXecs. Just checked RFC 3325: "A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field." "If there is no P-Asserted-Identity header field present, a proxy MAY add one containing at most one SIP or SIPS URI, and at most one tel URL. If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field." Therefore,sipXproxy should NOT keep the P-Asserted-Identity carried in the request that hasn't been authenticated, and must remove it.( unless the PAI header value is a tel URI, which we don't support at this point yet). Otherwise, it will end up with multiple P-Asserted-Identity headers with sip URI value, which will violates RFC 3325. Thinking about the case that when ITSP receives the requests that have multiple P-Asserted-Identity headers, which one should it use? I believe it might create some other compatibility issues. Thanks Huijun [1] http://track.sipfoundry.org/secure/attachment/15836/XECS-1643.new.patch _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
