[Home]

Summary:ASTERISK-27954: Queue Log "CONNECT" event incorrect "ringtime" value
Reporter:Dmitry Ramenev (expert)Labels:
Date Opened:2018-07-06 00:14:34Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Applications/app_queue
Versions:13.22.0 15.4.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu 16.04 in docker containerAttachments:( 0) photo_2018-07-10_11-56-15.jpg
( 1) photo_2018-07-10_12-02-28.jpg
Description:Queue has *30 s* config timeout and *300 s* app timeout. It's using "ringall" strategy. There are 2 agents assigned to queue, for example chris (penalty=1) and dmitry (penalty=2).

So, when queue having inbound call and when chris have been rejected this call after *17 s*, then the call will be received and answered by dmitry. For example he answering after *7 s*. We'll have in queue log: ENTERQUEUE => RINGNOANSWER(*17000*) => CONNECT(24, XXXX, *24*).

It seems CONNECT event includes chris's ringtime / RINGNOANSWER time.

But what if chris will be not available (paused)? Then dmitry first time rejects the call after *23 s* and after next call receiving - answering call. We'll have in queue log: ENTERQUEUE => RINGNOANSWER(*23000*) => CONNECT(34, XXXX, *4*).

Why this time CONNECT event is not including dmitry's ringtime before reject? Should this event include all previous RINGNOANSWER time or it should include only last ring time?
Comments:By: Asterisk Team (asteriskteam) 2018-07-06 00:14:35.072-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: Kevin Harwell (kharwell) 2018-07-09 13:46:34.106-0500

I confirmed the bug described in the second scenario. Also note, from the Asterisk [Queue Logs|https://wiki.asterisk.org/wiki/display/AST/Queue+Logs] wiki page:
{quote}
CONNECT(holdtime|bridgedchanneluniqueid|ringtime) - The caller was connected to an agent. Hold time represents the amount of time the caller was on hold. The bridged channel unique ID contains the unique ID of the queue member channel that is taking the call. This is useful when trying to link recording filenames to a particular call in the queue. Ringtime represents the time the queue members phone was ringing prior to being answered.
{quote}
Since that value is the ringtime of the queue member's phone I would have expected something like the following in the log instead of what was seen:
{noformat}
CONNECT(24, XXXX, <total time of member's ringing phone>).
{noformat}
By: Dmitry Ramenev (expert) 2018-07-10 00:11:50.198-0500

I agree with total ringtime for CONNECT event. There no matter total time or not total. It should be stable:)

More details.
It seems like RINGNOANSWER event itself also buggy. Please check attachments. All agents rejecting and answering calls in 9-10s. If we switching agents each time after reject, then sometimes RINGNOANSWER ringtime includes previous RINGNOANSWER ringtime.
So, same issue, but with RINGNOANSWER. It shouldn't include previous ringtime.

By: Dalius M. (mdalius) 2019-03-22 10:36:26.622-0500

There was reported similar issue with wrong RINGNOANSWER and wrong ring time to second agent after first get unavailable
ASTERISK-22056