Juha (and Francois),
What I miss in the discussion and draft is the reason why transport=tls was
deprecated, namely that TLS by itself is not a transport. The transport is
either TCP or SCTP, TLS is the security layer on top of that
The "TLS" value for Via transport in RFC3261 should really be read as
"TLS-TCP", just like there is now TLS-SCTP defined in RFC4168. The latter
does *not* define a "tls-sctp" value for the 'transport' parameter (i.e.
does not extend the definition for 'transport-param'), because it is not
needed: the use of TLS is solely determined by the URI scheme
"sip" ==> you MAY use TLS (but then upgrade the scheme to "sips:" in the
request sent out)
"sips"==> you MUST use TLS (with possible exception for last hop, i.e. sips
request URI rewritten by proxy to a sip URI obtained from a registered
Contact)
RFC3261 also implicitly discusses the possibility of a "first hop
exception", i.e. a UAC using a "sips:" scheme but not TLS (16.6 point 4).
Note that it does not consider the reverse case of using TLS without "sips:"
as scheme. Some implementations may use 'transport=tls' for this case, but
it is - and should remain - deprecated (i.e. ignored if received, never
generated).
For received Contact and Record-Route headers, it should be mandatory to
maintain state information regarding the transport that was used towards
that hop, and whether TLS was used or not. These are 2 separate items. The
latter is covered by the "secure" flag in RFC3261, for proxies RFC3261
assumes that "sips <==> use TLS" holds, so there is no need for separate
state for proxies regarding the use of TLS.
Regards,
Jeroen
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
