On 17 December 2014 at 13:01, Paul Belanger <paul.belanger@xxxxxxxxxxxxxx> wrote:
The way I'd see that is, queue.caller.delete would be called, sinceOn Wed, Dec 17, 2014 at 12:54 PM, Jared Smith <jaredsmith@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Dec 17, 2014 at 12:38 PM, Leif Madsen <lmadsen@xxxxxxxxxxxxxxxxxx>
> wrote:
>>
>> Off hand though I can't think of any other "states" that a caller could
>> get into other than waiting, connected, or onhold.
>
>
>
> The one that comes to my mind (and one we use frequently at my job) is a
> post-call survey. After the caller is done talking with an agent, they get
> transferred to a post-call survey so they can rate the service they
> received.
>
they are now moving outside the queue to another application (survey).
However, the argument could be made to keep that in a queue too.
I definitely see that as post-queue functionality. What we're getting into here is call flow properties, not queue.caller status. The caller could fall out of queue and pick up in any application, survey, etc. At this point that would be a separate report (or could be a combined report, but the data should be generated and combined from other information, not from the queue callers status).
Queue caller status is status while in a queue, and nothing else. Either side of the queue (prior to entering such as menu selections, etc, or post-queue handling such as exit-survey, voicemail etc) reporting should be handled separately.
Leif.
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
