inline > -----Original Message----- > From: Iñaki Baz Castillo [mailto:[email protected]] > Sent: Donnerstag, 15. September 2011 16:31 > To: Horvath, Ernst > Cc: [email protected] > Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630 > > 2011/9/15 Iñaki Baz Castillo <[email protected]>: > >> It may work for the 1st request. But in a subsequent > mid-dialog request in the reverse direction the contact URI > becomes the Request-URI, which is now SIPS, and therefore the > Contact in this request must also become SIPS, and you end up > in an all-SIPS case. > > This is not true. The in-dialog request will have, indeed, a RURI with > SIPS schema, but it will also contain a top Route with SIP schema, so > it takes preference and there is no need at all to set a SIPS Contact > URI.
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]). Regards, Ernst > > RFC 5630: > > 5.1.2. UAS Behavior > > When presented with a SIPS URI, a UAS MUST NOT change it to a SIP > URI. > > As mandated by [RFC3261], Section 12.1.1: > > If the request that initiated the dialog contained a SIPS URI in > the Request-URI or in the top Record-Route header field > value, if > there was any, or the Contact header field if there was > no Record- > Route header field, the Contact header field in the > response MUST > be a SIPS URI. > > In our case *there is* a Record-Route in the INVITE arriving to the > UAS and it does contain a SIP URI, so the Contact in the response from > the UAS does not need to be a SIPS URI. > > > Anyhow I insist: SIPS and TLS usage is a pain. Nobody understands it > (it's clear given any mail thread about this topic) and everybody does > wrong assumptions. I think SIP authors should worry about this reality > and react. > > > Regards. > > > -- > Iñaki Baz Castillo > <[email protected]> > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications.
