[sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"

Iñaki Baz Castillo ibc at aliax.net
Tue Jul 5 18:42:18 CEST 2011


2011/7/5 Jan Janak <jan at 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 at atlanta.com;transport=tcp" and
      "sips:alice at 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.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-dev mailing list