[asterisk-bugs] [JIRA] (ASTERISK-27216) app_queue: does its check-makeannouncement-logic twice each head-caller-loop

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-27216:
-------------------------------------

    Target Release Version/s: 16.0.0

> app_queue: does its check-makeannouncement-logic twice each head-caller-loop
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-27216
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27216
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 13.15.0
>            Reporter: Stefan Engström
>            Severity: Minor
>      Target Release: 13.18.0, 14.7.0, 15.1.0, 16.0.0
>
>
> I think the addition of the second check via the commit in 
> https://reviewboard.asterisk.org/r/2263/
> is unnecessary,
> By putting a check there, it allows for the possibility for the agent's phones to be ringing while announcement information is being played out to the head caller. Announcements should only be played between ringing cycles?
> All right, let me provide a little more context
> 1. Create a queue with a ringtime of 20 seconds and periodic announcement audio message (of playlength ~5 sconds) to be played every 20 seconds
> 2. Create a single SIP device B to be the only queue member
> 3. Have person A call the queue
> 4. B should attempt to answer the call while the periodic announcement message is being played out to the header caller (the only caller) (A). This should happen around 21 seconds after A enters queue
> The behavior I expect: B's sip device should stop ringing after ~20 seconds after A enters queue , and the whole periodic announcement should be played out to A before the second ringing cycle to B starts.
> Actual behavior: 
> 1) B sip device does ring as A is hearing announcement info, and 
> 2) when B attempts to answer the queue call is not actually answered.
> I'm not too concerned with 2) because 2) is a consequence of 1) and I think 1) is already unexpected behavior... It's even possible my particular configuration causes 2), but 1) is the issue I'm reporting. Should it really be possible for the head caller to hear "We will soon take your call, thank you for calling B...." then instantly get connected and hear "Hello you are talking to Doris"? 
> I'm not sure I follow your comment, what does *they* refer to in 'they are checks for two different types of announcements. '
> There are two checks for two different types yes, but each of them are checked twice:
> looking at app_queue.c
> you have at line 8073 in queue_exec
> {noformat}
>                 if (makeannouncement) {
>                         /* Make a position announcement, if enabled */
>                         if (qe.parent->announcefrequency)
>                                 if ((res = say_position(&qe,ringing)))
>                                         goto stop;
>                 }
>                 makeannouncement = 1;
>                 /* Make a periodic announcement, if enabled */
>                 if (qe.parent->periodicannouncefrequency) {
>                         if ((res = say_periodic_announcement(&qe,ringing))) {
>                                 goto stop;
>                         }
>                 }
> {noformat}
> then at line 5247 a very similar code block starts
> {noformat}
>         /* Make a position announcement, if enabled */
>         if (qe->parent->announcefrequency && qe->parent->announce_to_first_user) {
>                 say_position(qe, ringing);
>         }
>         /* Make a periodic announcement, if enabled */
>         if (qe->parent->periodicannouncefrequency && qe->parent->announce_to_first_user) {
>                 say_periodic_announcement(qe, ringing);
>         }
> {noformat}
> The queue_exec loop goes through both of these blocks each loop.



--
This message was sent by Atlassian JIRA
(v6.2#6252)