Re: [Users] NEW FEATURE: branch and script flags

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* &lt;bogdan(a)voice-system.ro <mailto:bogdan@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(a)openser.org <mailto:Users@openser.org> http://openser.org/cgi-bin/mailman/listinfo/users