[OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

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
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210602/b1843a3f/attachment.html>