Andreas Granig writes: 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. 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. you cannot use sips with udp transport. -- juha

On 01.12.2012 00:25, Andreas Granig wrote: (Disclaimer: non normative - this is how I understand SIP and how I would use it) The request URI should look like the one which the user enters. E.g. if user enters "sip:12345@example.com" then the request URI should be "sip:12345@example.com" - regardless of the transport protocol chosen by the transport layer. Thus, if NAPTR records tell you to use SIP over TLS, then use SIP over TLS but do not change the request URI. The contact header could be any transport - but of course it makes sense if the client uses the same transport protocol as used for sending the request (which is usually the same used for registration). When a user enters "sips:12345@example.com", then of course a secure transport must be used, which basically means that TLS will be used. Nevertheless the request URI is still "sips:12345@example.com" without any transport identifier. The request URI only contains a transport parameter if the user entered one (e.g. to force its client to use a certain transport), or if the call forwarding logic in the proxy requires a certain transport. In this case, NAPTR lookups will be skipped (as transport is already defined). In case if a SIPS URI entered by the user, the contact URI must be SIPS too. In a proxy it usually does not makes sense to manually change a request URI from SIP to SIPS - but there may be certain scenarios where things may get complex, e.g. the Sipwise "SIP Provider" setup: Client1 <---TLS/TCP/UDP ----> Proxy <---UDP--> sems/b2bua / Client2 <---TLS/TCP/UDP -- As long as SIP URIs are used, there is no problem in converting from TLS to UDP. If client 1 uses a SIPS URI to call client 2, then may be problems: From standard point of view it should be fine to convert TLS to UDP, as the transport is secured by other means (in this case a local hop via loopback interface). The question is how the SIP client will react, when receiving SIP requests for SIPs URIs, but the contact contains a SIP URI. A workaround of course would be to change sems's contact to "sips:...;transport=tls" in the proxy, but still use UDP between proxy and sems. RFC3263 does not enforce the format of the URI. It just tells you to use TLS/TCP/UDP - as said above, the RURI should not be changed due to NAPTR lookups. Hopefully not. The RURI should not be changed. Yes, there are lots of open issues and sips itself is broken by design as it enforces encryption between all hops, but there is no way to control or enforce that encryption is really used between all hops. So, I personally would mandate to drop the SIPS schema completely, as it can not guarantee secure transport on all hops. The only hop where a client can enforce a secure transport is the first hop - and this can be done also with the SIPS schema. regards Klaus

2012/12/1 Andreas Granig &lt;agranig(a)sipwise.com&gt;om>: The client yes, but a proxy not. This is, if the proxy is forwarding a request with RURI "sip:alice@domain.com" and NAPTR returns a SIPS+D2T (along others) the proxy could choose to send the request via TLS but must not modify the RURI scheme. Anyhow, I strongly discourage the usage of sips schema. It was a "dream" of the IETF. Nobody uses it, nobody can use it and it provides nothing (since an intermediary proxy could decide not to honor the requested security and forward the request via UDP/TCP). Some months ago I discussed this subject in sipcore WG and the conclusion is that nobody wants sips usage. transport=tls has NEVER been real, no one RFC mentions it. As said before, the proxy could choose TLS for forwarding the request (so would add a top Via with "TLS" transport) but should not modify the URI scheme. When a client sends a request with SIPS in the RURI, the responses must have SIPS in all the Record-Route and Contact. And the same for incoming requests in the same dialog. Otherwise the client should terminate the dialog. In this case the proxy should not attempt to forward the request and, instead, reject it with 416"Unsupported URI Scheme". Good cuestion but IMHO there is no good response. They could reply normally but the UAC may later terminate the dialog when it realizes that the Contact URI in the response has no SIPS schema (since SIPS is not valid in UDP). As said before, the easiest way to live with this is by never using SIPS as it provides nothing and adds lot of undocumented issues. Also note that it's valid for a client (or a proxy) to send a request via a TLS connection and still setting a Contact URI with transport=tcp. This would be hard for receiving incoming requests but for that Outbound (RFC 5626) does exist (the proxy would route the requests over the connection initiated by the client, regardless it is TCP or TLS and regardless the URI schema in the Contact URI). Regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;