Behavior "a" is correct. The useless inclusion of Contact header within the 407 should not alter where the subsequent INVITE is sent.
However if the UAC chooses to bypassing the proxy, it can of course try to do so since it is originating the call. And depending upon the purpose of the proxy, such behavior might of course result in unintended behavior: 305 response, 485 response, lack of privacy, lack of security, lack of trust, unreachability, etcetera. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Mauro Crovato > Sent: Tuesday, January 09, 2007 5:19 PM > To: [email protected] > Subject: [Sip-implementors] theorical question > > Hi, I'm having a theorical question/problem about the correct > sip behavior in some scenario and i can't find anyone who > tell me what is the right thing to do (Honestly I read the > RFC, but it doesn't help or i don;t have the complete picture > on my head). I found some sip clients do one thing and other > work different, so i don't known what to do... > > the scenario is basically like this: > > UAC <-----> SIP PROXY <-------> UAS > > - uac send an invite to proxy (the invite is for some client > of the remote UAS) > - it forwards it to UAS (based on static routing definition > or domain info or SRV) > - later uas sends a 407 response (proxy auth or www auth), > with UAS ip in the Contact header field > - the proxy receives this and forward it to UAC (without > changeing the Contact field) > - here are two behaviors depending the client: > a) the UAC send a new invite , with the digest auth, to the proxy > b) the UAC send a new invite , with the digest auth, > direct to the UAS. > > the question is which is the correct behavior? a or b? _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
