Thanks, that's a good idea! If I use the onsend route, I can still expect the transaction life to come to an end at this point, right? If not, I need some other way of manually sunsetting transactions.
On October 21, 2016 8:23:01 AM EDT, Daniel-Constantin Mierla <mico...@gmail.com> wrote: >One addition that was done rather recent is execution of onsend_route >for replies (it may require a core param to be set) and maybe you can >drop there based on an avp -- it may be a solution if you don't care >about transaction, but only not to send the sip response to the end >point. > >Cheers, >Daniel > > >On 21/10/16 11:45, Alex Balashov wrote: >> Yeah, I'm trying to avoid something complex like keeping state in >htable. >> >> I did try it - the docs are correct. drop() on a >= 2xx reply does >nothing in a named (TM) onreply_route[]. >> >> I really don't care if the transaction is completed internally. I >just want to stop the reply going back to the UAC. >> >> So, just wondering if there's some clever alternative idea. If not, I >guess I will have to use a global onreply_route and feed it information >about whether to use the drop using htable. >> >> >> On October 21, 2016 5:39:04 AM EDT, Daniel-Constantin Mierla ><mico...@gmail.com> wrote: >>> You can try it, not sure if docs are really in sync there. >>> >>> On the other hand, could be that the transaction was matching the >2xx >>> and then practically the state of transaction changed to completed, >so >>> even doing a drop of not sending out, the transaction is still >ended. >>> >>> An alternative solution is using a hash table with expiration of the >>> items matching the max timeout for transactions. >>> >>> Cheers, >>> Daniel >>> >>> >>> On 21/10/16 11:24, Alex Balashov wrote: >>>> The core documentation says that in a named onreply_route[], only >>>> provisional replies can be drop()'d. To drop any reply, it is >>>> necessary to use a global onreply_route. >>>> >>>> Is there any workaround for this, i.e. so I can drop a 2xx reply >from >>>> a specific TM transaction? >>>> >>>> The reason is, to know whether to drop it, I need access to either >>>> AVPs or, ideally, dialog variables. Since the global onreply_route >is >>>> executed by the core, I presume I won't have access to anything >that >>>> persists through TM there. >>>> >>>> Thanks! >>>> >>>> -- Alex >>>> >>> -- >>> Daniel-Constantin Mierla >>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - >>> http://www.asipto.com >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >list >>> sr-users@lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- Alex >> >> -- >> Principal, Evariste Systems LLC (www.evaristesys.com) >> >> Sent from my Google Nexus. >> -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
