[Users] NEW FEATURE: branch and script flags

Weiter Leiter bp4mls at googlemail.com
Tue Jan 9 14:58:33 CET 2007


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> 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
> http://openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070109/e10562cb/attachment.htm>


More information about the sr-users mailing list