Transfered Calls from the operator are being transfered back (ghost call)

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.

Hi Daniel,

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 13.0.188.8

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 44.80.0.95
Hardware Version 44.0.0.16.0.0.0 For the T29G Firmware Version 46.80.0.70
Hardware Version 46.0.0.128.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.

1 Like