[SR-Users] NAPTR, SRV and sips vs. transport=tls

[Andreas Granig]

Hi,

Hope to get some guidance here over the usage of "sips" and "sip plus
transport=tls" when following RFC3263.

The RFC3263 says that a NATPR record could return something like this
for a query like "host -t NAPTR example.com":

   ;          order pref flags service      regexp  replacement
      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.

This means that the client should use sips if possible when contacting
example.com.

Concluding from that, I suppose it should perform an SRV lookup "host -t
SRV _sips._tcp.example.com", and the result would be:

   ;;          Priority Weight Port   Target
       IN SRV  0        1      5061   server1.example.com
       IN SRV  0        2      5061   server2.example.com

What I'm curious about is how requests towards one of these servers
should look like, and how they are being handled by kamailio.

A lot of clients and servers are sending
"sip:user at example.com;transport=tls" in request URIs and Contact headers
and Record-Route headers, and you can check with
uri_param("transport","tls") which transport socket to use. This is
pretty useful as you can determine hop-by-hop whether or not to use TLS.
This approach has been obsoleted by RFC3261 though, and there doesn't
seem to be a mechanism in RFC3263 to indicate "use schema sip, but use
transport=tls".

On encounter of a NAPTR record like the one above, how does kamailio
act? Does it set a "sips" schema for the next hop?

And what's the general take on this "sips" schema? As far as I
understand RFC3261, it means that if a client sends a request to a
sips-URI, the request is sent to the domain via TLS, and 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." (RFC3261,
Chapter 4). What does this really mean in practice? Are you allowed to
rewrite the schema to "sip" and pass it on for example via UDP to the
callee if the callee didn't indicate transport=tls (deprecated anyways)
or "sips:" in the Contact of the registration? Or should you keep "sips"
as schema, but still send it via UDP, because you know based on local
policy or based on client registration that the next hop is not
supporting TLS? How would widespread clients react when getting a call
to a "sips" URI, especially if they receive it via UDP?

Looking forward hearing your input on that,
Andreas




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121201/a21765ad/attachment.pgp>