Re: [SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Alex Balashov
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 wrote:

Re: [SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Daniel-Constantin Mierla
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,

Re: [SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Alex Balashov
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

Re: [SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Daniel-Constantin Mierla
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

[SR-Users] Dropping non-provisional replies in onreply_route

2016-10-21 Thread Alex Balashov
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