Forward to Mailbox not working in queue call

avayaxavayax
in Support
My FOP2 operator extension is member of a queue. When the operator picks up a call going to that queue (all from the panel), and wants to forward the call to the mailbox of another extension via the transfer to mobile icon, the call fails with below output from the CLI. The call just hangs up.
A manual transfer on the phone itself via the direct dial prefix (#2) is possible though.

However, when the operator has initiated the call or picked up a call not coming from the queue, this problem doesn't happen.
Any ideas?

-- Connected line update to IAX2/5318-6722 prevented.
-- SIP/5313-00000033 answered IAX2/5318-6722
-- <SIP/5313-00000033> Playing 'beep.gsm' (language 'en')
> 0x7f2910045230 -- Probation passed - setting RTP source address to 87.11.113.13:1836
== Spawn extension (from-internal, #22517, 1) exited non-zero on 'IAX2/5318-6722'
-- Executing [#22517@from-internal:1] Macro("IAX2/5318-6722", "vm,2517,DIRECTDIAL,") in new stack
-- Executing [s@macro-vm:1] Macro("IAX2/5318-6722", "user-callerid,SKIPTTL") in new stack
-- Executing [s@macro-user-callerid:1] Set("IAX2/5318-6722", "TOUCH_MONITOR=1427657975.157") in new stack
-- Executing [s@macro-user-callerid:2] Set("IAX2/5318-6722", "AMPUSER=5318") in new stack
-- Executing [s@macro-user-callerid:3] GotoIf("IAX2/5318-6722", "13?report") in new stack
-- Goto (macro-user-callerid,s,16)
-- Executing [s@macro-user-callerid:16] GotoIf("IAX2/5318-6722", "1?continue") in new stack
-- Goto (macro-user-callerid,s,30)
-- Executing [s@macro-user-callerid:30] Set("IAX2/5318-6722", "CALLERID(number)=5318") in new stack
-- Executing [s@macro-user-callerid:31] Set("IAX2/5318-6722", "CALLERID(name)=Johann Mobile") in new stack
-- Executing [s@macro-user-callerid:32] Set("IAX2/5318-6722", "CDR(cnum)=5318") in new stack
-- Executing [s@macro-user-callerid:33] Set("IAX2/5318-6722", "CDR(cnam)=Johann Mobile") in new stack
-- Executing [s@macro-user-callerid:34] Set("IAX2/5318-6722", "CHANNEL(language)=5313") in new stack
-- Executing [s@macro-vm:2] Set("IAX2/5318-6722", "VMGAIN=g(12)") in new stack
-- Executing [s@macro-vm:3] Macro("IAX2/5318-6722", "blkvm-check,") in new stack
-- Executing [s@macro-blkvm-check:1] Set("IAX2/5318-6722", "GOSUB_RETVAL=TRUE") in new stack
-- Executing [s@macro-blkvm-check:2] ExecIf("IAX2/5318-6722", "0?Set(GOSUB_RETVAL=TRUE)") in new stack
-- Executing [s@macro-blkvm-check:3] MacroExit("IAX2/5318-6722", "") in new stack
-- Executing [s@macro-vm:4] GotoIf("IAX2/5318-6722", "0?vmx,1") in new stack
-- Executing [s@macro-vm:5] Hangup("IAX2/5318-6722", "") in new stack
== Spawn extension (macro-vm, s, 5) exited non-zero on 'IAX2/5318-6722' in macro 'vm'
== Spawn extension (from-internal, #22517, 1) exited non-zero on 'IAX2/5318-6722'
-- Executing [h@from-internal:1] Hangup("IAX2/5318-6722", "") in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on 'IAX2/5318-6722'
-- Hungup 'IAX2/5318-6722'

Comments

  • avayaxavayax
    Just making an important correction to my initial post which doesn't make sense the way it is.
    When I have received a call on my fop2 extension coming from a queue, I can't forward the call to the mailbox of another extension via the transfer to mailbox action button (above I wrote transfer to mobile button, which is nonsense).
    The problem doesn't happen when the call was either inititated by the operator or received not coming from the queue.
    I hope that is clear.
  • nicolasnicolas
    Description is clear, but log files do not help at all. FOP2 is FOP2, and your dialplan is your dialplan. I might be able to help with the FOP2 side of things, but not your dialplan. Whenever you transfer or redirect a call, FOP2 will send a command to Asterisk via the AMI interface. That is the only thing we can check/verify, whatever happens *next*, inside your dialplan, with your phones, or whatever, are not handled and not a responsibility of FOP2 itself. So, to capture the AMI debug and FOP2 commands, you have to start fop2_server with debug enabled, and *then* inspect that log when you attempt to transfer a queue call.

    You can start fop2 in debug mode to capture that like this:

    service fop2 stop
    cd /usr/local/fop2
    script capture.log
    ./fop2_server -X 511
    (log into fop2, answer a queue call, attempt that transfer that fails)
    ctrl-C
    exit
    service fop2 start

    At that point you will have a capture.log file to analyse. Open it up and look for "atxfer" or "tovoicemail" strings, all that you see afterwards are the actual commands being issued by FOP2 to Asterisk and the Asterisk response. IF the command FOP2 issues is correct, but asterisk misbehaves, then there is nothing I can do, as it won't be a FOP2 issue in itself. If the command that FOP2 sends is incorrect, then I might be able to give you a workaround or provide a fix.

    Best regards,

  • avayaxavayax
    edited March 2015
    Here is a capture.
    When I pick up a call, I hover over the calling extension in the queue section and click the pickup call popup.
    As the originate channel for the extension, I am using Local/*805313@from-internal, with *80 being the intercom prefix to auto answer a call that Asterisk originates to me.
    That works usually, but in this scenario, I think that is what is breaking a forward to mailbox or supervised transfer.

    5318 calls queue 5320. 5313 rings and wants to forward call to mailbox of 2517. #2 voicemail direct dial prefix
  • nicolasnicolas
    This is the action that FOP2 is performing, according to what you say, it seems to be correct:

    [fixed]
    127.0.0.1 -> Action: Redirect
    127.0.0.1 -> Channel: IAX2/5318-282
    127.0.0.1 -> Exten: #22517
    127.0.0.1 -> Context: from-internal
    127.0.0.1 -> Priority: 1
    127.0.0.1 -> Async: True
    [/fixed]

    Channel IAX2/5318-282 will be redirected to your dialplan extension #22517 and context from-internal

    You can verify the existence of that extension@context with the command

    asterisk -rx "dialplan show #22517@from-internal"

    If the dialplan shows the comedian mail app being called, then everything in FOP2 is correct and whatever happens is up to your own asterisk setup/configurations.


    if the extension@context is not correct, then you might need to review the voicemail dial prefix, etc..
  • avayaxavayax
    This is the output of asterisk -rx "dialplan show #22517@from-internal":

    asterisk -rx "dialplan show #22517@from-internal"
    [ Included context 'ext-local' created by 'pbx_config' ]
    '#22517' => 1. Macro(vm,2517,DIRECTDIAL,${IVR_RETVM}) [pbx_config]
    2. Goto(vmret,1) [pbx_config]

    -= 1 extension (2 priorities) in 1 context. =-
  • nicolasnicolas
    Seems fine, at least it calls the macro vm. FOP2 is doing the right thing, there is nothing you can change in your config or in FOP2 to make it any different, if that call does not arrive to voicemail is an asterisk/dialplan issue of some sort.

    There are events in your capture showing that the channel was indeed sent to that part of your dialplan:

    [fixed]
    127.0.0.1 <- Event: Newexten
    127.0.0.1 <- Privilege: dialplan,all
    127.0.0.1 <- Channel: IAX2/5318-282
    127.0.0.1 <- Context: macro-vm
    127.0.0.1 <- Extension: s
    127.0.0.1 <- Priority: 1
    127.0.0.1 <- Application: Macro
    127.0.0.1 <- AppData: user-callerid,SKIPTTL
    127.0.0.1 <- Uniqueid: 1427765939.24
    [/fixed]

    So if the call is dropped or whatever, it is an asterisk thing.


Sign In or Register to comment.

© Asternic Corp 2024