[Home]

Summary:ASTERISK-26496: GROUP_COUNT or GROUP_MATCH_COUNT may report an invalid number of channnels when channels are established nearly simultaneously
Reporter:Victor Villarreal (mefhigoseth)Labels:
Date Opened:2016-10-22 08:39:58Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Functions/General
Versions:11.22.0 14.1.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:x86_64 Debian 7 based Asterisk server. Asterisk compiled from sources.Attachments:( 0) Dan-CLI_output.txt
( 1) Dan-DialPlan.txt
( 2) issue_dialplan.txt
( 3) issue_full.txt
Description:When we fired several calls trough a SIP trunk simultaneously, the GROUP_COUNT and the GROUP_MATCH_COUNT could return the same number of calls on that trunk.

You can found more info on the issue_full.txt (full log extract) and the issue_dialplan files.

[Edit by Rusty - You can reproduce easily with the following dialplan]

{noformat}
[from-internal]
exten = 101,1,Dial(Local/s@group-dial&Local/s@group-dial)

[group-dial]

exten = s,1,NoOp(Group count is: ${GROUP_COUNT(1)} )
same = n,Set(GROUP()=1)
same = n,Wait(45)
same = n,Hangup()
{noformat}

Making several calls from one or two phones to 101 will result in the GROUP_COUNT occasionally being reported as the same (for the same group) for a pair of channels.
Comments:By: Asterisk Team (asteriskteam) 2016-10-22 08:39:59.867-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Victor Villarreal (mefhigoseth) 2016-10-22 08:41:39.982-0500

There are the files.
By: Rusty Newton (rnewton) 2016-10-28 09:06:37.704-0500

Can you test this in 13 or 14 since only security fixes are now allowed for 11?

I imagine it will be the same, but it is good to validate.
By: Victor Villarreal (mefhigoseth) 2016-11-01 08:38:53.689-0500

Hi Rusty, sory for the delay.

Unfortunately we can not test with a different version of the 11 due to an issue of compatibility with third-party software we use actually on production.
By: Rusty Newton (rnewton) 2016-11-09 14:59:49.445-0600

Forgot to comment that I reproduced this in 14 and I added the dialplan I used for reproduction to the issue description.
By: Daniel Journo (journo) 2017-01-06 07:20:13.225-0600

I have a hacker exploiting this. I'm working on discovering how the hacker is obtaining the sip login details, but this issue is being exploited in order to make an unlimited number of calls.

Also, the peer's call-limit seems to be being ignored.

v11.10.2 at the moment but migrating shortly to v13.
By: Birger "WIMPy" Harzenetter (wimpy) 2017-01-07 13:52:32.553-0600

The test case is bad.
The result is to be expected when the count is queried *before* the group is set.

By: Daniel Journo (journo) 2017-01-07 14:00:52.504-0600

I've tested the following dialplan:
{noformat}
[from-internal]
exten => 556,1,Dial(Local/s@group-dial&Local/s@group-dial&Local/s@group-dial&Local/s@group-dial&Local/s@group-dial&Local/s@group-dial)

[group-dial]
exten => s,1,Set(GROUP()=1)
same => n,NoOp(Group count is: ${GROUP_COUNT(1)})
same => n,Wait(45)
same => n,Hangup()
{noformat}

It appears to work fine when using Local channels.
By: Daniel Journo (journo) 2017-01-07 15:09:21.787-0600

I can confirm that when INVITEs are fired at Asterisk using sipsak, the issue occurs.
Wait(0.1) in the dialplan does not mitigate this issue.

Attached my dialplan and CLI output.
Note that call-limit seems to be honored. I believe that is because I am running individual sipsak processes from a bash file rather than launching them simultaneously. From what I've seen, call-limit is not honored when the invites are simultaneous.
By: Daniel Journo (journo) 2017-01-08 15:46:42.504-0600

I've just set up a test server and GROUP seems to be working fine.
I'm going to work on why it's not working on my production server.
By: Victor Villarreal (mefhigoseth) 2017-01-08 20:52:36.462-0600

Hi there.

I've just found a workarround for this issue. If you use GROUP_COUNT() or GROUP_MATCH_COUNT() to check your current number of outgoing calls, then put this line of code:

{code}
same => n,Wait($[ ${RAND(1,10)} / 10 ])
{code}

Before call GROUP_*_COUNT() function. This turn a pseudo-simultaneous calls into a non-simultaneous calls, adding a random delay (between 0 and 1 second) before proceed.