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?

5 Responses to “Requiring Agent To Confirm Queue Calls Only When Forwarded To External Device”

  1. Tiago Geada said:

    Aug 16, 12 at 5:29 pm

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

  2. Phil Frost said:

    Aug 16, 12 at 8: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. said:

    Aug 17, 12 at 1: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.

    /O

  4. Phil Frost said:

    Aug 17, 12 at 9: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 172.20.25.126:3072
    – 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 172.20.20.6:5060;branch=z9hG4bK6ad7c9fd;rportP60
    From: “Phil Frost” ;tag=as719c88e2
    To: ;tag=y5f8ddjzb0
    Call-ID: 22d43bc765acbcdd20da386e28ab8ed3@172.20.20.6:5060
    CSeq: 102 INVITE
    Contact:
    Diversion:
    ;reason=”unconditional”
    Content-Length: 0

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

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

  5. Phil Frost said:

    Aug 17, 12 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:

    [handsets]

    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)

    [handsets-confirmation-required]

    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)

    [confirm-call]

    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.