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