> Could you clarify "resolv" and "attempt to use"? By "resolve", I mean undergo the typical RFC 3263 rules to determine address, port, and transport.
By "attempt to use" within my statement "attempt to use reliable transport to the same IP address and port that you would have used for UDP", I mean try to use it (with the understanding that opening/using the TCP connection might not work). > 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? The following is my understanding of RFC 3263 use of NAPTR. Thus only 1 transport type is selected. Similarly only 1 transport type is selected when using SRV. "The NAPTR processing as described in RFC 2915 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server." > 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. That ignores the RFC 3261 requirement. However some do ignore it because of configuration or other reasons (such as to avoid potential delays). > 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. However, the solution has issues since the sender does not necessarily know in advance that using TCP will work to the UDP's address/port. > If they prefer UDP, but like TCP for large messsages, using UDP prio in > NAPTR accomplishes this. Yes; however fragmentation will occur if the sender does not support that aspect of RFC 3261 (because of configuration or other reason). > 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! :-( The size rule is to override the "transport" result of the RFC 3263 process. -- 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
