On Fri, 2005-11-25 at 22:16 +0100, Jeroen van Bemmel wrote: > opinions differ on this; see also > http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-March/008424.html > > One scenario in which using TCP won't work, is when the client is behind NAT > and/or a firewall. IMO an error response (e.g. 513 Message too large) would > be better (more reliable) in that case
Let me consider my answer more carefully. I don't mean to prescribe a simple rule for how to handle such situations. I don't even like RFC 3261's rather rigid rule for when to use TCP (or other stream protocols) at the beginning of 18.1.1. I was trying to emphasize that an implementation cannot depend on *other* implementations implementing any particular rule on the matter, and should not make its successful function depend on other implementations making particular choices. A good implementation needs to be designed based on careful thought about all the different cases and problems that might arise, and possible recovery strategies from problems, informed by a good knowledge of both the standards and the behavior of real systems. In the case of the question that was asked originally, despite the language in RFC 3261, one cannot depend that the length of a request arriving via UDP is less than 1300 bytes, so one should not automatically assume that UDP is the best choice for forwarding the request. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
