On Tue, Jul 5, 2011 at 12:42, Iñaki Baz Castillo ibc@aliax.net wrote:
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.
So what is the difference then? How is a Route header with sips scheme different from a Route header with the transport=tls parameter? Is the proxy server supposed to treat Route headers with sips differently than Route headers with sip;transport=tls?
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.
Yeah, I understand this paragraph. I think the motivation for this was to make sips independent of the particular transport mechanism (tls).
But my original question was related to the Route/Record-Route header. There the proxy records the particular transport mechanism that was used when the dialog was being established. So if the INVITE was received over TLS, it would contain ;transport=tls in the Route header.
You mentioned that the Route header should rather contain sips scheme if the scheme of the Request-URI was sips. And I don't understand why. Maybe you're right, but I don't see what difference that would make at the moment.
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.
Elegant is a subjective and it hardly justifies such change, we need more hard evidence supporting such change.
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).
One can hardly blame them, I don't understand sips either ;-).
-Jan
Cheers.
-- Iñaki Baz Castillo ibc@aliax.net