5 jul 2011 kl. 20.01 skrev Martin Hoffmann:
Juha Heinanen wrote:
Martin Hoffmann writes:
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
i don't agree with the above.
If I understand things correctly, the above is the intent of the standardization body in charge of SIP.
for example, no matter which transport a request arrives to a proxy, the next hop proxy may be only reachable over tls, in which case i would use ;transport=tls.
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI. Also, if you next hop is only reachable via TLS and, yet the transport parameter and schema indicate unencrypted TCP, what stops you from using the TLS connection you have?
Only the opposite is a problem because you would degenerate the security status of your transmission and that is prohibited by the sips scheme.
I disagree. SIPS and SIP with "transport=tls" are two different things. RFC 3261 deprecated "transport=tls" but it is widely agreed on SIPit testings that we have no other way to handle some situations.
Quoting RFC 5630:
in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;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.
The "tls" parameter has not been eliminated from the ABNF in [RFC3261], Section 25, since the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. The transport=tls parameter has never been defined in an RFC, but only in some of the Internet drafts between [RFC2543] and [RFC3261].
This specification does not make use of the transport=tls parameter.
The reinstatement of the transport=tls parameter, or an alternative mechanism for indicating the use of the TLS on a single hop in a URI, is outside the scope of this specification.
For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- SCTP".
So "transport=tls" is still in need of clarification...
/O