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 <[email protected]> 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 < > [email protected]> 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: [email protected] >> phone: +34669448337 >> >> >> On Wed, Jun 2, 2021 at 4:32 PM Jeff Pyle <[email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]>: >>>> >>>>> 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 <[email protected]> >>>>> 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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: [email protected] phone: +34669448337
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
