It is a bit counterintuitive, though. Like Joel, I would have thought such restrictions ultimately should ultimately be based on the type of the toplevel action.
Then again, I make use of this a lot from failure_route, calling the same route blocks over and over for route-advancing, some of them containing function calls which are not strictly possible in failure_route. The only thing one really has to be careful of in that scenario is transaction state; can’t send stateless replies out of failure_route, so accordingly cannot send them from a descendant route either. That’s an excellent use-case for send_reply(), which does the right thing (in effect, sl_send_reply() vs t_reply()) depending on whether a transaction context exists. — Sent from mobile, with due apologies for brevity and errors. > On Aug 13, 2019, at 3:38 AM, Joel Serrano <j...@textplus.com> wrote: > > Great!!! This is good to know!! > > Thank you Daniel! > Joel. > >> On Tue, Aug 13, 2019 at 12:36 AM Daniel-Constantin Mierla >> <mico...@gmail.com> wrote: >> Hello, >> >> that is a "known hack" to go around the route block type restrictions for >> functions. >> >> The purpose of the restrictions is to limit the usage in the blocks where >> the developer intended to allow the function to be used, like she/he tested >> for those route blocks or thought it is enough there and didn't analyze the >> effects when using in other route block types. >> >> However, many functions are just safe to use in other route block types than >> those imposed by the developer. >> >> Probably the unregister() is safe in onreply block, because it doesn't need >> to generate a reply or use information from request URI. >> >> Cheers, >> Daniel >> >>> On 13.08.19 07:28, Joel Serrano wrote: >>> Forgot to add: >>> >>> root@csbc01:~# kamailio -V >>> version: kamailio 5.3.0-dev7 (x86_64/linux) >>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, >>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, >>> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, >>> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, >>> HAVE_RESOLV_RES >>> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, >>> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> id: unknown >>> compiled with gcc 8.3.0 >>> root@csbc01:~# >>> >>> >>> >>>> On Mon, Aug 12, 2019 at 2:13 PM Joel Serrano <j...@textplus.com> wrote: >>>> Hello, >>>> >>>> I'm playing around with the unregister() function from the registrar >>>> module: >>>> >>>> https://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar.f.unregister >>>> >>>> Docs say that that it can be used in REQUEST_ROUTE or FAILURE_ROUTE. >>>> >>>> I needed it in REPLY_ROUTE, and before reading the docs I tried it and got >>>> this error: >>>> >>>> Aug 12 15:52:44 csbc01 kamailio: CRITICAL: <core> [core/cfg.y:3526]: >>>> yyerror_at(): parse error in config file >>>> /etc/kamailio/csbc/reply_routes.cfg, line 27, column 71: Command cannot be >>>> used in the block#012 >>>> Aug 12 15:52:44 csbc01 kamailio[12737]: ERROR: bad config file (1 errors) >>>> >>>> But, I have this working on another setup, I compared, and my difference >>>> is that I'm running unregister() inside a route, and calling that route >>>> from reply_route, and that works (and by works, I mean it also does what >>>> it is supposed to do, which is unregister the AoR). >>>> >>>> So this doesn't work: >>>> >>>> ... >>>> onreply_route[MANAGE_REG_REPLY] { >>>> if(status=~"2[0-9][0-9]") { >>>> if(($sel(contact.expires)==0) || ($hdr(Expires)==0)){ >>>> if (unregister("location", "$sht(sipserver=>$fU::contact)")) { >>>> xlog("L_NOTICE", "[usrloc] removed user location\n"); >>>> } >>>> route(DEL_SIPSERVER); >>>> } >>>> ... >>>> >>>> But this works: >>>> >>>> ... >>>> onreply_route[MANAGE_REG_REPLY] { >>>> if(status=~"2[0-9][0-9]") { >>>> if(($sel(contact.expires)==0) || ($hdr(Expires)==0)){ >>>> route(UNREG_CUSTOMER); >>>> route(DEL_SIPSERVER); >>>> } >>>> ... >>>> >>>> ... >>>> route[UNREG_CUSTOMER] { >>>> if (unregister("location", "$sht(sipserver=>$fU::contact)")) { >>>> xlog("L_NOTICE", "[usrloc] removed user location\n"); >>>> } >>>> } >>>> ... >>>> >>>> >>>> >>>> So I'm in no-mans-land right now, docs say it's not allowed in >>>> REPLY_ROUTE, and if I try it it will fail, but if I try it inside a route, >>>> it woks (hack?). >>>> >>>> What is the correct approach here? Should unregister() be valid in >>>> reply_route (like other similar functions, for example: save()) and >>>> therefor docs should be updated and the error in the logs should also be >>>> updated, or if it's really not supported, shouldn't Kamailio not let me >>>> use it anywhere that a ends up being called from reply_route? >>>> >>>> I hope I have explained myself correctly. As always, please let me know if >>>> this should be a GH issue instead and I'll happily create it. >>>> >>>> Thanks, >>>> Joel. >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
