[Users] NEW FEATURE: branch and script flags
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Jan 9 15:28:42 CET 2007
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* <bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>> 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
> Users at openser.org <mailto:Users at openser.org>
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
More information about the Users
mailing list