Re: [sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"

Why would you want to use sips in the Route header in this particular case and not sip with the transport=tls parameter? I tried to make sense out of rfc 5630 but failed, so if you could present any more evidence why this is a good idea, that would be great. The way I understand sips is that by using this scheme in a URI, you are indicating that you want to be contacted securely and if that is not possible (for whatever reason), you would rather want the request to fail than to be forwarded insecurely. I can see how this could make sense from end-point's (phone) point of view. But why would anyone want to use this in the Route header? By using sips instead of sip;transport=tls in a Route header the proxy server is enforcing that it is to be contacted securely during the dialog, even if the original request (that established the dialog) may not have been subject to such a restriction. In other words request path that was fine for the INVITE is no longer fine for the re-INVITE or BYE. Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used? -Jan On Tue, Jul 5, 2011 at 09:03, Iñaki Baz Castillo <ibc(a)aliax.net> wrote: