@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
- press transfer on the phone
- press the blf button of the extension you want to transfer to
- press the transfer button again.
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.
me thinks you will have to get down and dirty on this one. you are going to have to look at exactly what the phone is sending - i am not sure if you can get everything simply by turning up the verbosity on the console but it is worth a try. if not then turn on the packet capture in the yealink phone and use tcpdump to capture the traffic from the phone and to/from the pbx. i like wireshark to view the captured files.
what you do know is if the transfer is properly completed (## plus extension) it does work. what you also know is that using a button (set as blf or transfer) does not work.
you should be able to see what happens on a successful transfer (no ghost call) and to see what is different when using the blf key.
Thanks, got them. Will be going through them later.
Were you ever able to resolve this? I’m having the exact same issue with Yealink T42 and T46.
Any luck with this? I’m having the exact same issue.
I am still having this problem. I am reinstalling the PBX distro this week and starting from scratch.
Sorry wish I had a better answer for you
Thanks for the reply! Yes definitely a PITA. PLease let me know how you make out. I’m going to be trying a few other things in the meantime (Different Firmware, Changing timeouts, etc.) There’s like zero info about this on Google.
We had to go to a cloud solution due to power outages. Since then we have had no complaints. The version that is running is:FreePBX 18.104.22.168
It is being managed by the hosting company now as well.
Thanks Rudy! This is a tough one to troubleshoot. Any idea if the firmware on the phones changed when you went with the cloud provider? Just asking because it seems like a Yealink issue.
No. Firmware stayed the same. On the T23G we are running Firmware Version 22.214.171.124
Hardware Version 126.96.36.199.0.0.0 For the T29G Firmware Version 188.8.131.52
Hardware Version 184.108.40.206.0.0.0.
The server is VMWare, not sure about the version of ESX nor hardware it is running on. We do have a VPN connection between our network and theirs. Maybe the sonicwall is filtering something, although in the logs (set on debug currently) there is nothing being recorded.
Thanks again for the info. Now I’m wondering if it might be a network related because it doesn’t seem like many people are experiencing the issue. Do you know if you’re using chan_sip or pjsip for your extensions on the cloud? Sorry to be a pest but this is driving me crazy!
This looks to be a Yealink bug.
The OP has posted a workaround. This would make sense why Daniel didn’t have the issue after he moved to the cloud. The VOIP provider is probably blocking or rewriting the 503 packets.
Here is the solution provided by Yealink when I contacted support.