inline On Mon, 2003-09-08 at 08:34, Adi Even-Tzur wrote: > 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.
Yes. > > 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. All of that come after and is part of the clause "If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI," I've added a bug (734) against the spec to make it more clear that the rest of that paragraph is dependent on that starting sentence. > 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. This is a bug in the spec. The conditional here should be the same as what I quoted above (noting that its what was in the request associated with this response that's being tested). This is being tracked now as bug 735. Thanks for pointing it out! > > 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
