Thanks to all for answers. The RINGNOANSWER event is now generated even in case of congestion. So I still think, that RINGNOANSWER should be generated in every case when the call was ringing and not answered. There could be another parameter specifying hangup cause (as proposed in issue ASTERISK-15710) and users should determine, if it was agent fault (e.g. congestion is OK, ringtime < 10sec is OK etc.). My patch is going to master (not to versions 13 or 14), so I think we could change queue_log a bit.
On the other hand, this change is breaking compatibility, and it seems that I am alone, who think it is a correct way. So I change it to new event RINGCANCELED, which could be good compromise. Any other ideas are welcome... Martin Tomec P.S.: ABANDON event can’t be used, at least with ringall strategy – there are many RINGCANCELED per call, but ABANDON should be generated only once. From: asterisk-dev-boun...@lists.digium.com [mailto:asterisk-dev-boun...@lists.digium.com] On Behalf Of Kevin Harwell Sent: Thursday, January 19, 2017 8:38 PM To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] app_queue: RINGNOANSWER event On Thu, Jan 19, 2017 at 12:22 PM, Troy Bowman <t...@lump.net<mailto:t...@lump.net>> wrote: To me, RINGNOANSWER means that the agent either rejected or let it ring to timeout while the caller was waiting. If the elapsed seconds equals timeout, they let it ring and never answered. If the elapsed seconds is under the timeout, they rejected the call. <snip> In my opinion, if the caller abandons while we are ringing the agent's phone, it is not the agent's fault that the agent didn't pick up. If a RINGNOANSWER would happen in that case, I'd be assigning fault where there is none. In our call center, RINGNOANSWER is a criminal offense. :) This would be my interpretation as well. That is that RINGNOANSWER implies that in some way the agent is to blame for the call not connecting. I sincerely hope we don't change this behavior. If the impetus for this is to show how long the agent's phone rang, we should put that statistic in data4 of ABANDON or something like that, because we already identify whether an agent's phone was in the process of ringing or being whispered to in ABANDON. Even RINGCANCELED is misleading because the agent did not cancel. It is still and ABANDON. On Thu, Jan 19, 2017 at 2:59 AM, Tomec Martin <to...@ipex.cz<mailto:to...@ipex.cz>> wrote: <snip> So there are 2 ways to move forward: A) Create RINGNOANSWER event after every call end without answer. That breaks backward compatibility for thoose who rely on current behavior. B) Create new event RINGCANCELED – which can be misleading, because call was not canceled. Between these options I lean toward 'B'. Creating a new event would hopefully have a minimal amount of side effects. *Hopefully* most parsers/filters would just ignore the new event. I agree that RINGCANCELED can be misleading as well. Since ABANDON seems to mean the caller hung up then how about calling it RINGABANDON instead? A third option (mentioned on the code review [1] and by Troy) would be to include the agent name/info in the ABANDON event. [1] https://gerrit.asterisk.org/#/c/4649/ Kevin Harwell Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
