My Response Inline

   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.

[Joseph] Fine
        

   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.


[Joseph] After P1 forwards the first 407 it removes it own authorization
header from the request.When this reaches at P2 then again P2 will request
for authentication.This 407 is again given to the UAC through P1.This time
the UAC sees this as a failure of credentials for the prevoius request and
sends again to the user to key in the username and password.This willl agin
the request with one authorization header.Now again while passing through P1
it strips the authorization header from the request.Will this not create a
loop?

   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


Disclaimer:

This message and any attachment(s) contained here are information that is 
confidential, proprietary to HCL Technologies and its customers, privileged or 
otherwise protected by law. The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended 
recipient of this message, you are not authorized to read, forward, print, 
retain, copy or disseminate this message or any part of it. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete it from your computer.

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to