[SR-Users] Last negative 5XX reply not getting relayed

Sergiu Pojoga pojogas at gmail.com
Mon May 14 18:29:28 CEST 2018


Hi Alex,

# ----- tm params -----
modparam("tm", "failure_reply_mode", 3)

I use drouting, here's the main logic.

request_route {

 ...

if (is_method("INVITE") && !has_totag()) {
                ...

                # handle DR failure
                t_on_failure("MANAGE_DR_FAILURE");

                if (!do_routing("$avp(drgroup)")) {
                          sl_reply("503", "Unknown destination");
                          exit;
                 }

                # Relay the request to gateway
                route(DR_RELAY);
}

}

# DR relay
route[DR_RELAY] {

        if (!route(RELAY)) {
                sl_reply_error();
        };
        exit;
}

# DRouting failure route
failure_route[MANAGE_DR_FAILURE] {

        if (t_is_canceled()) {
                exit;
        }

        if (t_check_status("486|600")) {
                xlog("L_INFO", "received BUSY, stop trying");  # --
curious, 486 gets relayed fine
                exit;
        }

        # try next GW
        if (use_next_gw()) {
                t_on_failure("MANAGE_DR_FAILURE");

                xlog("L_INFO", "MANAGE_DR_FAILURE: Call from <$fu> with
username <$fU> going to <$ru>\n");
                route(RELAY);
                exit;

        # -- Trunk failover to PSTN number
        } else if (is_avp_set("$avp(s:failover)") && $avp(direction) ==
"in") {
                $ru="sip:" + $avp(s:failover) + "@someothergateway.com"; #
-- basic routing, to improve by sending back to DRouting with updated $rU
                xlog("L_INFO", "MANAGE_DR_FAILURE: No more gateways,
sending call to trunk failover destination <$ru>...\n");
                route(RELAY);

        } else {
                xlog("L_WARN", "No more routes available\n");
                #t_reply ("503", "Service Unavailable");        # -- why do
we have to force a reply instead of proxy relaying whatever it is
                exit;
        }
}



On Mon, May 14, 2018 at 11:34 AM, Alex Balashov <abalashov at evaristesys.com>
wrote:

> Hi,
>
> 1. Do you have a failure_route for this transaction? If so, can you
> provide it?
>
> 2. Make sure the `failure_reply_mode` modparam for TM is set to 3, which
> is default anyway:
>
> https://kamailio.org/docs/modules/5.1.x/modules/tm.html#
> tm.p.failure_reply_mode
>
> -- Alex
>
> On Mon, May 14, 2018 at 11:33:15AM -0400, Sergiu Pojoga wrote:
>
> > Not sure if it's a default Kamailio behavior or something I'm doing
> wrong...
> >
> > When receiving a negative reply for an INVITE (more like in the 5xx
> range),
> > proxy doesn't relay the message to the originator but instead issues it's
> > own "500 Service Unavailable".
> >
> > That doesn't happen, from observations so far, to "603 Declined" or "486
> > Busy Here" or "404 Not Found" or "200 OK" replies.
> >
> > *For example, here's the negative reply proxy receives from the callee:*
> >
> > 2018/05/14 10:52:37.716627 65.XX.XX.166:5060 -> 65.XX.XX.167:5060
> > SIP/2.0 503 Service Unavailable
> > Via: SIP/2.0/UDP
> > 65.xx.xx.167;branch=z9hG4bK9223.00b4f3143d245a895c4bb6a107add2
> 58.0;received=65.xx.xx.167;rport=5060
> > Via: SIP/2.0/UDP
> > 205.xx.xx.221;received=205.xx.xx.221;rport=5060;branch=
> z9hG4bKQ4XpXga0vgZ8B
> > From: "514XXXXXXX" <sip: 514XXXXXXX @205.xx.xx.221>;tag=tXj0NHrje9jNS
> > To: <sip:450XXXXXXX at 65.xx.xx.167>;tag=as18e452b7
> > Call-ID: 48eac296-d229-1236-a685-005056a149a4
> > CSeq: 122818714 INVITE
> > Server: Asterisk
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> > PUBLISH, MESSAGE
> > Supported: replaces, timer
> > Session-Expires: 1800;refresher=uas
> > X-Asterisk-HangupCause: Subscriber absent
> > X-Asterisk-HangupCauseCode: 20
> > Content-Length: 0
> >
> > *Here's what the originator gets in the final message:*
> >
> > 2018/05/14 10:52:37.718143 65.xx.xx.167:5060 -> 205.xx.xx.221:5060
> > SIP/2.0 500 Service Unavailable
> > Via: SIP/2.0/UDP
> > 205.xx.xx.221;rport=5060;branch=z9hG4bKQ4XpXga0vgZ8B;
> received=205.xx.xx.221
> > From: "514XXXXXXX" <sip:514XXXXXXX at 205.xx.xx.221>;tag=tXj0NHrje9jNS
> > To: <sip:450XXXXXXX at 65.xx.xx.167>;tag=31a2c69b5d434ef4a60796e26f568b
> f0-9343
> > Call-ID: 48eac296-d229-1236-a685-005056a149a4
> > CSeq: 122818714 INVITE
> > Server: Kamailio 5.1
> > Content-Length: 0
> >
> > I'd like any reply to be relayed back as is, unless I do some
> > t_check_status() => t_reply() for specific reasons (which I have none at
> > this point).
> >
> > Thanks
> > Sergiu
>
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180514/8de0db96/attachment.html>


More information about the sr-users mailing list