Greetings,
I am having an issue where the operator (201) transfers a call to another extension (202), 202 answers the call however after 201 hangs up they get a call back on their extension with nobody there on the line.
Does anyone know how to fix this?
Thanks in advance
Wow that sounds like a phone issue to me not sure the PBX would ever do that and no other reports of it. Has this always happened? What version of FreePBX and Asterisk are you using? What phones, models and firmware but my gut says its a phone problem.
how are they doing the transfer and what type of phone? i have seen this if the operator does not complete the transfer. the standard mantra is transfer - number - transfer or ##number
This is happening to us as well. We are using Yealink T29G and T23G. FreePBX 13.0.163. We just started using this in production.
The “Ghost” calls seem to happen whether the VM picks up or not. However it only happens with external incoming calls. Calls made from within the system do not have the same behavior.
Also some additional information. The incoming route directs the call to a Queue. The queue has three extensions as ‘agents’. Once the call is picked up and then transferred to another non-queue extension, there is a “Call Returned” message. When the receptionist picks up the call, the line disconnects. Will try to capture some log or Call Event Logging in a bit.
what is the process that is used to transfer a call?
Typically the call will be transfer one of two ways. Pressing the button under “Transfer” then typing the extension, or by pressing the BLF button on the expansion module.
This log entry seems to be related to the latest known “Ghost” call:
200 is the receptionist extension.
607xxxxxxx is the outside caller
231 was the transferee
[2016-08-15 15:39:13] VERBOSE[32182][C-00000056] app_dial.c: PJSIP/231-00000092 is ringing
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] app_dial.c: PJSIP/231-00000092 answered Local/200@from-queue-00000024;2
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:1] ExecIf(“PJSIP/231-00000092”, “0?Set(CDR(recordingfile)=.wav)”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:2] Set(“PJSIP/231-00000092”, “__MACRO_RESULT=”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:3] Set(“PJSIP/231-00000092”, “CFIGNORE=”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:4] Set(“PJSIP/231-00000092”, “MASTER_CHANNEL(CFIGNORE)=”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:5] Set(“PJSIP/231-00000092”, “FORWARD_CONTEXT=from-internal”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:6] Set(“PJSIP/231-00000092”, “MASTER_CHANNEL(FORWARD_CONTEXT)=from-internal”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:7] Macro(“PJSIP/231-00000092”, “blkvm-clr,”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-blkvm-clr:1] Set(“PJSIP/231-00000092”, “SHARED(BLKVM,DAHDI/i1/607xxxxxxx-14)=”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-blkvm-clr:2] Set(“PJSIP/231-00000092”, “GOSUB_RETVAL=”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-blkvm-clr:3] MacroExit(“PJSIP/231-00000092”, “”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:8] ExecIf(“PJSIP/231-00000092”, “0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=231/sip:[email protected]:5060)”) in new stack
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-auto-blkvm:9] ExecIf(“PJSIP/231-00000092”, “0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=)”) in new stack
[2016-08-15 15:39:20] VERBOSE[32249][C-00000056] bridge_channel.c: Channel PJSIP/231-00000092 joined ‘simple_bridge’ basic-bridge
[2016-08-15 15:39:20] VERBOSE[32182][C-00000056] bridge_channel.c: Channel Local/200@from-queue-00000024;2 joined ‘simple_bridge’ basic-bridge
[2016-08-15 15:40:10] VERBOSE[32249][C-00000056] bridge_channel.c: Channel PJSIP/231-00000092 left ‘simple_bridge’ basic-bridge
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] bridge_channel.c: Channel Local/200@from-queue-00000024;2 left ‘simple_bridge’ basic-bridge
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] app_macro.c: Spawn extension (macro-dial-one, s, 48) exited non-zero on ‘Local/200@from-queue-00000024;2’ in macro ‘dial-one’
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] app_macro.c: Spawn extension (macro-exten-vm, s, 16) exited non-zero on ‘Local/200@from-queue-00000024;2’ in macro ‘exten-vm’
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Spawn extension (ext-local, 231, 2) exited non-zero on ‘Local/200@from-queue-00000024;2’
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Executing [h@ext-local:1] Macro(“Local/200@from-queue-00000024;2”, “hangupcall,”) in new stack
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“Local/200@from-queue-00000024;2”, “1?theend”) in new stack
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Goto (macro-hangupcall,s,3)
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“Local/200@from-queue-00000024;2”, “0?Set(CDR(recordingfile)=)”) in new stack
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“Local/200@from-queue-00000024;2”, “”) in new stack
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘Local/200@from-queue-00000024;2’ in macro ‘hangupcall’
[2016-08-15 15:40:10] VERBOSE[32182][C-00000056] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘Local/200@from-queue-00000024;2’
[2016-08-15 15:40:10] VERBOSE[32189][C-00000056] bridge_channel.c: Channel Local/200@from-queue-00000024;1 left ‘simple_bridge’ basic-bridge
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] bridge_channel.c: Channel DAHDI/i1/607xxxxxxx-14 left ‘simple_bridge’ basic-bridge
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Spawn extension (ext-queues, 801, 42) exited non-zero on ‘DAHDI/i1/607xxxxxxx-14’
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Executing [h@ext-queues:1] Macro(“DAHDI/i1/607xxxxxxxx-14”, “hangupcall,”) in new stack
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“DAHDI/i1/607xxxxxxx-14”, “1?theend”) in new stack
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Goto (macro-hangupcall,s,3)
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“DAHDI/i1/607xxxxxxx-14”, “0?Set(CDR(recordingfile)=)”) in new stack
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“DAHDI/i1/607xxxxxxx-14”, “”) in new stack
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘DAHDI/i1/607xxxxxxx-14’ in macro ‘hangupcall’
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] pbx.c: Spawn extension (ext-queues, h, 1) exited non-zero on ‘DAHDI/i1/607xxxxxxx-14’
[2016-08-15 15:40:10] VERBOSE[32171][C-00000056] chan_dahdi.c: Hungup ‘DAHDI/i1/607xxxxxxx-14’
try transferring using ## plus extension and see what happens.
Thanks. We will try that and report back.
This looks a little hinky to me, specifically the part where Local/200@from-queue-000000024 gets handled. it takes them transaction 30 seconds to get handled, but it doesn’t look like the connection is actually successful.
I can’t put my finger on it, but I just get the feeling that there’s something to look at here. I’m not sure that Loca/200@from-queue… is correct - I’d expect that to be Local/200@from-internal (or something similar).
Thanks guys for sticking with me on this.
New behavior information. Tested transferring using suggested ## Works with no ghost.
Tried again with the Transfer button on the main console, worked with no ghost call as well.
While using the BLF, there was a “recall” ghost call.
@cynjut, the incoming route currently goes to an IVR which routes the caller to one of three queues. Each queue has several receptionist extensions. The receptionist transfers the call out of the queue to an extension. That’s most likely why it says @from-queue rather than @from-internal. (my newbie guess).
how have you set up the blf? as a speed dial or a transfer?
Used the Endpoint Manager template for the phone and extension modules. There was a dropdown selection for the button. Chose the BLF option to create a “button appearance”. The dropdown didn’t have those choices for me to change. Just checked the menu, there is an option for transfer and it doesn’t seem to change the field labels. Could try to change the button action from BLF to Transfer(?). But would we loose the ability to have the LED change color?
well that is your issue. i am pretty sure the blf acts as a speeddial when pressed. i don’t have a yealink in front of me to test, but what is happening is that the call transfer is not being completed. try this
Thanks, will have the receptionists try that.
@bksales, tried your test routine. Same results. The calls were returned to the originator (receptionist) as a “recall”.
Also tried using ## then the button. Any use of the BLF button, when transferring, creates the recall AKA ghost call.
as a test change the key from blf to transfer
changed the button on the phone from BLF to Transfer. Tested by calling and using only the button to make transfer. Also used the active transfer button, then pressed the button. Both had the recall behavior at the end of the call.
Also to note, the calls are going to voicemail not being picked up on the other end. The behavior exists whether the caller leaves a voicemail or disconnects before recording begins.