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

[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,
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 <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 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 at 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.
>

-- 
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