Please correct me, but these and previous other discussions on related topics, such as forking, early media and race conditions seem to confirm the fact that no formal and reliable routing protocol has been developed as yet to route between a larger number (more than 2 in the trapezoid model) of SIP proxies and various (Oh so many) other feature and media servers.
If there were a reliable routing protocol between all the SIP network elements these discussions would not take place for so long and there would be just one RFC describing something like "The SIP Network Routing Protocol". And some open source implementation to prove it. As is, every SIP network must be manually engineered, for every configuration instance and adding yet another new "network service" requires starting all over again. Is this view embarrassingly naïve? It is only meant to defend the view SIP should be used just as a rendezvous and session setup protocol. Henry On 2/20/09 3:05 PM, "Theo Zourzouvillys" <[email protected]> wrote: On Fri, Feb 20, 2009 at 8:28 PM, Dean Willis <[email protected]> wrote: > Of course, that doesn't help with an attack mode that turns UAs into > amplifiers . . . Well, luckily UAs could more easily remain stateless when rejecting responses than proxies, as they don't need to worry about things like forking (be it parallel or serial - e.g due to next hop SRV processing), so should be able to commonly respond to failure responses statelessly. This specific attack only arises when a there can be a invite server transaction created directly by a UDP request that has not been authenticated, and doesn't contain a "via cookie" alas, every UA implementation i've played with to date has almost always been stateful for even failure responses sent over UDP that havn't required a large amount of processing (or any variance) to reach it, except for some very low level induced responses like malformed header fields. ~ Theo
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
