asterisk users - Nov 2004 - Queue announce behavior for callback agents?

CVS-HEAD-10/30/04

When using the queue announce= in conjunction with a callback agent it
appears the # key must be pressed before the optional announcement is
heard by the agent (as far as I can tell), this seems to make sense for
always logged in agents, but is in the reverse order of what one might
expect for callback agents.

I realize the # is an acknowledgement that not only was the call
answered, but there is a real live body on the answering end. Perhaps
the announcement could loop until timeout or ackcall?

Is there a method available to play the announcement before the ackcall
# key is pressed? What about to loop it until timeout?

Thanks.

From a quick glance, it appears that this is not a trivial change.

the ackcall is handled by the agent channel, and the agent channel doesn't 
tell queue that the channel has been aswered until the # key is 
pressed.  Once queue understands that the channel is answered it plays the 
announcement.

To make what you want work, both applications would need additional coding 
to have app_agent be able to notify app_queue that the end device has 
answered but wants an announcement message before accepting the caller, and 
also supply information to app_queue that the end user accepts or rejects 
the call after hearing the annoucement.

You may want to submit a feature request at http://bugs.digium.com/ asking 
for this feature.

-Chris

 >
 >CVS-HEAD-10/30/04
 >
 >When using the queue announce= in conjunction with a callback agent it
 >appears the # key must be pressed before the optional announcement is
 >heard by the agent (as far as I can tell), this seems to make sense for
 >always logged in agents, but is in the reverse order of what one might
 >expect for callback agents.
 >
 >I realize the # is an acknowledgement that not only was the call
 >answered, but there is a real live body on the answering end. Perhaps
 >the announcement could loop until timeout or ackcall?
 >
 >Is there a method available to play the announcement before the ackcall
 ># key is pressed? What about to loop it until timeout?
 >

>  >CVS-HEAD-10/30/04
>  >
>  >When using the queue announce= in conjunction with a 
> callback agent it  >appears the # key must be pressed before 
> the optional announcement is  >heard by the agent (as far as 
> I can tell), this seems to make sense for  >always logged in 
> agents, but is in the reverse order of what one might  
> >expect for callback agents.
>  >
>  >I realize the # is an acknowledgement that not only was the 
> call  >answered, but there is a real live body on the 
> answering end. Perhaps  >the announcement could loop until 
> timeout or ackcall?
>  >
>  >Is there a method available to play the announcement before 
> the ackcall  ># key is pressed? What about to loop it until timeout?
>  >
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com 
> [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of 
> Chris A. Icide
> Sent: Sunday, November 07, 2004 12:54 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] Queue announce behavior for 
> callback agents?
> 
>  From a quick glance, it appears that this is not a trivial change.
> 
> the ackcall is handled by the agent channel, and the agent 
> channel doesn't tell queue that the channel has been aswered 
> until the # key is pressed.  Once queue understands that the 
> channel is answered it plays the announcement.
> 
> To make what you want work, both applications would need 
> additional coding to have app_agent be able to notify 
> app_queue that the end device has answered but wants an 
> announcement message before accepting the caller, and also 
> supply information to app_queue that the end user accepts or 
> rejects the call after hearing the annoucement.
> 
> You may want to submit a feature request at 
> http://bugs.digium.com/ asking for this feature.
> 
> -Chris
> 
>  >
Chris,

What if ackcall could be given parameters, like the name of a sound file
to play between the answer event and the end of the timeout event? This
would then only be a modification to ackcall, right?

Here is the sequence I envision;

Agent call out event; Answer event; Ackcall sequence, modified to loop a
sound file for the remaining timeout duration, like "I have a call for
the support queue"; # to ack; Notify queue if there is an ack; Queue
plays announcement, like "connecting..."; (optional in the current
code). Seems like this would not require modifying the queue code based
on your earlier analysis.

Now, if I only had the skills to envision the c required to implement
it!

Is this a smaller project? Since we have no in-house coders we would
need to have this written for us (yes, I realize there would be a cost),
with hopes that it would then be useful enough to others to be added to
the project so we do not have to maintain workarounds.

Damon

> You could do something like that, but ackcall wouldn't know 
> what queue called it, so the message would end up needing to 
> be fairly generic. To get a message unique to the queue that polled 
> the agent, you still will need to modify both app_queue and app_agent.
I guess I need to understand the relationship between queue, agent, and
ackcall. Seems like if ackcall can tell the queue the call has been
answered it must be somewhat aware of what queue called it. Is it that
there is a generic token passed?
> Unfortunately, my C skills are so poor, doing this would 
> probably take me a week alone.
Which means it would take ME a year :(

  I think your best option 
> would be to either post a bounty, post a feature request on 
> bugs.digium.com and add a note that you will pay for the 
> work, or as a last resort (you might get somewhat flamed for 
> this) go to the asterisk-dev list (or IRC channel might be 
> better) and ask if someone would be willing to do the coding 
> for you (for a fee of course).  If you just post the request 
> on bugs.digium.com and don't offer a bounty, you might get 
> the code done for free, but I wouldn't count on it being soon.
> 
I will look at similar bounty requests, just not sure how much work this
is, and I do not want to over/under bid.

Thanks for your input Chris.

Damon