29 Aug
2005
29 Aug
'05
11:15 a.m.
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
29 Aug
29 Aug
11:21 a.m.
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
11:45 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:23 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
30 Aug
30 Aug
6:43 p.m.
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> 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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:58 p.m.
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:
_______________________________________________
Users mailing list
Users(a)openser.org <mailto:Users@openser.org>
http://openser.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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(a)openser.org <mailto:Users@openser.org>
> http://openser.org/cgi-bin/mailman/listinfo/users
<http://openser.org/cgi-bin/mailman/listinfo/users>
31 Aug
31 Aug
11:59 a.m.
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(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
>
12:18 p.m.
Bogdan-Andrei Iancu writes:
- 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;
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 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....
where is this "nat=yes" parameter added and by which nathelper function?
-- juha
12:30 p.m.
Hi Juha,
Juha Heinanen wrote:
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:
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.
- 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;
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 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....
where is this "nat=yes" parameter added and by which nathelper function?
12:44 p.m.
Bogdan-Andrei Iancu writes:
- 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?
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
12:34 p.m.
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
>
6835
days inactive
6837
days old
10 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion -
Richard Z