On 08/31/05 12:59, Bogdan-Andrei Iancu wrote:
Hi,
it works, but is not save since you can not be 100% that dst_uri
presence is strictly related to NAT traversal. It's also used by RR
module to force routing after loose_route; and by dispatcher for the
same reasons.....
if you do not call other function that alter the r-uri except
lookup(location) as I said, I do not see why is not 100% sure that the
user is behind the nat. When loose_route() is used, lookup(location)
should not be used, I see no good reason. dispatcher is for load
balancing and it is usually in front of registrar. In this
circumstances, I would say that the situations to have many settings of
dst_uri is very less probable.
Daniel
I see here two ways of approaching this issue:
- to have per-branch flags also before transaction creation; will
be a new param to append_branch (8 in total :-/), but this flags will
not be accessible from script; only in branch route;
- use something else than flags for NAT marking (something already
present in all branch stages): nathelper, when builds the received URI
(which will become dst_uri) will append a "nat=yes" parameter; this
parameter will be easyly identify in branch route and NAT traversal
may be activated....
any comments or new options are welcomed.......
regards,
bogdan
Daniel-Constantin Mierla wrote:
I would say yes, if you do not call other
functions that alter the
r-uri/dst_uri, except lookup("location").
Daniel
On 08/30/05 19:43, Richard Z wrote:
Just a thought... is it possible to ingore the
nat flag and just
rely on the existence of dst_uri to indicate a NATed UA?
On 8/29/05, *Klaus Darilion* < klaus.mailinglists(a)pernau.at
<mailto:klaus.mailinglists@pernau.at>> wrote:
Ho Bodgan!
To use branch routes for branch-only NAT traversal also the
nathelper
and mediaproxy functions must be adopted to work in branch routes.
regards
klaus
Bogdan-Andrei Iancu wrote:
Hi,
indeed, prior branch_route, there is only one set of flags
shared by all
> branched - that's still unchanged.
>
> regards,
> bogdan
>