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

[Alex Balashov]

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.