From: "Joseph C T - NPD, Chennai" <[EMAIL PROTECTED]> This is fine when proxy P forks and also it collates the 407 responses.
A proxy is *required* to collate 407 responses from a forked request. See RFC 3261, section 16.7, item 7. Is there any chance for a scenario like this UA1->P1->P2->P3->UA3 ,where P1 and P2 are in the same domain and use same realm. Yes, such a scenario could easily happen. The first request will cause a 407 at P1. The UAC will provide an authorization based on P1's challenge and re-send the request. The second request will pass P1 and cause a 407 at P2 (assuming that P2 requires a separate nonce). That 407 will be returned to the UAC, which will construct a second authorization based on the second 407. The third request will have both authorizations, it will pass P1 and P2 and arrive at UA3. This is a direct consequence of the rules in RFC 3261. If yes,then how does the UA1 know the second challenge was from the second proxy(P2) Why are you obsessed with knowing which challenge is from which proxy? The UAC cannot tell which proxy generates which challenge, and it does not need to. It only needs to construct authorization headers for every challenge it receives, and keep resending the request until it arrives at the desired UAS (as witnessed by the successful response). Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
