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. > -- 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