[Home]

Summary:ASTERISK-27920: app_queue: Queue member considered inuse after immediately hanging up during dialing.
Reporter:Cao Minh Hiep (hiepcm)Labels:
Date Opened:2018-06-15 04:25:09Date Closed:2018-09-28 07:49:05
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_queue
Versions:13.21.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Asterisk v13.21.0, Telephone.Attachments:( 0) ast_configs.csv
( 1) ast_extensions.csv
( 2) Unconditional_call_forward_failed_full_logs_13.21.txt
( 3) Unconditional_call_forward_failed_queue-logs_13.21.txt
( 4) Unconditional_call_forward-CLI_logs_13.21.txt
Description:Hello,
We found an issue when making an Unconditional Call Forward as the following:

1. Two phones A and phone B in two work groups.
2. Setup an Unconditional Call Forward from phone A to phone B.
3. Make a call from outside to phone A.
4. Phone A will be not ringing, it forwards to phone B.
5. Phone B will be ringing, then pick up phone B.
6. After picking up phone B, immediately hang up phone B.
7. Phone B has been hung up, however still hear ringing sound from the outside phone.
8. Queue log will output the message of "has another call trying, can't receive the call "
9. Hang up the outside phone then try to make another call.
10. Now we can hear ringing sound from outside phone but, phone B now is not ringing.


We investigated the issue and understood that:
1). It will happen 100% with the scenario above.
2). And It will not happen if picking up the phone and answer.
3). When making an unconditional call forward,
    the queue member of the phone A will be added to pending members container,
    and the queue member of the phone B will be not added to.
4). Normally, the added queue member will be removed after hung up the phone at update_queue().
5). When the issue happens, It will not be hung up in this way, therefore
  the added queue member will not be removed.
6). We tried to fix this issue by adding "pending_members_remove(member)" into the following code:
{noformat}
if (ast_check_hangup(peer)) {
       /* Agent must have hung up */
ast_log(LOG_WARNING, "Agent on %s hungup on the customer.\n", ast_channel_name(peer));
+　  pending_members_remove(member);
ast_queue_log(queuename, ast_channel_uniqueid(qe->chan), member->membername, "AGENTDUMP", "%s", "");
blob = ast_json_pack("{s: s, s: s, s: s}", "Queue", queuename,
                  "Interface", member->interface,
  "MemberName", member->membername);
queue_publish_multi_channel_blob(qe->chan, peer,
                                                                queue_agent_dump_type(), blob);
ast_channel_publish_dial(qe->chan, peer, member->interface,
       ast_hangup_cause_to_dial_status(ast_channel_hangupcause(peer)));
ast_autoservice_chan_hangup_peer(qe->chan, peer);
ao2_ref(member, -1);
goto out;
} else if (ast_check_hangup(qe->chan)) {
{noformat}
Then, issue does not happen.

Please take a look at them and tell us the correct way to solve this issue.

Thank you.
Comments:By: Asterisk Team (asteriskteam) 2018-06-15 04:25:10.556-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: Joshua C. Colp (jcolp) 2018-06-19 04:26:03.389-0500

Your Asterisk CLI log (and other logs) show a version of "13.12.0" while in this report you specified 13.21.0 - which version is in use? If it is not the latest then you need to upgrade, as fixes and changes went into app_queue for this level of stuff.
By: Cao Minh Hiep (hiepcm) 2018-06-19 23:03:19.875-0500

Hello,
I am sorry for my mistake of testing on an old version.
(our server was set to restore automatically after every two days)

I attach new logs which confirmed on version 13.21.0
The issue also happens on this version.
Please have a look at them again.

Thank you.
By: Joshua C. Colp (jcolp) 2018-06-21 04:54:46.239-0500

Please also attach the configuration or details about the configuration for this as well so the scenario can be precisely reproduced. Even the smallest configuration detail can end up altering things.
By: Cao Minh Hiep (hiepcm) 2018-06-21 20:14:24.086-0500

Hello,
We are using realtime DB to do. Please see the attaching configuration files this.

About the scenario can be precisely reproduced, It is same as we described at the first report.
(I copy it)
1. Two phones A and phone B in two work groups.
2. Setup an Unconditional Call Forward from phone A to phone B.
3. Make a call from outside to phone A.
4. Phone A will be not ringing, it forwards to phone B.
5. Phone B will be ringing, then pick up phone B.
6. After picking up phone B, immediately hang up phone B.
7. Phone B has been hung up, however still hear ringing sound from the outside phone.
8. Queue log will output the message of "has another call trying, can't receive the call "
9. Hang up the outside phone then try to make another call.
10. Now we can hear ringing sound from outside phone but, phone B now is not ringing.


Thank you.
By: Cao Minh Hiep (hiepcm) 2018-07-31 20:41:22.603-0500

Hello Joshua Colp.
I am sorry to bother you, but how is the issue going?.
How about the patch I wrote at the head of the issue?

Here are two patches that I think It related to this issue.
ASTERISK-26862
ASTERISK-26621
I have already tested the influencing of the removing pending member if it is removed the same member two or more times. It worked well.
I saw that the current source code also has the same situation in some cases.

Please take a look at the issue and let me know if you need more information.
Thank you.

By: Joshua C. Colp (jcolp) 2018-08-01 04:22:20.962-0500

The issue has been accepted and noone is actively working on it. If you'd like to contribute your change the method to do so is in the initial comment posted on this issue, otherwise you'll have to wait for someone to dig in.
By: Cao Minh Hiep (hiepcm) 2018-08-22 02:37:15.038-0500

Hello,
Here are results that we have investigated.

This issue related to setting of holdtime, announcements, member delays.
It works well if we set the member delays to "0" and no announcements and no holdtime.
This issue will happen if we set member delays to  "1", "2"... or announcements or holdtime and hangs up the call during processing it.

And here is the reason:
(At the step of answering a phone.)
It takes care any holdtime, announcements, member delays, or other options after a call has been answered if it exists. (We can see the following the part of the source code to know it.)
Normally, After the call has been aswered, and we wait for the processing one of the cases of the member delays or hold time or announcements finished, "if (ast_check_hangup(peer))" will be not executed, then queue will be updated at update_queue(). Here, pending member will be removed.

However, after the call has been aswered, if we hangs up the call during one of the cases of the member delays or hold time or announcements,  "if (ast_check_hangup(peer))" will be executed.
In this case, outgoing = NULL and at hangupcalls, pending members will not be removed.

In try_calling () process:
{noformat}
if (announce || qe->parent->reportholdtime || qe->parent->memberdelay) {
        int res2;
        res2 = ast_autoservice_start(qe->chan);
        if (!res2) {
                 if (qe->parent->memberdelay) {
                               ...
                 }
                  if (!res2 && announce) {
                               ...
                  }
                  if (!res2 && qe->parent->reportholdtime) {
                               ...
                  }

        if (ast_check_hangup(peer)) {
                   /* Agent must have hung up */
                  ...
        }
        ...
}
{noformat}

That's why we suggest removing the pending members in case of "if (ast_check_hangup(peer)) " executes.

Please consider it and have a look at these points.
Thank you.

By: Friendly Automation (friendly-automation) 2018-09-28 07:49:08.462-0500

Change 10290 merged by George Joseph:
app_queue: Fix Attended transfer hangup with removing pending member.

[https://gerrit.asterisk.org/10290|https://gerrit.asterisk.org/10290]
By: Friendly Automation (friendly-automation) 2018-09-28 07:49:28.364-0500

Change 10048 merged by George Joseph:
app_queue: Fix Attended transfer hangup with removing pending member.

[https://gerrit.asterisk.org/10048|https://gerrit.asterisk.org/10048]
By: Friendly Automation (friendly-automation) 2018-09-28 07:49:44.863-0500

Change 10291 merged by George Joseph:
app_queue: Fix Attended transfer hangup with removing pending member.

[https://gerrit.asterisk.org/10291|https://gerrit.asterisk.org/10291]
By: Friendly Automation (friendly-automation) 2018-09-28 07:50:01.362-0500

Change 10292 merged by George Joseph:
app_queue: Fix Attended transfer hangup with removing pending member.

[https://gerrit.asterisk.org/10292|https://gerrit.asterisk.org/10292]