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
