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

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