Robert Sparks wrote: [...]
Loop detection at proxies is also a concept that is a carryover
from pre-3261 days. There are many reasons to not loop detect
at proxies - the biggest being the n^2 processing burden it
puts on the network.
Robert:
On the other hand, there are good reasons for proxies to do loop detection.
A couple I can think of are the needs of end UAs to be kept simple and possess a minimal footprint. Thus, burdening them with loop detection may be undesirable. Also, on a wireless network, no point wasting precious airwaves to send a request to a UA only to have it reject the request with a 482 (which incidentally, would be the same response it will receive on the original INVITE).
Clearly the efficiency loop detection affords results in additional processing and thus slowing down of the proxies. But alternatively, it does catch looped requests as early as possible to avoid further use of the network (and host) resources allocated to process a duplicate request.
rfc3261 strikes a good balance between doing it or not for proxies by making it a MAY. I seem to remember from the dim mists of memory that we had discussed this before the release of rfc3261 in August of 2002. The decision was to leave it in the specification as a MAY (someone please correct me if I am mistaken).
Thanks,
- vijay --- Vijay K. Gurbani [EMAIL PROTECTED],research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
