[SR-Users] NAPTR, SRV and sips vs. transport=tls

[Juha Heinanen]

Andreas Granig writes:

> A lot of clients and servers are sending
> "sip:user at example.com;transport=tls" in request URIs and Contact headers
> and Record-Route headers, and you can check with
> uri_param("transport","tls") which transport socket to use. This is
> pretty useful as you can determine hop-by-hop whether or not to use TLS.
> This approach has been obsoleted by RFC3261 though, and there doesn't
> seem to be a mechanism in RFC3263 to indicate "use schema sip, but use
> transport=tls".

when rfc3261 was specified, the whole sips thing was put there at the
last minute.  no-one had any practical experience of it.  i guess the
requirement to have something like https came from ietf area directors.
the result is a useless mess.

> And what's the general take on this "sips" schema? As far as I
> understand RFC3261, it means that if a client sends a request to a
> sips-URI, the request is sent to the domain via TLS, and from there "the
> request is sent securely to the callee, but with security mechanisms
> that depend on the policy of the domain of the callee." (RFC3261,
> Chapter 4). What does this really mean in practice? Are you allowed to
> rewrite the schema to "sip" and pass it on for example via UDP to the
> callee if the callee didn't indicate transport=tls (deprecated anyways)
> or "sips:" in the Contact of the registration?

in that case, the proxy has to drop the request unless the last hop is
"secure", i.e., uses a vpn, barb wire, or something.

> Or should you keep "sips"
> as schema, but still send it via UDP, because you know based on local
> policy or based on client registration that the next hop is not
> supporting TLS? How would widespread clients react when getting a call
> to a "sips" URI, especially if they receive it via UDP?

you cannot use sips with udp transport.

-- juha