I'm looking at the patch you posted[1] and have a couple of questions... > 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. 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
