2010/10/12 M. Ranganathan <[email protected]>: >>> IMHO this is an exotic specification. What about if the >>> proxy/registart has to route a long request to a user registered in a >>> UDP location? should the proxy try TCP? to which port? what about NAT? >>> So this is a so exotic "feature" that I strongly understand everybody >>> ignores it [*]. >> >> Strongly agreed. >> >> This is one of the most batshit inane, idiotic requirements I have >> ever seen, and it should be rightly ignored by everyone in light of >> the realities of today's Internet. > > MTU discovery using ICMP can give you the maximum size of UDP packet.
"MTU discovery" mechanism is broken by mane servers/routers filtering ICMP packets. Relying on this mechanism is not feasibe in today's world. > Usually it is simpler to implement the following strategy: > > - If the message is below 64K, send the message using UDP. > - If the UDP transaction times out, try TCP transport. I already explained that changing to TCP in case of large messages is a workaround that only works in some cases, and doesn't work in lot of cases: - When the proxy/server doesn't support TCP. - When the request must be send within a dialog whose target is a SIP UDP location (this is: a big NOTIFY cannot be sent over TCP if the SUBSCRIBER used UDP). - When the request must be send via to a user registered under a SIP UDP location. So, changing from UDP to TCP only works when sending single requests not belonging to an existing dialog or registration, which is insufficient. So it's just a ugly workaround and implementors should ignore such exotic and useless "features". > The SIP protocol requires that both UDP and TCP be supported for the > port where the stack is listening. When you create a dialog (INVITE/SUBSCRIBE) using UDP you cannot receive a TCP request/response, so your theroy fails. When a user is behind NAT you cannot open a TCP connection with him from outside the NAT and can only reuse the UDP port mapping open in the router in case the registration is "keep-alived" (i.e. using OPTION from the UAC or from the registrar). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
