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(a)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(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
>
> -- Alex
>
> --
> Principal, Evariste Systems LLC (
www.evaristesys.com)
>
> Sent from my Google Nexus.
>