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