[ASTPPCOM-190] Bad limit counter Created: 28/Mar/17  Updated: 01/Apr/21  Resolved: 01/Apr/21

Status: Done
Project: ASTPP Community
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: Neurotec Tecnologia S.A.S (Inactive) Assignee: Samir Doshi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

hi, we create 5 trunks using the same Gateway,
every trunk has he own limit.
but when astpp launch the call it use limit_execute, example:
limit_execute(db FS-OUT gw_FS-OUT 20 bridge sofia/gateway/FS-OUT/5742792866)
we see this line repeat for every trunk call out, but there is a problem it use the same resource gw_FS-OUT for every call, so this not limit well.

you can check, calling from fs_cli limit_usage db FS-OUT gw_FS-OUT you see we always using the same counter for each trunk limit.

our solution was edit, astpp.xml.lua:

~~~lua
able.insert(xml, [[<action application="limit_execute" data="db ]]..outbound_info['path']..[[ gw_]]..outbound_info['path']..[[ ]]..outbound_info['maxchannels']..[[ bridge sofia/gateway/]]..outbound_info['path']..[[/]]..temp_destination_number..[["/>]]);
~~~

replace with, variable resource outbound_info['path'] with outbound_info['trunk_id']
~~~lua
able.insert(xml, [[<action application="limit_execute" data="db ]]..outbound_info['path']..[[ gw_]]..outbound_info['trunk_id']..[[ ]]..outbound_info['maxchannels']..[[ bridge sofia/gateway/]]..outbound_info['path']..[[/]]..temp_destination_number..[["/>]]);
~~~



 Comments   
Comment by Samir Doshi [ 05/Apr/17 ]

I guess you have gateways created with same name right?
If so then yeah this will happen.

Its good idea to use id in place of gateway name. We will update that.

Best Regards

Samir Doshi
iNextrix Technologies Pvt. Ltd.
http://www.inextrix.com

Disclaimer:
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. If you
are not the intended recipient you are hereby notified that any disclosure,
copying, distribution or taking action in reliance of the contents of this
information is strictly prohibited and may be unlawful. Please notify the
sender immediately and destroy all copies of this message and any
attachments contained in it.

On Tue, Mar 28, 2017 at 10:58 PM, Neurotec Tecnologia S.A.S <
notifications@github.com> wrote:

> hi, we create 5 trunks using the same Gateway,
> every trunk has he own limit.
> but when astpp launch the call it use limit_execute, example:
> *limit_execute(db FS-OUT gw_FS-OUT 20 bridge
> sofia/gateway/FS-OUT/5742792866)*
> we see this line repeat for every trunk call out, but there is a problem
> it use the same resource gw_FS-OUT for every call, so this not limit
> well.
>
> you can check, calling from fs_cli limit_usage db FS-OUT gw_FS-OUT
> you see we always using the same counter for each trunk limit.
>
> our solution was edit, astpp.xml.lua:
>
> able.insert(xml, [[<action application="limit_execute" data="db ]]..outbound_info['path']..[[ gw_]]..outbound_info['path']..[[ ]]..outbound_info['maxchannels']..[[ bridge sofia/gateway/]]..outbound_info['path']..[[/]]..temp_destination_number..[["/>]]);
>
> replace with, variable resource outbound_info['path'] with
> outbound_info['trunk_id']
>
> able.insert(xml, [[<action application="limit_execute" data="db ]]..outbound_info['path']..[[ gw_]]..outbound_info['trunk_id']..[[ ]]..outbound_info['maxchannels']..[[ bridge sofia/gateway/]]..outbound_info['path']..[[/]]..temp_destination_number..[["/>]]);
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/iNextrix/ASTPP/issues/190>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AA6gcd7HQIzkzEwWqPQDqMqassEjfRtQks5rqUM6gaJpZM4Mr8dc>
> .
>

Comment by Samir Doshi [ 21/Apr/17 ]

Fixed. We changed code.

Generated at Sat Feb 10 07:14:57 CET 2024 using Jira 8.13.3#813003-sha1:22ebedbb75c99b147c66f14e031dd8a2d214753a.