Re: [OpenSIPS-Users] Call Branching in parallel and series

2022-11-01 Thread Liviu Chircu

On 01.11.2022 17:12, Conrad de Wet wrote:


This works, except I want to extend this even further. I want these 4 
branches to keep trying on a loop until the transaction timeout occurs 
or one of the calls is answered. Except I find that the 
“failure_route” has two main problems, firstly if I try a “t_relay()” 
in the failure_route, the original call gets relayed again and I can’t 
seem to refer back to the branch.


This causes the number of branches to quickly run out (I think max is 
16), as it seem to nest the branch. Also because the t_relay() appears 
to act on the main branch, all the urls are reset, so I don’t really 
know where I was originally sending this request to.


failure_route[my_on_failure]{

    seturi($branch(uri));   # <-- This is null

    t_relay(); # causes new branches that don’t seem to 
kill the old ones.


}


Hi, Conrad!

Re: the confusion around failure_route: the failure route callback 
actually means a "failure to relay", not a "failure of a specific 
branch".  So no matter how many branches you attempted to relay in 
parallel (1, 2, 8, etc.), it means they *all* failed (some explicitly 
with, e.g. a 404, others implicitly with a 408 internal timeout).  So 
now you're in this callback and you're only given the original 
Request-URI of the message, with an opportunity to build a new set of 
branches to relay (optionally with a new failure route callback), or 
just give up and pass the error message back upstream.


On topic:  I'm assuming the need to "keep trying these branches in a 
loop" stems from the fact that the "lookup()" operation may produce 
different results throughout the duration of the call attempt.  So 
instead of having a long transaction timeout, you prefer to have a 
shorter one and keep redo'ing the "failure_route + lookup()" loop in 
hope that the WS device comes online, correct?  If so, you may indeed 
often run into the "max branches exceeded" limitation quite easily this 
way, at least with how the code currently works...


Possible cheap workaround: recompile with a larger MAX_BRANCHES (say, go 
from 12 to 31).  At least you may get your PoC working this way and move 
to solving other problems.  Medium-term, maybe we can look into 
developing some support for creating lots of branches in the "master" 
OpenSIPS tree.


Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Call Branching in parallel and series

2022-11-01 Thread Conrad de Wet
Hi All, 
I’m trying to work out how to Fork/Branch calls to various contacts.
 
Firstly, my setup is that I have, let’s say, OpenSIPS-Gateway(os-gw) and 
OpenSIPS-Websocket clients (os-ws). Both of these are a load balanced array of 
servers. So when a client registers on os-ws he could register on any of the 
possible os-ws servers. With os-gw, again there can be N number of servers, but 
this plays little part in my issue, except that all calls are always sent from 
os-ws to os-gw for onward sending, even if the call is to be turned around on 
os-gw back to a registered user on os-ws (internal calling).
 
Let’s take this flow:
[os-ws(x)] <- INVITE > [os-gw(y)] < INVITE > [os-ws(z)]
 
It will be the responsibility of the os-gw to find the correct os-ws (by 
looking in the location table) and sending the call on to the correct os-ws 
server, so that in can reach the actual client endpoint. 
 
I’m busy with my own sort of “lookup()” replacement but with a few more 
encasements. I have managed to get the contacts list form the database, and can 
call something like:
 
seturi("sip:bob@10.0.0.3");
append_branch("sip:bob1@10.0.0.2");
append_branch("sip:bob2@10.0.0.2");
append_branch("sip:bob3@10.0.0.1");
t_relay();
 
This works, except I want to extend this even further. I want these 4 branches 
to keep trying on a loop until the transaction timeout occurs or one of the 
calls is answered. Except I find that the “failure_route” has two main 
problems, firstly if I try a “t_relay()” in the failure_route, the original 
call gets relayed again and I can’t seem to refer back to the branch.
 
This causes the number of branches to quickly run out (I think max is 16), as 
it seem to nest the branch. Also because the t_relay() appears to act on the 
main branch, all the urls are reset, so I don’t really know where I was 
originally sending this request to.
 
failure_route[my_on_failure]{
seturi($branch(uri));   # <-- This is null
t_relay(); # causes new branches that don’t seem to kill the 
old ones.
}
 
So basically, I’m trying to parallel fork the original call (probably no more 
than about 5), and have these branches, retry in a loop (series) until one of 
the contacts answers or the timeout occurs, at this time the cancel will be 
sent to all the “other” branches (probably t_cancel_branch("o") would work for 
that, but I have not been able to test this).
 
The ultimate benefit here: it would be possible that, even if a call has been 
sent to one of the endpoints and is ringing, another endpoint can come online 
and would soon begin to ring. You would have a choice of devices to answer the 
call with.
 
Thanks, Conrad


Sent from my iPhone___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users