[Devel] loop detection fix

[Bogdan-Andrei Iancu]

Hi,

from an implementer point of view I would suggest a different approach 
of the issue: the same number of elements will be tested, but instead of 
encoding them all into an id (md5, hash, xor, whatever), just tests them 
ad-literam each one of them.

why?

1) it;s much much faster - if  I need to encode all into an ID, I need 
to parse all the elements which prove a bit expensive...not to count the 
encoding; if I do sequential checking with all elements, I can stop at 
the first difference (ex; check first the callid - if match, continue 
with from tag, etc).
Considering that in 99% of the case the result will not be loop 
detected, it will spare a lot of parsing and testing.

2) we do not have any potential collisions due the encoding algorithm.

3) no need to put extra stuff in the request via. Note that playing with 
the branch param can be dangerous since it is also used for transaction 
matching.

4)  same matching elements are checked, but the checking sequence is 
different, so we do not loose anything from the RFC specs.


regards,
bogdan

Juha Heinanen wrote:

>Daniel-Constantin Mierla writes:
>
> > The issue is with hash value. Somehow should ensure unique values, but 
> > most algorithms dont. They recommend in draft to use md5 which has low 
> > probability of collision.
>
>i guess that md5 is the best there is.
>
> > Also, Route set has to be taken in consideration. Not usre if R-URI and 
> > Routes have to be canonized -- r-uri to username/host/port/proto and 
> > route to host/port/proto.
>
>route set would need to be included only if proxy configuration allows
>pre-loaded route set that includes more routes than one for the proxy
>itself.  this could be a module parameter.
>
>i don't think that any canonization would be needed, since if host name
>gets changed to ip/port, then loop would be detected next time when that
>same ip/port shows up in r-uri.
>
>-- juha
>
>_______________________________________________
>Devel mailing list
>Devel at openser.org
>http://openser.org/cgi-bin/mailman/listinfo/devel
>
>  
>