Hi
I was wondering what exactly happens with parallel branching in this situation:
branch_route[BR_T] { if (condition) { # Stuff below not required exit or return } do other stuff before relaying
}
Will this break, stop the processing of all branches with higher index as the one being processed? From what I observe, I fear this is the case.
Could I safely use return(1) (vs return which probably is return(0) thus eq exit)? Or would the only safe option be to wrap the 'other stuff' in an else statement?
Mit freundlichen Grüssen
-Benoît Panizzon-
As is often the case, there is a useful opportunity here to step back, switch to decaf, and ask why you want to call 'exit' from a branch_route in the first place.
On 30 Jan 2024, at 06:49, Benoit Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi
I was wondering what exactly happens with parallel branching in this situation:
branch_route[BR_T] { if (condition) { # Stuff below not required exit or return }
do other stuff before relaying
}
Will this break, stop the processing of all branches with higher index as the one being processed? From what I observe, I fear this is the case.
Could I safely use return(1) (vs return which probably is return(0) thus eq exit)? Or would the only safe option be to wrap the 'other stuff' in an else statement?
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Alex
As is often the case, there is a useful opportunity here to step back, switch to decaf, and ask why you want to call 'exit' from a branch_route in the first place.
:-)
Actually I intended to call 'return(1)' to stop processing that actual route and continue in the calling route at the point when all work is done.
I wrapped everything in if/else and I am re-testing.
But on the first glimpse, I still seem to get corrupted stuff at a certain point in branching like $du being null instead of the intended destination of that branch.
Am I right, that $du should contain the sip URI of where the INVITE is being routed to in the branch route? Or am I mistaking here?
In most of my branches, $du is correctly pointing to the next hop (so I can use it to determine how to engage RTPengine), but sometimes it's null and I still didn't figure out why.
I'll probably send another email with more details of what I try to accomplish a bit later when done testing and still facing the issue.
Your help is very appreciated!
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi Benoit,
On 30 Jan 2024, at 08:28, Benoit Panizzon benoit.panizzon@imp.ch wrote:
Hi Alex
As is often the case, there is a useful opportunity here to step back, switch to decaf, and ask why you want to call 'exit' from a branch_route in the first place.
:-)
Actually I intended to call 'return(1)' to stop processing that actual route and continue in the calling route at the point when all work is done.
This will happen naturally, because branch_route, like onreply_route, is essentially a callback/event hook, not a request route subroutine.
In other words:
request_route { ...
t_on_branch("BRANCH"); ...
other_stuff(); # will execute after branch_route
t_relay(); ... }
branch_route[BRANCH] { branch_scoped_stuff(); }
I wrapped everything in if/else and I am re-testing.
But on the first glimpse, I still seem to get corrupted stuff at a certain point in branching like $du being null instead of the intended destination of that branch.
Am I right, that $du should contain the sip URI of where the INVITE is being routed to in the branch route? Or am I mistaking here?
Not necessarily; $du is only used to override the RURI ($ru), where needed. Otherwise, the domain portion of the request URI is consumed by t_relay() to make the next-hop determination.
You can access the next-hop determination using $nh(...):
https://www.kamailio.org/wikidocs/cookbooks/5.7.x/pseudovariables/#nhkey
In most of my branches, $du is correctly pointing to the next hop (so I can use it to determine how to engage RTPengine), but sometimes it's null and I still didn't figure out why.
$du is not mandatorily populated, as mentioned above. Consider $nh(...) instead.
In terms of the original question you posed, why not do this?
request_route { ...
if(jittery) t_on_branch("BRANCH_DECAF"); else t_on_branch("BRANCH_REGULAR");
t_relay(); }
-- Alex
Hi Alex
Only drawback I have with this is, when cycling through registered contacts and adding branches. I can only have one trigger.
request_route { ... if(jittery) t_on_branch("BRANCH_DECAF"); else t_on_branch("BRANCH_REGULAR");
Actual situation. I have two registrars, each one shall only send invites to CPE registerd locally (aka where the socket is not 0)
So I loop through the AOR and:
* append_branch, if contact if socket > 0 * append_branch to other registrar if branch count < registered contacts
But I have to handle some headers and rtpengine differently, for branches to an actual customer CPE or the one which might add a call to the other registrar to correctly send the invite though the sockets present there.
But, in my last tests, comparing $du and $(branch(uri)[]) in every branch, I found there is an off by one with the index!
While in Branch $T_branch_idx = 0. I get the correct URI in $(branch(uri)[-1]) matching to $ds. In $T_branch_idx = 1, $ds corresponds to $(branch(uri)[0]) and so on.
This is utterly weird I would not have expected the index to be negative.
But I'll have a shot at $nh, thanks for pointing that out!
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi Alex
But I'll have a shot at $nh, thanks for pointing that out!
Thank you, using the $nh variables within the branch route solved all my issues with trying to determine where that branch is being sent to to correct handle some special CPE cases and rtpengine.
Now for example I can correctly hint with IP protocol shall be used by rtpengine depending if the CPE is using legacy v4 or modern v6 IP :-)
Still needs some testing to see what realy happens if the first branch is using IPv4 (RTP with IPv4) and the next one is using IPv6 (RTP with IPv6 for SAME callid) and then the first one picks up the call. Is rtpengine stuck with IPv6 or will it listen to both protocols because it processed two offer for the same callid?
-
Alex Balashov -
Benoit Panizzon