Hi!
The nat flag which will be loaded during lookup() - will it be set for each branch so it can be queried in branch_route for all of the registered contacts, or should I use isdsturiset() instead of testing for the NAT flag?
regards klaus
Klaus Darilion writes:
The nat flag which will be loaded during lookup() - will it be set for each branch so it can be queried in branch_route for all of the registered contacts, or should I use isdsturiset() instead of testing for the NAT flag?
i don't think that there is any changes regarding nat flag yet. nat flag is set if any of the contacts is behind nat. it would be nice if nat flag would be automatically set in branch route only if contact of the corresponding branch is behind nat.
-- juha
Hi,
indeed, prior branch_route, there is only one set of flags shared by all branched - that's still unchanged.
regards, bogdan
Juha Heinanen wrote:
Klaus Darilion writes:
The nat flag which will be loaded during lookup() - will it be set for each branch so it can be queried in branch_route for all of the registered contacts, or should I use isdsturiset() instead of testing for the NAT flag?
i don't think that there is any changes regarding nat flag yet. nat flag is set if any of the contacts is behind nat. it would be nice if nat flag would be automatically set in branch route only if contact of the corresponding branch is behind nat.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
Juha Heinanen wrote:
Klaus Darilion writes:
The nat flag which will be loaded during lookup() - will it be set
for > each branch so it can be queried in branch_route for all of the
registered contacts, or should I use isdsturiset() instead of
testing > for the NAT flag?
i don't think that there is any changes regarding nat flag yet. nat flag is set if any of the contacts is behind nat. it would be nice if nat flag would be automatically set in branch route only if contact of the corresponding branch is behind nat.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 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
Juha Heinanen wrote:
Klaus Darilion writes:
The nat flag which will be loaded during lookup() - will it be set
for > each branch so it can be queried in branch_route for all of the
registered contacts, or should I use isdsturiset() instead of
testing > for the NAT flag?
i don't think that there is any changes regarding nat flag yet. nat flag is set if any of the contacts is behind nat. it would be nice if nat flag would be automatically set in branch route only if contact of the corresponding branch is behind nat.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 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 > > > Juha Heinanen wrote: > >> Klaus Darilion writes: >> >> > The nat flag which will be loaded during lookup() - will it be set >> for > each branch so it can be queried in branch_route for all of the >> > registered contacts, or should I use isdsturiset() instead of >> testing > for the NAT flag? >> >> i don't think that there is any changes regarding nat flag yet. nat >> flag is set if any of the contacts is behind nat. it would be nice if >> nat flag would be automatically set in branch route only if contact of >> the corresponding branch is behind nat. >> >> -- juha >> >> _______________________________________________ >> Users mailing list >> Users@openser.org <mailto:Users@openser.org> >> http://openser.org/cgi-bin/mailman/listinfo/users <http://openser.org/cgi-bin/mailman/listinfo/users> >> >> >> > > _______________________________________________ Users mailing list Users@openser.org <mailto:Users@openser.org> http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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.....
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 >
Bogdan-Andrei Iancu writes:
- to have per-branch flags also before transaction creation; will bea new param to append_branch (8 in total :-/), but this flags will not be accessible from script; only in branch route;
this is what i thought would need to be done, i.e., add int nat_flag as a new field in struct branch. yes, append_branch would need a new param for it.
- use something else than flags for NAT marking (something alreadypresent 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....
where is this "nat=yes" parameter added and by which nathelper function?
-- juha
Hi Juha,
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
- to have per-branch flags also before transaction creation; will bea new param to append_branch (8 in total :-/), but this flags will not be accessible from script; only in branch route;
this is what i thought would need to be done, i.e., add int nat_flag as a new field in struct branch. yes, append_branch would need a new param for it.
I was thinking more general: not only a nat_flag, but a set of flags -maybe other flags will be required in the future. But there are some logical issues: - you have flag set X in branch array and a flag set Y in the request - when the branch is built in TM, the per-branch flag set should be X|Y, right? - once a branch is appended, you cannot change from script its flags....or more general, you will not be able to manipulate the branch flags previous to branch route.
- use something else than flags for NAT marking (something alreadypresent 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....
where is this "nat=yes" parameter added and by which nathelper function?
the idea was to make "fix_nated_register" to add to RCV_URI AVP (which will be saved in usrloc as received) the "nat=yes" param....
regards, bogdan
Bogdan-Andrei Iancu writes:
- you have flag set X in branch array and a flag set Y in therequest - when the branch is built in TM, the per-branch flag set should be X|Y, right?
when ul creates adds the branches for the contacts, it would mark in struct branch of each contact if that branch is behind nat or not. when nat flag is then tested in branch route, it would be that branch specific nat flag. so only the nat flag would be overridden.
if you want to store all flags per branch, then things get more complicated, since i guess we would need to mark in branch struct also which flags have been set per branch, because only those should be overridden for each branch route.
-- juha
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 >
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion -
Richard Z