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 <miconda(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users