On Wed, Dec 17, 2014 at 12:05 PM, Leif Madsen <lmadsen@xxxxxxxxxxxxxxxxxx> wrote: > On 17 December 2014 at 13:01, Paul Belanger <paul.belanger@xxxxxxxxxxxxxx> > wrote: >> >> On 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. >> > >> The way I'd see that is, queue.caller.delete would be called, since >> 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. > Disclaimer: I have not looked at the queue application :-) After reading through the comments, two points: (1) I agree with Leif: you'll probably want to find some place where you can draw a boundary between your queue application and the rest of the "system", whatever it happens to be. Anything that occurs after the queue has handed off the caller to something else should be the domain of the rest of the system. Where you draw that boundary is up to you, but StasisEnd is always a good starting point for finding out when something is no longer your concern. (2) Another consideration to think about is how configurable you want your reporting to be. If you go down the path of events - which is what it appears like you're doing - you are deferring the actual queue reports to another piece of software. That's probably a good thing. Granularity then becomes an issue: is taking a post-call survey something that you want your queue to report? Or should it report (a) the caller has left the queue and (b) the caller has hung up - and leave the time delta and its implications up to the software that interprets the events? -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
