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@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Ho Bodgan! To use branch routes for branch-only NAT traversal also thenathelper 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 >