[SR-Users] Dropping non-provisional replies in onreply_route
abalashov at evaristesys.com
Fri Oct 21 14:30:57 CEST 2016
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 <miconda at 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
>On 21/10/16 11:45, Alex Balashov wrote:
>> Yeah, I'm trying to avoid something complex like keeping state in
>> 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 at 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
>>> and then practically the state of transaction changed to completed,
>>> even doing a drop of not sending out, the transaction is still
>>> An alternative solution is using a hash table with expiration of the
>>> items matching the max timeout for transactions.
>>> 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
>>>> 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
>>>> executed by the core, I presume I won't have access to anything
>>>> persists through TM there.
>>>> -- Alex
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>> sr-users at lists.sip-router.org
>> -- Alex
>> Principal, Evariste Systems LLC (www.evaristesys.com)
>> Sent from my Google Nexus.
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
More information about the sr-users