[OpenSIPS-Users] send_reply from branch_route

Pat Burke pat at voxtelesys.com
Thu Jan 26 14:49:14 EST 2017

Thanks Bogdan,

I was able to make it work by making the decision to end the call prior to calling the branch.  Works like a charm.

Pat Burke

-----Original Message-----
From: "Bogdan-Andrei Iancu" <bogdan at opensips.org>
To: "OpenSIPS users mailling list" <users at lists.opensips.org>, "Pat Burke" <pat at voxtelesys.com>
Date: 01/26/17 08:20
Subject: Re: [OpenSIPS-Users] send_reply from branch_route

Hi Pat,

In the branch route you cannot use any signaling function - the branch route is there just for exploring and changing the SIP message (in a per branch manner). What you can do is to drop a branch (to tell OpenSIPS not to send that branch out) by using the "drop()" function.

Still, you can do parallel forking without the need of branch route - again, the branch route is optionally there if you want to individually changes the branches (like for the branch going to a GW to add the RPID hdr, but not for the branch going to a user). If you deal with the branches in the same way, there is no need for a branch route.


Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
On 01/26/2017 05:08 AM, Pat Burke wrote:


I have an opensips server that I use for routing.  I receive a call and will attempt multiple carriers to complete the call.  My understanding is that in 2.2 I had to use branch_route to be able to make multiple attempts.  What I am running into now is that when I get a SIP response that indicates that I don't want to try another carrier, or I have tried as many as I want to try, then I want to send a SIP response (ether the response from the last carrier or a response of my own) and end the call.  When I t_reply I get the following error 
            "CRITICAL:tm:w_t_reply: unsupported route_type (8)".

In a nutshell, the flow is

1)  Call flow leads to RELAY_TO_EGRESS to make the first call.
2)  RELAY_TO_EGRESS sets up the call information by calling OUTBOUND_SETUP (which will attempt to terminate the call if there are errors or no more carriers) and then creates a branch to handle the attempt (BRANCH_TO_EGRESS)
3)  BRANCH_TO_EGRESS does some final setup (setting up headers, etc) and sets the t_on_failure to "egress_failed"
4)  If the call attempt fails, "egress_failed" is called which may want to terminate the call (send_reply...) or attempt again by calling TRY_CARRIER_FAILOVER
5) TRY_CARRIER_FAILOVER will start the process again by calling RELAY_TO_EGRESS (which usually ends in the call to OUTBOUND_SETUP because that is where it determines when no more attempts are going to be made).

In 1.11 without branching this worked fine.

What is the correct way to architect the code.  Here is the general structure I have now.



    if (!t_relay("0x01")) {
        send_reply("500","Internal Error");

                if ($avp(current_carrier_idx) == $avp(out_routes_no)) {
                    route(NO_ROUTES_AVAILABLE, "No more routes available.");
    if (!route(VALIDATE_CARRIER)) {
        route(TRY_CARRIER_FAILOVER, "503", "In supplemental exclusion.");

branch_route[BRANCH_TO_EGRESS] {

    xlog("L_WARN", "$rU SCRIPT:EGRESS:WARN: No carriers to route to.  Ending the call \n");
    $avp(error_reason) := $avp(error_reason) + $param(1);
    t_reply("503","Service not available.");

failure_route[egress_failed] {
    if (t_was_cancelled()) {
        route(ADD_STATUS_ERROR_REASON_TO_HISTORY, $(<reply>rs), $(<reply>rr));
        xlog("L_WARN", "$rU SCRIPT:RADVANCE:WARN: Do not route advance replying with $(<reply>rs) - $(<reply>rr) \n");
        $avp(error_reason) := $avp(error_reason) + "Call Terminated with " + $(<reply>rs) + ".";
        t_reply("487","Request cancelled");

    if ($(<reply>rs) != null) {
        route(TRY_CARRIER_FAILOVER, $(<reply>rs), $(<reply>rr));
    } else {
        $avp(error_reason) := $avp(error_reason) + "Server Error V2 - empty response (rs).";
        route(TRY_CARRIER_FAILOVER, "503", "Server Error");



Pat Burke

_______________________________________________ Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170126/f0836f3c/attachment.html>

More information about the Users mailing list