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

2016-10-21 Thread 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 
>  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
>>  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@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


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

2016-10-21 Thread 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 
 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
> 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@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.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

2016-10-21 Thread 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 
>  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@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


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

2016-10-21 Thread Alex Balashov 
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 
 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@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.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

2016-10-21 Thread Daniel-Constantin Mierla 
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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

2016-10-21 Thread Alex Balashov 
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

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users