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
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:
>One addition that wa
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
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
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
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 whe
