Hi again Brett, thanks a lot for your input so far. Think I might have been a bit unclear in one respect though, but lets start with:
>> 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. Do you really think that is clear in 3261? The transport chapter says NOTHING regarding DNS/NAPTR. It just explicitly 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. *Addtionally*, the description just before saying: The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations. This to me describes a scenario where higher layers perform 3263 procedures, and THEN the transport layer might hit the 1300 rule, forcing ~TCP. The following text saying: If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, also hints at the higher layers wanting to send over for instance UDP, which could have been selected by NAPTR.(or ip||port, etc) I would still like to know the answer on which order you would use the transports in my previous question, since it referred to a failure scenario. So when you do not get get any responses to your requests/connection attempts, in which order would you test the different transports and destinations: 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 logic you described indiicated you would first try UDP, then TCP? But then the logic of falling back to UDP when tcp fails, is completely useless? This is another reason why I feel that the transport-rule in 18.1.1 should *override* whatever NAPTR indicates, because if you cant, the fallback requirement is less usefull. Regards Taisto Qvist -- _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
