Requiring Agent To Confirm Queue Calls Only When Forwarded To External Device

I'd like to allow my users to forward their calls using the forwarding feature on their SIP handsets and continue to receive Queue() calls. Currently I set the 'i' option in Queue() so that if a user forwards to their cell phone, or any other extension that has voicemail, the voicemail doesn't eat all the calls to the queue.

I'm aware that I can configure the queue to require agents to acknowledge the call. However, most of the calls go to internal devices where confirmation isn't necessary, so I'd like to avoid the extra inconvenience in that most common case.

What I'd like to do is somehow detect that a handset has responded with a SIP 302 response, and only when this is the case, require the agent to confirm humanness before answering the call from the queue. Any ideas on how this could be implemented?
Asterisk Users 3.2 years ago 5 Answers

Answers ( 5 )

  1. Tiago Geada
    August 16, 2012 at 17:29 pm

    forward to a Local extension that has dialplan requiring the acknowledgement?

  2. Phil Frost
    August 16, 2012 at 20:16 pm

    I'd think that would require teaching all the users to forward to a different extension if they thought they could be receiving queue calls. My users probably aren't that good at following directions ;)

    Ultimately, I'm sure I could solve this problem by taking management of forwarding off the phone and into Asterisk, since then I'd absolutely have some flag indicating if forwarding is active or not. However, I was just hoping there was an easier way. I'm really happy with the forwarding interface on our current handsets, and I'd rather not go through the effort of changing their configuration, or changing the user experience if I can avoid it.

  3. Olle E.
    August 17, 2012 at 01:28 am

    17 aug 2012 kl. 03:15 skrev Phillip Frost:

    If a call is forwarded and hit the dialplan again, it's forwarded to the context set in the channel variable FORWARD_CONTEXT.

    So you could set this variable before you hit queue(), then do things differently in the context specified by this variable, since you know that the call is forwarded.


  4. Phil Frost
    August 17, 2012 at 09:12 am

    This sounds like just what I need, but I can't get it to work. Looks to me like FORWARD_CONTEXT is being ignored, and the forward target number is being interpreted in the default context. Am I doing something wrong?

    The queue is entered like this:

    same => n(to-queue),Set(FORWARD_CONTEXT=confirmation-required) same => n,Queue(${queuename},${app_options},,,300)

    [confirmation-required] exten => _X!,1,Verbose(3,Calling ${EXTEN} with confirmation required) same => n,Dial(Local/${EXTEN}@default/n) same => n,Hangup(NO_ANSWER)

    Now when I call the queue, with an agent logged in that has his handset set to redirect, I see this in the console:

    -- Executing [s@support-queues-exit:5010] Set("SIP/pfrost-00000012", "FORWARD_CONTEXT=confirmation-required") in new stack -- Executing [s@support-queues-exit:5011] Queue("SIP/pfrost-00000012", "support,rn,,,300") in new stack -- SIP/pfrost-00000013 connected line has changed. Saving it until answer for SIP/pfrost-00000012 -- Got SIP response 302 "Moved Temporarily" back from -- Now forwarding SIP/pfrost-00000012 to 'Local/912485551234@default' (thanks to SIP/pfrost-00000013)

    SIP tracing shows the response from the phone as:

    SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP;branch=z9hG4bK6ad7c9fd;rportP60 From: "Phil Frost" ;tag=as719c88e2 To: ;tag=y5f8ddjzb0 Call-ID: 22d43bc765acbcdd20da386e28ab8ed3@ CSeq: 102 INVITE Contact: Diversion: ;reason="unconditional" Content-Length: 0

    I'm using Asterisk from the Digium Debian repo. core show version reports:

    Asterisk built by pbuilder @ nighthawk on a x86_64 running Linux on 2012-04-25 17:23:34 UTC

  5. Phil Frost
    August 17, 2012 at 12:26 pm

    After some headbanging, I found an alternate solution. I enter the queue like this:

    same => n(to-queue),Set(__queue_call=yes) same => n,Queue(${queuename},${app_options},,,300)

    The double underscores make queue_call inherited by channels spawned later. Thus, I can add some logic to detect this, and behave differently. I renamed my previous context "handsets" to "handsets-no-confirmation-required", and added this:


    exten => _[#*0-9]!,1,NoOp() ; for queue calls, require the called party to accept the call with a DTMF ; response before connecting. This avoids queue calls from being eaten by ; voicemail and other such automated systems. same => n,GotoIf($["${queue_call}"="yes"]?handsets-confirmation-required,${EXTEN},1) same => n,Goto(handsets-confirmation-not-required,${EXTEN},1)


    exten => _[#*0-9]!,1,Verbose(3,Calling ${EXTEN} with confirmation required) same => n,Dial(Local/${EXTEN}@handsets-confirmation-not-required,,U(confirm-call)) same => n,Hangup(NO_ANSWER)


    exten => s,1,Verbose(3,confirming call) same => n,Background(followme/no-recording) same => n,Background(followme/options) same => n,WaitExten(10) same => n,Goto(2,1)

    exten => 1,1,Verbose(3,call confirmed) same => n,Return()

    exten => 2,1,Verbose(3,call rejected) same => n,Set(GOSUB_RESULT=CONTINUE) same => n,Return()

    exten => _[it],1,Goto(s,1)

    Works great.

 Prev question

Next question