Yes, transaction will be ended, onsend_route is executed after all transaction processing was done. There might be some error messages in the logs, but that can be eventually tuned with a small patch.
Cheers, Daniel On 21/10/16 14:30, Alex Balashov wrote: > 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. > -- 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
