Olle E. Johansson wrote:
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
It's like in HTTP world:
- http:// means HTTP over TCP.
- https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport
param. But SIP protocol can work over different transport layers (TLS
is not a transport layer).
You can not compare sips with https. Sorry.
https puts a requirement for TLS all the way.
SIPS: in RFC3261 did not.
RFC 3261, section 4:
| A call made to a SIPS URI guarantees that secure, encrypted transport
| (namely TLS) is used to carry all SIP messages from the caller to the
| domain of the callee. From there, the request is sent securely to
| the callee, but with security mechanisms that depend on the policy of
| the domain of the callee.
It's simply a request, a proposal. Now if you
don't want to change the
properties of the original request, but still require your
infrastructure to use TLS for the next hop you do not want to change
to a SIPS: uri, which will put a new requirement for the rest of the
signalling. You want to add an attribute like ";transport=tls".
Why? We are talking about the URI in the (Record-) Route header here,
which _only_ indicates how to get to the next hop. If you put a SIPS URI
in there, this has no consequence whatsoever for the complete path.
Yes, SIPS: is really messy and hard to understand.
I'd argue it's completely broken like so many things in SIP. IETF went
out to publish a document to fix it. After much argueing, this became
RFC 5630 and people are confused as ever.
How would you guys
handle a Contact: with SIPS: ?
In a dialog or in a registration?
Can you reuse a connection like
outbound? I guess not, since you have to verify the endpoint
certificate.
If you reuse a connection you'd have done that already earlier. Most
likely, the client opened the conneciton to you in the first place.
One final word: What Iñaki and me are argueing here is what the standards
say. What we probably don't agree on is what this means in practice. For
me as someone who regularly has to bring different SIP implementations
together, it means pretty much nothing. You'd never find SIPS URIs in
the wild but plenty of transport=tls. (Or well, not really, nobody is
using TLS in practice anyways.)
Regards,
Martin