Juha Heinanen schrieb:
Klaus Darilion writes:
> It is not possible to detect if a reply comes from a proxy or not.
klaus,
yes, but the two via test tells that ua is not taking directly to this
sr instance and i thus don't need to care about it.
> could add the alias anyway and handle the problem in "handle_alias": If
> alias parameter is removed from RURI (in-dialog request), set $du only
> if it was not already set by loose_route().
i first thought to add the $du test, but looks like the via test makes
it unnecessary. however, loose_route() may be key to solving the reply
problem: if loose_route() sets $du, it means that next hop is another
proxy. then it is possible to set TO_PROXY flag and test it
onreply_route. right?
yes, but only in in-dialog requests.
In my setups currently I do the NAT decision in first request processing
and store the result in a RR-cookie. in-dialog NAT handling is purely
done on RR-cookie. RR-cookie defines if NAT handling is done for caller,
callee or both.
Regarding NAT-detection my decision algorithm is simple and pragmatic:
if request comes from a local account (is_from_local()), then the caller
will be marked for NAT traversal (regardless if behind NAT or not.
Further, target will be analysed and calls to local users will be
NAT-handled.
regards
klaus
> I think the functions are great to have, but would like different naming
> (either have "alias" always at the beginning or at the end of the
> function name).
>
> e.g: add_alias(), handle_alias()
i can change the names. thanks for helping out on this.
-- juha
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
