[OpenSIPS-Users] Getting header from 302
David Villasmil
david.villasmil.work at gmail.com
Thu Jun 3 12:08:33 EST 2021
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> 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> 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
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Regards,
David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210603/105324e5/attachment-0001.html>
More information about the Users
mailing list