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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
