[sr-dev] alias_contact()/handle_alias() ready for testing

Klaus Darilion klaus.mailinglists at pernau.at
Mon Nov 9 13:31:50 CET 2009



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
> 
> 



More information about the sr-dev mailing list