2011/7/5 Jan Janak jan@ryngle.com:
But why would anyone want to use this in the Route header? By using sips instead of sip;transport=tls in a Route header the proxy server is enforcing that it is to be contacted securely during the dialog, even if the original request (that established the dialog) may not have been subject to such a restriction. In other words request path that was fine for the INVITE is no longer fine for the re-INVITE or BYE.
Hi Jan, the Route header will be removed by each proxy in the path, so there is no restriction for in-dialog requests. Example:
A P1 P2 B
-----INV TLS----->
----- INV UDP ----> RR: sips:P1;tcp
----- INV UDP ----> RR: sip:P2;udp RR: sips:P1;tcp
The 200 arriving to A would contain:
SIP/2.0 200 OK Record-Route: sip:P2;transport=udp Record-Route: sips:P1;transport=tcp Contact: sip:B;transport=udp
So A would generate an ACK as follows:
ACK sip:B;transport=udp SIP/2.0 Route: sips:P1;transport=tcp Route: sip:P2;transport=udp
then A would route the ACK to P1 using TLS (as topmost Route has sips).
P1 would remove the topmost Route (loose-routing) so the ACK would become:
ACK sip:B;transport=udp SIP/2.0 Route: sip:P2;transport=udp
then P1 would route the ACK to P2 using UDP (as topmost Route is sip with udp).
And so on.
So a sips scheme in a Route header is just hop-by-hop information, and not end-to-end.
However a sips schema in a request URI mandates all the path to be secure, but that is not the case of a sips in a Record-Route header.
Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used?
RFC 3261 deprecates the usage of transport=tls in section 26.2.2 SIPS URI Scheme:
Note that 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.
But anyway, in other thread in sip-implementors I got the conclussion that RFC 3261 deprecates sips schema with transport=tls, but says nothing about sip schema with transport=tls (in fact, "tls" is still a valid transport according to the BNF grammar). So, I don't say that current sip-router behavior is wrong, but I think it would be more "ellegant" if it would use sips URI and ;transport=tcp.
NOTE: In fact, some existing clients (as the widely extended PJSIP) would fail if the Record-Route contains sips+transport=tcp as I've reported today: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-July/013102.html
This is because PJSIP does not understand at all the meaning of a sips schema (ugly in a so widely deployed SIP stack).
Cheers.