2011/9/16 Horvath, Ernst <ernst.horv...@siemens-enterprise.com>: > Well, I read RFC 3261 differently. 8.1.2 says: > > Otherwise, the procedures are applied to the first Route header field > value in the request (if one exists), or to the request's Request-URI > if there is no Route header field present. These procedures yield an > ordered set of address, port, and transports to attempt. Independent > of which URI is used as input to the procedures of [4], if the > Request-URI specifies a SIPS resource, the UAC MUST follow the > procedures of [4] as if the input URI were a SIPS URI. > > This behaviour overrides the transport indicated in the Route header if > the Request-URI is SIPS. And it applies to mid-dialog requests as well. > BTW, RFC 5630 has some text on your original point: > > 5.1.1.2. SIPS in a Dialog > > If the Request-URI in a request that initiates a dialog is a SIP URI, > then the UAC needs to be careful about what to use in the Contact > header field (in case Record-Route is not used for this hop). If the > Contact header field was a SIPS URI, it would mean that the UAS would > only accept mid-dialog requests that are sent over secure transport > on each hop. Since the Request-URI in this case is a SIP URI, it is > quite possible that the UA sending a request to that URI might not be > able to send requests to SIPS URIs. If the top Route header field > does not contain a SIPS URI, the UAC MUST use a SIP URI in the > Contact header field, even if the request is sent over a secure > transport (e.g., the first hop could be re-using a TLS connection to > the proxy as would be the case with [RFC5626]).
Hi, this definitely tells me that SIPS and TLS is impossible, but just in the case of full TLS in the whole path. I insist on the bug I've reported for RFC 5630: If the client sets a SIP Contact URI and sends the request using TLS, then it would receive incoming in-dialog requests via UDP or TCP, but not TLS. This does not make sense as the caller could use just SIP over TLS, and in case of NAT this would never work as the proxy/server could never send a TCP or UDP request to the client. So IMHO SIPS and TLS is broken and it can only work when the full path is secure (which is unfeasible in most of the environments). This needs a rework, or maybe Olle is right and we should use ;transport=tls (with SIP schema), ;transport=tls-sctp and so on. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP implementation. Use dispa...@ietf.org for new developments on the application of sip. Use sipc...@ietf.org for issues related to maintenance of the core SIP specifications.
