Subject: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes.

From: Taisto Qvist <[email-masked]>
Date: Tue, 6 May 2014 11:20:58 +0000

Hi, 

I have been figure out how to interpret the MUST rule of rfc3261's chapter 18.1.1. that says:

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP.

in relation to DNS NAPTR priorities for selecting transport protocol.

The initial paragraph(just preceding the above rule) of 18.1.1 says that:

   "The user of the transport layer passes the client transport the request, 
   an IP address, port, transport, and possibly TTL for multicast destinations."

Which to me implies that DNS lookup according to rfc3263 has been performed, and that the rule above  will/can OVERRIDE the NAPTR priorities?

Reading rfc3263 sometimes uses the phrase: 

   However, another transport, such as TCP, MAY be used if the guidelines of 
   SIP mandate it for this particular request.
   
However, only directly in connection with URI's containing IP and/or port, or scenarios where NAPTR does not exist.

So, in a scenario where NAPTR *are* configured(for instance with UDP as highest priority), are you supposed to ignore the MUST rule in 18.1.1 above??

I am definitely in need of clarification, since 18.1.1 doesn't refer at all to the procedures of rfc3263 and how they can impact this rule of protocol selection.

Best Regards
Taisto Qvist

---

From: Brett Tate <[email-masked]>
Date: Tue, 6 May 2014 08:13:13 -0400

> Which to me implies that DNS lookup according to rfc3263
> has been performed, and that the rule above  will/can
> OVERRIDE the NAPTR priorities?

Correct; the size rule overrides the already determined transport for the
request (unless CANCEL or non-2xx ACK).

> So, in a scenario where NAPTR *are* configured (for
> instance with UDP as highest priority), are you supposed
> to ignore the MUST rule in 18.1.1 above??

No.

-- 

See why you should attend BroadSoft Connections 2014<http://broadsoftconnections.com/>

This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 09:47:59 -0400

> From: Taisto Qvist <[email-masked]>
> 

My interpretation of the rules is that the DNS lookup process
generates a prioritized list of addresses/ports/transports.  This list
is then filtered depending on the context.  If the rule in 18.1.1 is
triggered, all the elements of the list that have transport=UDP are
removed.  If not, and if a transport parameter was specified, elements
that do not match the transport parameter are removed.  (There is
further filtering if the URI is sips:, but I don't know them.)

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 14:08:18 +0000

Agree - it is still possible to take information from the NAPTR record and comply with the RFC 3261 requirement, e.g. in selecting TCP over SCTP.

Regards

Keith 

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of 
> Dale R. Worley
> Sent: 06 May 2014 14:48
> To: Taisto Qvist
> Cc: [email-masked]
> Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 
> 1300 bytes.
> 
> generates a prioritized list of addresses/ports/transports.  
> This list is then filtered depending on the context.  If the 
> rule in 18.1.1 is triggered, all the elements of the list 
> that have transport=UDP are removed.  If not, and if a 
> transport parameter was specified, elements that do not match 
> the transport parameter are removed.  (There is further 
> filtering if the URI is sips:, but I don't know them.)
> 
> Dale
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brett Tate <[email-masked]>
Date: Tue, 6 May 2014 10:40:46 -0400

Hi,

I disagree with both interpretations.  My interpretation is that the RFC
3263 NAPTR/SRV process only selects a single transport type; UDP was
selected within this situation.  The RFC 3261 size rule overrides the
selected transport type (but still uses the address and port associated
with UDP) and provides a fallback to the selected transport type.

This is the reason for the following RFC 3261 section 18.2.1 snippet:

"For any port and interface
 that a server listens on for UDP, it MUST listen on that same port
 and interface for TCP.  This is because a message may need to be sent
 using TCP, rather than UDP, if it is too large."

> From: sipcore [mailto:[email-masked]] On Behalf Of DRAGE,
> Keith (Keith)
> Sent: Tuesday, May 06, 2014 10:08 AM
> To: Dale R. Worley; Taisto Qvist
> Cc: [email-masked]
> Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes.
>
> Agree - it is still possible to take information from the NAPTR record
> and comply with the RFC 3261 requirement, e.g. in selecting TCP over
> SCTP.
>
> Regards
>
> Keith
>

--

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 11:27:46 -0400

> further filtering if the URI is sips:, but I don't know them.)

This is consistent with my feeling of how it *ought* to work.

Whether that is what was *intended* is a slightly different question, 
and one I don't know the answer to.

	Thanks,
	Paul

---

From: Taisto Qvist <[email-masked]>
Date: Wed, 7 May 2014 06:52:00 +0000

Thanks Keith, but I was more thinking about the situation that NAPTR configuration prioritizes UDP, and then the message is larger than 1300 bytes.

In this case it I don't know which rule is more important? When NAPTR config "disagrees" with rfc3261, which takes precedence?

Regards
Taisto

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: den 6 maj 2014 16:08
To: Dale R. Worley; Taisto Qvist
Cc: [email-masked]
Subject: RE: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes.

Regards

Keith 

> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. 
> Worley
> Sent: 06 May 2014 14:48
> To: Taisto Qvist
> Cc: [email-masked]
> This list is then filtered depending on the context.  If the rule in 
> 18.1.1 is triggered, all the elements of the list that have 
> transport=UDP are removed.  If not, and if a transport parameter was 
> specified, elements that do not match the transport parameter are 
> removed.  (There is further filtering if the URI is sips:, but I don't 
> know them.)
> 
> Dale
>

---

From: Taisto Qvist <[email-masked]>
Date: Wed, 7 May 2014 07:14:55 +0000

Hi, 

This is somewhat similar to what my interpretation has been before as well.  But after some discussions with Brett on sip-implementors, I've realized that I've missed the rules of 2915/NAPTR Order values, which quite(?) clearly says that once you've selected a NAPTR RR with a specific Order value, that *it*. 

      Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order....

So at least in the case of different Order values for the different protocols, you should only use the first match. If the Order values are the same though.....?

But still...it feels like the two algorithms/rules collide a bit, or are at least in need of clarification. Especially that rfc 3263, chapter 4.1 only refers to the size-rule as a *MAY* in scenarios where we don't have or use NAPTR. 

A MAY requirement, referring to a MUST requirement.

Regards
Taisto Qvist

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: den 6 maj 2014 15:48
To: Taisto Qvist
Cc: [email-masked]
Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes.

> in relation to DNS NAPTR priorities for selecting transport protocol.

My interpretation of the rules is that the DNS lookup process generates a prioritized list of addresses/ports/transports.  This list is then filtered depending on the context.  If the rule in 18.1.1 is triggered, all the elements of the list that have transport=UDP are removed.  If not, and if a transport parameter was specified, elements that do not match the transport parameter are removed.  (There is further filtering if the URI is sips:, but I don't know them.)

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 7 May 2014 11:08:47 +0000

Exactly as others have indicated. If the length exceeds the limit then the absolute RFC 3261 requirement (MUST) applies, i.e. not use UDP. 

I am aware of implementations that can be set to override this, but they are non-conformant to the RFC.

Regards

Keith

> From: Taisto Qvist [mailto:[email-masked]] 
> Sent: 07 May 2014 07:52
> To: DRAGE, Keith (Keith); Dale R. Worley
> Cc: [email-masked]
> Thanks Keith, but I was more thinking about the situation 
> that NAPTR configuration prioritizes UDP, and then the 
> message is larger than 1300 bytes.
> 
> In this case it I don't know which rule is more important? 
> When NAPTR config "disagrees" with rfc3261, which takes precedence?
> 
> Regards
> Taisto
> 
> Agree - it is still possible to take information from the 
> NAPTR record and comply with the RFC 3261 requirement, e.g. 
> in selecting TCP over SCTP.
> 
> Regards
> 
> Keith 
> 
> > > I have been figure out how to interpret the MUST rule of 
> rfc3261's 
> > > chapter 18.1.1. that says:
> > >