asterisk users - Jan 2013 - Capture queue agent drop and put caller back in queue

Asterisk 11

Occasionally we will have a partial power outage, or a piece of network 
equipment will fail, and our queue agents who are on active calls with 
callers will be disconnected from the caller.  What I'd like to do is 
capture those calls and put them back in the queue (at a high priority) 
so that we don't lose the caller.

I've tried to duplicate the situation in my lab: I have one agent in the 
queue, a caller dials into the queue, gets connected to the agent then I 
pull the ethernet cable out of the agent's computer (testing with a 
softphone) but I don't see anything happen on the asterisk console.  
core show channels shows the 2 channels still bridged even though the 
agent is gone.

Shouldn't asterisk somehow know when the agent disappears?
How can I accomplish my goal?

-- 

Mitch

On Mon, Jan 21, 2013 at 11:03 AM, Mitch Claborn <mitch_ml at
claborn.net>wrote:
> How can I accomplish my goal?
>
http://lmgtfy.com/?q=battery+backup


-- 
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130121/31a96cd2/attachment.htm>

On Mon, Jan 21, 2013 at 12:03 PM, Mitch Claborn <mitch_ml at
claborn.net>wrote:
> Shouldn't asterisk somehow know when the agent disappears?
>
Asterisk will only notice that the agent is gone when a timeout has
occurred. When you're pulling out the Ethernet cable, there's no
opportunity for any equipment to signal to Asterisk that something has
changed.


-- 
-Chris Harrington
ACSDi Office: 763.559.5800
Mobile Phone: 612.326.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130121/69582361/attachment.htm>

Mitch Claborn <mitch_ml at claborn.net> writes:
> Shouldn't asterisk somehow know when the agent disappears?
You are a bit out of luck since SIP session timers, the obvious
solution, cannot be set lower than 90 seconds.

rtptimeout set to e.g. 10 seconds may work, but you need to then set
rtpholdtimeout higher and hope that voice activity detection or mute
does not kill the calls...

Does Asterisk consider RTCP packets for the purpose of rtptimeout? That
could solve the problems of silence suppression and mute.


/Benny

On Mon, Jan 21, 2013 at 12:03 PM, Mitch Claborn <mitch_ml at
claborn.net>wrote:
> How can I accomplish my goal?

Since nobody seems to have come up with an Asterisk-specific solution, it
sounds like the real approach here is something more generic.

You can set up Nagios to fire off an event if it detects endpoints or
infrastructure are suddenly dead. In particular, Nagios could launch a
program written for this purpose, passing the endpoints it detects are
missing, and that program could then query Asterisk via AMI about the call
IDs each endpoint is a participant in, then do a forced-transfer to a
dedicated queue that announces the failure condition to the caller. This
AMI could also conveniently remove the dead endpoints from the existing
queues (including the failover queue).

The wildcard here is obviously the program itself, which would be slightly
complex. It would have to have intimate knowledge about your
infrastructure. It's unlikely something like this currently exists that you
can just drop-in, but I'm sure there's someone on this list that would
be
willing to sell you the labor to write it.

-- 
-Chris Harrington
ACSDi Office: 763.559.5800
Mobile Phone: 612.326.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130122/c334227f/attachment.htm>

Not doubting how quickly Nagios can respond, but if the Nagios solution is going
to place a call using Asterisk, wouldn?t it be just as efficient (or more so) to
depend on Asterisk?

 

From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces
at lists.digium.com] On Behalf Of Christopher Harrington
Sent: Tuesday, January 22, 2013 3:30 PM
To: Benny Amorsen
Cc: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Capture queue agent drop and put caller back in
queue

 

On Tue, Jan 22, 2013 at 3:01 PM, Benny Amorsen <benny+usenet at
amorsen.dk> wrote:

 

Can a Nagios-based solution provide quicker failover than the 90 seconds
provided by sip timers or the 10-30 seconds provided by rtptimeout?

 

Certainly; Nagios can detect missed ping responses with a granularity of single
seconds.




 

-- 
-Chris Harrington

ACSDi Office: 763.559.5800

Mobile Phone: 612.326.4248

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130122/8f0572f0/attachment.htm>

How do you propose that Asterisk determines that the endpoint has vanished
off the network without waiting for a 10-90 second timeout period?


On Tue, Jan 22, 2013 at 4:07 PM, Danny Nicholas <danny at debsinc.com>
wrote:
> Not doubting how quickly Nagios can respond, but if the Nagios solution is
> going to place a call using Asterisk, wouldn?t it be just as efficient (or
> more so) to depend on Asterisk? ****
>
> **
>
-- 
-Chris Harrington
ACSDi Office: 763.559.5800
Mobile Phone: 612.326.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130122/afe6965c/attachment.htm>

Using qualify=10 ?

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces
at lists.digium.com] On Behalf Of Christopher Harrington
Sent: Tuesday, January 22, 2013 5:11 PM
To: Danny Nicholas
Cc: Asterisk Users Mailing List - Non-Commercial Discussion; Benny Amorsen
Subject: Re: [asterisk-users] Capture queue agent drop and put caller back in
queue

How do you propose that Asterisk determines that the endpoint has vanished off
the network without waiting for a 10-90 second timeout period?



On Tue, Jan 22, 2013 at 4:07 PM, Danny Nicholas <danny at debsinc.com>
wrote:


	Not doubting how quickly Nagios can respond, but if the Nagios solution is
going to place a call using Asterisk, wouldn?t it be just as efficient (or more
so) to depend on Asterisk?

	 

-- 
-Chris Harrington

ACSDi Office: 763.559.5800
Mobile Phone: 612.326.4248

2013/1/21 Mitch Claborn <mitch_ml at claborn.net>
> Asterisk 11
>
> Occasionally we will have a partial power outage, or a piece of network
> equipment will fail, and our queue agents who are on active calls with
> callers will be disconnected from the caller.  What I'd like to do is
> capture those calls and put them back in the queue (at a high priority) so
> that we don't lose the caller.
>
> I've tried to duplicate the situation in my lab: I have one agent in
the
> queue, a caller dials into the queue, gets connected to the agent then I
> pull the ethernet cable out of the agent's computer (testing with a
> softphone) but I don't see anything happen on the asterisk console. 
core
> show channels shows the 2 channels still bridged even though the agent is
> gone.
>
> Shouldn't asterisk somehow know when the agent disappears?
> How can I accomplish my goal?
>
>


I am not sure that from the PoV of the caller this solution would work -
they would experience tens of seconds of silence plus they would have to go
back to the queue. If this happens rarely, you could have a process call
them back instead - you acknowledge what happened and have someone on-line
with the person apologizing.

We have a few clients implementing something like this for calls exiting
the queue on timeouts and it seems to be well-liked by the callers. Of
course it depends on what you are doing and the level of service that
callers come to expect.

Just my two cents,
l.




-- 
Loway - home of QueueMetrics - http://queuemetrics.com
Test-drive WombatDialer beta @ http://wombatdialer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130124/ed9e6645/attachment-0001.htm>