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
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@openser.org <mailto:Users@openser.org> http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
onbranch_route[1] { xlog("-------branch=$T_branch_idx, branch flags=$bF\n"); if (isbflagset(3)) { #current branch is marked as natted
an idea would be to force an RTP proxy only for the branches where is is needed.
Does rtpproxy/mediaproxy support this? E.g. 3 branches, 1 without and 2 with an RTP proxy?
Further, can I set different reply routes for different branches?
regards klaus
} }
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
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Hi Klaus,
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
onbranch_route[1] { xlog("-------branch=$T_branch_idx, branch flags=$bF\n"); if (isbflagset(3)) { #current branch is marked as natted
an idea would be to force an RTP proxy only for the branches where is is needed.
Does rtpproxy/mediaproxy support this? E.g. 3 branches, 1 without and 2 with an RTP proxy?
yes, is just a matter a conf - apply media relay in onbranch route, based on branch flags. There is no special support needed.
Further, can I set different reply routes for different branches?
I guess it is not needed - use only one onreply route for all branches and use branch flags to do different processing if needed.
regards, bogdan
Nice upgrade -- thanks. One small piece of documentation feedback: can I suggest the nomenclature "Request/transaction" instead of "Message/transaction?" When I first read through this (quickly, I admit), I interpreted "Message" flags to be flags within the scope of the current message only.
Cheers, -- kobi
On Jan 9, 2007, at 4:40 AM, Bogdan-Andrei Iancu wrote:
Message/transaction flags
<...>
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!
Hi Kobi,
well...originally, that flags were per-message flags, but when using TM, they are per transaction flags....
so, your first though was correct - if no TM used, the flags are per message.
regards, bogdan
Kobi Eshun wrote:
Nice upgrade -- thanks. One small piece of documentation feedback: can I suggest the nomenclature "Request/transaction" instead of "Message/transaction?" When I first read through this (quickly, I admit), I interpreted "Message" flags to be flags within the scope of the current message only.
Cheers,
kobi
On Jan 9, 2007, at 4:40 AM, Bogdan-Andrei Iancu wrote:
Message/transaction flags
<...>
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!