31 Aug
2005
31 Aug
'05
6:30 a.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?