15 sep 2011 kl. 15:38 skrev Iñaki Baz Castillo: > 2011/9/15 Olle E. Johansson <[email protected]>: >>> As a personal comment, I would like to say that nobody understands the >>> usage of "sips" schema, just nobody. And the specs do not help. >>> >> With the deprecation of "transport=tls" it becomes even more strange. > > AFAIK "transport=tls" has never been deprecated. Instead, it has never > been an standard. Note for example that RFC 3261 says: > > Note that in the SIPS URI scheme, transport is independent of TLS, > and thus "sips:[email protected];transport=tcp" and > "sips:[email protected];transport=sctp" are both valid (although > note that UDP is not a valid transport for SIPS). The use of > "transport=tls" has consequently been deprecated, partly because > it was specific to a single hop of the request. This is a change > since RFC 2543. > > "A change since RFC 2543"?? transport=tls has never been defined in > RFC 2543. Check yourself: > > http://tools.ietf.org/html/rfc2543 > > >> We should really spend some time on a "hitch hikers guide to SIP with TLS" >> and write an RFC to reinstate transtport=tls, which is what we all use. > > Or spend some time in a new draft that *correctly* explains how to use > TLS in the first hop (without requiring security in the whole path). > This is *very* easy: > > As I've explained in my first mail: > > INVITE sip:[email protected] SIP/2.0 > Via: SIP/2.0/TLS 1.2.3.4 > From: sip:[email protected] > Contact: sips:[email protected];transport=tcp > > That's all. Just: > - Set TLS in Via transport. > - Use "sip" schema in every URI. > - But use "sips" schema in Contact URI. > > And it works.
This means thet the request URI of the ACK will be using SIPS, and then section 8.1.1.8 comes into play and requires the other side to also use a SIPS uri in their contact. In this case, both UAs need a TLS certificate. Interesting. /O _______________________________________________ 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.
