Hi Bret, Could you clarify "resolv" and "attempt to use"? I'm wondering when you mean that you will actually send traffic..
If I had an 1400 byte request, with a next-hop FQDN that resolved to NAPTR with prio "1:UDP, 2:TCP", what transmission attempts would you make, in what order? (and lets say that the srv-lookup returns the same two hosts, as1.examle.com, and as2.example.com) The below text sounds like you would first try UDP, then TCP? But then the logic of falling back to UDP when tcp fails, seems kind of useless? I would prefer (for large messages) 1) TCP to as1, and if it fails, UDP to AS1(udp-fallback rule) 2) TCP to as2, and if it fails, UDP to AS2(udp-fallback rule) Another curious scenario is how to behave when you only find NAPTR for a single protocol. My current feeling is that if I only find NAPTR pointing to UDP, I will not perform TCP attempts, even if the packet is >1300. With that behavior in mind(depending on how correct my assumptions are), I think that allowing the 1300 rule to override NAPTR priorities is nice, since it enables an automatic fragmentation avoidance, while still enabling UDP for small packets if that is what I normally prefer. It makes it possible for a destination to ensure that if they REALLY dont want a specific protocol, they can ensure this by configuring only the other NAPTRs. If they want TCP for everything, setting NAPTR prio for TCP will accomplish this. If they prefer UDP, but like TCP for large messsages, using UDP prio in NAPTR accomplishes this. If the size rule is not supposed to enable overriding of NAPTR priorities, it means that my only way of avoiding fragmentation is to use TCP for everything! :-( Regarding my second issue, about having same priorities, I was wonderingen wether there is a real BENEFIT to using this. Yes, you CAN, and it seems to result in that the sender can use whatever transport he feels like...which to me means that I as a receiver can never know what will be used. That, to mee, would be less attractive. I am mainly looking to ensure that my feeling that its better to priorities your NAPTRs to know what *should* be the default is not way of the target, and that there are some real scenarios where same-prio NAPTRs are a GOOD idea. Thanks for your reply so far, and I hope others might chime in as well. Regards Taisto Qvist ----- Original Message ----- From: "Brett Tate" <br...@broadsoft.com> To: "Taisto Qvist" <taisto.qv...@ip-solutions.se>, sip-implementors@lists.cs.columbia.edu Sent: Friday, 25 April, 2014 1:09:16 PM Subject: RE: [Sip-implementors] Transport Selection dependent on message size and NAPTR priorities (pitting rfc3261 vs rfc3263) Hi, My interpretation is that you resolve per typical RFC 3263 rules first (although potentially higher likelihood of failure). Then if the request's size exceeds the threshold (and not CANCEL or non-2xx ACK), attempt to use reliable transport to the same IP address and port that you would have used for UDP. If it fails (as described within RFC 3261 section 18.1.1), the device should retry using UDP (with appropriate Via adjustments). Concerning your same priority question, the following is within RFC 2915 section 7.1. It basically means that you have no preference. "note that the values of the order and preference fields are equal in all records, so the client is free to pick any record." -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- implementors-boun...@lists.cs.columbia.edu] On Behalf Of Taisto Qvist Sent: Friday, April 25, 2014 6:37 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Transport Selection dependent on message size and NAPTR priorities (pitting rfc3261 vs rfc3263) Hey Sippers, I would like to get everyones option on the interpretation of how to select transport protocol in rfc3261/3. It mainly concerns the issue of when to allow rfc3261's rule of "if bigger than 1300, use reliable transport", over-ride the rules of rfc3263. Since I've always been of the persuasion that I want to avoid IP fragmentation as much as possible, I've always considered the 1300-rule to override NAPTR priorities, but discussions have made me realize that the text in rfc3263 which refers to this rule, is referenced regarding to scenarios with the URI containing IP address and/or port. So the simple question is, should the message size over-ride NAPTR priorities? Is the rfc3261 rule of chapter 18.1.1 more "important" or not? Additionally, can you see any useful scenario of using SAME priority NAPTRs for your supported transport protocols? Best Regards Taisto Qvist (S)IP Teacher and Developer _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- 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. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
