Hi there,
as concept, the branch flags are the same as former pseudo-branch flags.
What was needed, was a separation of the transaction flags from the
branch flags (formally, the branch flags were a part of the transaction
flags). Why was this needed?
1 - more consistency - as separate sets of flags, the risk to make
confusion and mistakes is reduced.
2 - extend the flag space - formally all available flags were 32,
which were split in 2 types - per transaction and per branch
3 - coherence - with the new approach, the RURI has his own set of
branch flags, so all branches (including RURI) are equivalent;
previously, the RURI branch flags were transaction flags
4 (and more important) - the new design make possible to save the
branch flags into usrloc (during registration); it was critical to make
a correlation between the branch flags and contact flags (some internal
stuff :-/).
hope I manage to bring some light :)
regards,
bogdan
Weiter Leiter wrote:
Answering the call for feedback,
Script local flags are clear to me.
But I fail to see the clear benefits of transaction+branch(new) over
the transaction+"pseudo-branch"(old) flags. Please correct me if
wrong, but pseudo-branch flags:
- inherit the (transaction) flags from route 0;
- are local to each branch: so if setflag(11) in branch_route of
branch A, isflagset(11) will return false in branch_route of branch B
(which is concurrent with A, but effectively runs "after" it -
parallel fork);
- are visible in replies routes: so if setflag(10) in onreply_route of
branch A, isflagset(10) will return false in onreply_route of branch B
(also in case that this reply of B comes after reply of A).
So, accounting, what I see as brand new - in pseudo-branch(old) vs.
branch(new) - is having flags - of type new transaction/message -
which are globally visible, in all request & replies (& failure?)
routes. Any glaring error?
Disclaimer: I only have a shallow understanding of flags, don't shoot
the bullets to hard. :-)
WL.
On 1/9/07, *Bogdan-Andrei Iancu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi everybody,
Following some discussions with Juha regarding some extension for the
branch flags, we decided it is better to have a re-design of flags in
openser to allow a better flexibility and extensibility without any
consistency penalties.
What we had so far:
- message flags (or transaction flags) which are transaction
persistent
- pseudo-branch flags - a set of flags from the message flags were
handled by TM as branch flags
(saved per branch and not only per transaction).
What we have now:
- message flags (or transaction flags) will works as they do now,
but the branch mask will be removed (rolling back as in 0.9.x
versions).
These flags are transaction persistent.
- branch flags (NEW) are saved also in transaction, but per
branch;
also they will be saved in usrloc (per contact). A new set of
functions
were added for manipulating these flags from script. So, there flags
will be registration persistent and branch persistent.
- script flags (NEW) are no-message-related flags - they are only
script persistent and you can strictly use them for scripting.
Once you
exit a top level route, they will be lost. These flags are useful and
they offer an option to de-congest the message flags - many flags have
no need to be saved as they just reflect some scripting status.
What changes brings this:
- NAT flag will become a branch flag all the time.
- you can have custom flags to be saved into usrloc (via
branch flags).
- more flags in script (via script flags).
Corresponding Functions:
Message/transaction flags:
setflag(flag_idx)
resetflag(flag_idx)
isflagset(flag_idx)
Branch flags:
setbflag/setbranchflag(branch_idx,flag_idx)
resetbflag/resetbranchflag(branch_idx,flag_idx)
isbflagset/isbranchflagset(branch_idx,flag_idx)
or, the shorter format, working on the default (branch 0) flags:
setbflag(flag_idx)
resetbflag(flag_idx)
isbflagset(flag_idx)
Script flags:
setsflag/setscriptflag(flag_idx)
resetsflag/resetscriptflag(flag_idx)
issflagset/isscriptflagset(flag_idx)
Flags and Pseudo Variables
Message/transaction flags
$mf (decimal) , $mF (hexa)
Branch flags
$bf (decimal) , $bF (hexa)
Script flags
$sf (decimal) , $sF (hexa)
Flags and routes:
Message/transaction flags
These flags will show up in all routes where messages related to
the initial request are processed. So, they will be visible and
changeable in onbranch, failure and onreply routes; the flags will be
visible in all branch routes; if you change a flag in a branch route,
the next branch routes will inherit the change.
Branch flags
There flags will show up in all routes where messages related to
initial branch request are processed. So, in branch route you will see
different sets of flags (as they are different branches); in onreply
route yo will see the branch flags corresponding to the branch the
reply
belongs to; in failure route, the branch flags corresponding to the
branch the winning reply belongs to will be visible.
In request route, you can have multiple branches (as a result
of a
lookup(), enum query, append_branch(), etc) - the default branch is 0
(corresponding to the RURI); In reply routes there will be only one
branch , the 0 one. In branch route the default branch is the current
process branch (having index 0); In failure route, initialy there is
only one branch (index 0), corresponding the the failed branch.
Script flags
There flags are available only in script and are reset after each
top level route execution (routes internally triggered by
OpenSER). They
will be persistent per main route, onreply_route, branch_route,
failure_route. Note they will be inherit in routes called from
other routes.
Example: nat flag handling
..........
# 3 - the nat flag
modparam("usrloc","nat_bflag",3)
..........
route {
..........
if (nat detected)
setbflag(3); # set branch flag 3 for the branch 0
..........
if (is_method("REGISTER")) {
# the branch flags (including 3) will be saved into location
save("location");
exit;
} else {
# lookup will load the branch flag from location
if (!lookup("location")) {
sl_send_reply("404","Not Found");
exit;
}
t_on_branch("1")
t_relay();
}
}
onbranch_route[1] {
xlog("-------branch=$T_branch_idx, branch flags=$bF\n");
if (isbflagset(3)) {
#current branch is marked as natted
.........
}
}
if no parallel forking is done, you can get rid of the branch
route and
add instead of t_on_branch():
........
if (isbflagset(3)) {
#current branch is marked as natted
.........
}
.........
I will upload this description on the wiki page to be more
accessible -
in the mean while, any feedback (reports, better ideas, bugd) are
welcome!
Regards,
Bogdan
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
