Subject: [sipcore] RFC 3263 NAPTR Rules

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Dec 2014 15:13:23 +0100

Hello! 
In a discussion about NAPTR today I ended up confusing myself and reading the RFC did not make me less confused.

Section 4.1 says:

"If the server supports
   multiple transport protocols, there will be multiple NAPTR records,
   each with a different service value."

Later the same section says:

"If a SIP proxy, redirect server, or registrar is to be contacted
   through the lookup of NAPTR records, there MUST be at least three
   records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
   service field, and one with a "SIPS+D2T" service field."

These doesn't work together. The first part says "IF" but the second says "MUST".

Does this allow me to publish a NAPTR record set only with TLS?

If I MUST publish three NAPTR records - how can I say "this is my record and I don't want you to connect using this transport"

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Dec 2014 10:46:36 -0500

"Olle E. Johansson" <[email-masked]> writes:
> If I MUST publish three NAPTR records - how can I say "this is my
> record and I don't want you to connect using this transport"

Are you allowed to do that?  Aren't SIP servers required to listen on
both UDP and TCP?

This may be modified by RFC 5630 (revised use of SIPS), though.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Dec 2014 19:12:55 +0100

> Are you allowed to do that?  Aren't SIP servers required to listen on
Yes, but in NAPTR I show how I *want* to be connected to :-)

> This may be modified by RFC 5630 (revised use of SIPS), though.
The word "NAPTR" is not mentioned in that document. Nor is "DNS".

SIP/TLS is the only NAPTR record I want to publish.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Dec 2014 09:20:19 +0100

> If I MUST publish three NAPTR records - how can I say "this is my record and I don't want you to connect using this transport"

Seems like we need to clear this up somewhere. 

In addition to the above issues we now have a situation where a server may support WebSocket transport, but a NAPTR record
for that transport does not make sense. That may be in the WebSocket RFC though.

/O