On Wed, 2003-10-08 at 13:38, Vijay K. Gurbani wrote: > 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. A UA doesn't do loop detection. It does merge detection. It has to do merge detection whether things in the network are loop detecting or not. So I don't see your point here.
> 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). Huh? The last hop is the only one over the air. An endpoint is only going to 482 if its a merged request, not a loop. It doesn't even make sense to be talking about loops at this hop, so I assume you are talking about having proxies detect merges. _THAT_ is a different conversation. Proxies are forbidden to reject merged requests. > > 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). Loop detection was left as a MAY, merge detection was not. > > 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
