thanks for the response. I read about the second way to deal with asymmetric record routing by setting multiple record-route headers by the proxy. my question is whether this is going to be a substitute solution that is recommended by rfc 3261.
In addition, I'm still confused about the current solution described in rfc 3261 section 16.6.4 and 16.7.8. The example you gave is when a request is received over TLS and sent over UDP. You've written that changing the record-route from SIP to SIPS when the response is received is not the correct behavior and the proxy just need to keep the record-route addresses to be distinctive enough so that they will resolve to the correct interface. but, according to rfc 3261: 1. when handling the request according to section 16.6.4, rfc 3261: "a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI." - meaning the proxy must insert a record-route with a URI that is not a SIPS. 2. when handling the response according to section 16.7.8, rfc 3261: "If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI." - meaning the proxy need to rewrite the record-route with URI that is not a SIPS to one with SIPS. Is the rfc not accurate, or am I missing here something ? regards, Adi Even-Tzur. -----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 5:45 PM To: Adi Even-Tzur Cc: [EMAIL PROTECTED] Subject: Re: SipIt Interop problem - when proxy should rewrite URI of Record-R oute header First off - Using TLS and using a sips: URI are not the same thing. sips: implies TLS. TLS does not imply sips: In the scenario you describe below, there is no reason for a sips: URI to spring into existence. In fact, it would be an error if one did. A sips: URI says something about the security of transporting messages _all the way to the far endpoint's domain_, not just the next hop. The real concern in this case is providing enough information in the RR header field so that subsequent requests from each direction show up at the interface the proxy wants them to show up. Assume that what the proxy wants is to continue using TLS upstream and the non-TLS (say UDP) downstream. It needs to give its downstream proxy a URI that resolves to UDP according to 3263. It needs to give its upstream proxy a URI that resolves to TLS. RjS btw - A better way to deal with this asymetric record routing than rewriting the fields in responses was identified several months ago on the SIP list. Check out http://bugs.sipit.net/sipwg/show_bug.cgi?id=664 On Sun, 2003-08-31 at 05:30, Adi Even-Tzur wrote: > Hello, > > This is an issue that was raised during SipIt 13 "sips spirals" advanced > test. > > When a proxy received a request over TLS, but the Request-URI is without > "sips", and the proxy sent the outgoing request > over non-TLS - should the proxy rewrite the URI of the Record-Route header > it set when forwarding the response from "sip" to "sips" or should it leave > it as is ? > > In other words, does the transport type the request was received and sent is > what that matters or is it the URI type that matters ? > > > regards, > > Adi Even-Tzur. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
