[OpenSIPS-Users] Getting header from 302

[Ben Newlin]

Yes, if a reply route is armed or the global reply route exists, they are triggered first for any reply. Failure route, if armed, is triggered after that for any >=300 response codes.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of David Villasmil <david.villasmil.work at gmail.com>
Date: Thursday, June 3, 2021 at 8:10 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Getting header from 302
Oh I didn’t register that <reply> param. I’ll try with that.
On the other hand, I may be confused about how opensips processes >299 replies. Does it process them on onreply route and then goes to the failure route? I mean that’s what I’m doing right now, but is this intended by design? I would’ve though it’d go straight to the failure route, but actually going to the onreply route sounds smart.

On Wed, 2 Jun 2021 at 22:08, Jeff Pyle <jeff at ugnd.org<mailto:jeff at ugnd.org>> wrote:
I've been working on a proxy to sit between MS Teams and "normal" SIP stacks.  Teams sends way too many 180s and RTP-less 183s so I sanitize them like this:

onreply_route[relay_reply] {
        if (t_check_status("180")) {
                if (isflagset("GOT_180")) {
                        drop;
                } else {
                        setflag("GOT_180");
                }
        }

        if (isflagset("GOT_180") && t_check_status("183")) {
                drop;
        }
}

With this I stop superfluous 18x messages from being relayed downstream.  The 'drop' here kills the message completely.  You could include the drop if you want to stop the message from being relayed (which you probably do) and are finished processing it in the script (which you are probably not).

If I understand your application correctly, I'd populate the AVP in the reply route and do everything else in the failure route.  Or, try Liviu's suggestion of using $(<reply>hdr(Identity)) in the failure_route directly.  Either way, then continue in the failure_route to do whatever else needs to happen.


- Jeff



On Wed, Jun 2, 2021 at 2:10 PM David Villasmil <david.villasmil.work at gmail.com<mailto:david.villasmil.work at gmail.com>> wrote:
Hello Jeff,

That's exactly what I'm doing:

# Relay to REDIRECT server
route[relay_to_REDIRECT]
{
    t_on_reply("reply_from_REDIRECT");
    t_on_failure("failure_from_REDIRECT");

    xlog("L_ERR", "[$ci][$rm]: Relaying to REDIRECT");
    if (!t_relay()) {
        xlog("L_ERR", "[$ci][$rm]: unable to relay request $ru to $tU -- replying with error");
        sl_reply_error();
    }

    exit;
}

# Response from REDIRECT will come in here.
failure_route[failure_from_REDIRECT]
{
    xlog("L_ERR", "[$ci][$rm]: I'm in failure_route[failover_from_REDIRECT]");
    if (t_was_cancelled()) {
        exit;
    }

    if(is_avp_set("$avp(myheader)")) {
        xlog("L_ERR", "[$ci][$rm]: Got Identity Header: $(hdr(myheader))");
        setflag(100);
        route(invite);
    }
}

# Response 302 from REDIRECT will come in here.
onreply_route[reply_from_REDIRECT]
{
    xlog("L_ERR", "[$ci][$rm]: I'm in onreply_route[reply_from_REDIRECT]");
    if (t_was_cancelled()) {
        exit;
    }

    # detect redirect, store the header and send to "invite" as normally
    if (t_check_status("302") && is_present_hf("myheader")) {
        $avp(identity_header) = $(hdr(myheader));
        setflag(100);
        drop();
    }
}

So I suppose i don't need the drop()?

Regards,

David Villasmil
email: david.villasmil.work at gmail.com<mailto:david.villasmil.work at gmail.com>
phone: +34669448337

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