[OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

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> 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
> phone: +34669448337
>
>
> On Wed, Jun 2, 2021 at 4:32 PM Jeff Pyle <jeff at ugnd.org> wrote:
>
>> If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
>> comes back, I have access to the reply in the onreply_route, then the
>> failure_route.  From a SIP perspective, a 302 is a failure since it's not
>> 2xx-series, no?  I don't do a drop() in the onreply_route.  It just
>> naturally follows its course to the failure_route.
>>
>> David, in your case, since you're trying to drop any 302 that doesn't
>> have an Identity header, I'd check for its presence in the onreply_route
>> and set a flag if there accordingly.  And, capture its value in an AVP if
>> you need.  Next, in the failure_route, if (t_check_status("302") &&
>> !isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
>> easily expand that block to route-advance to your next carrier,
>> send_reply(499, "Something Else"), or whatever you makes sense for your
>> application.
>>
>>
>> - Jeff
>>
>> On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq <Johan at democon.be> wrote:
>>
>>> that's because 302 is not an error.
>>> So I guess that drop() is the only way.
>>>
>>> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
>>> david.villasmil.work at gmail.com>:
>>>
>>>> Thanks Ben,
>>>>
>>>> That’s a good point. But only way I’ve found to jump over from oneply
>>>> to failure_route is by doing a drop(). If there’s another way, I’d love to
>>>> know about it!
>>>>
>>>> David
>>>>
>>>> On Wed, 2 Jun 2021 at 08:29, Ben Newlin <Ben.Newlin at genesys.com> wrote:
>>>>
>>>>> You still don’t need to call drop() as long as you are handling the
>>>>> request in failure_route. The 302 will not be sent back upstream as long as
>>>>> failure_route either creates a new branch request or sends back a different
>>>>> reply code. Only if failure_route exits without doing either of these
>>>>> things would the downstream 302 be sent back upstream as-is.
>>>>>
>>>>>
>>>>>
>>>>> In fact, as far as I know drop() has no functionality for responses >=
>>>>> 200.
>>>>>
>>>>>
>>>>>
>>>>> Ben Newlin
>>>>>
>>>>>
>>>>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210602/23cf7840/attachment-0001.html>