Attended Transfer Not Transferring - Call Remains On Hold

[Daniel_AU]

We have a local Windows Hosted 3CX v16. Various Yealink Handsets. We are finding on some occasions that users are unable to attended transfer a call. Phone rings, user 1 answers, user 1 presses transfer and dials new extension, user 2 answers and call is announced, user 1 presses transfer again and call remains on hold with initial user. This happens using the BLF keys or dialing the extension. Handsets are Yealink T46S, originally with custom templates, but reverted back to default and problem still occurs. We have seen this issue on more then one handset. It does not happen on every call, but often enough to be a problem.

 

[JohnS_3CX]

Hi Daniel,

• Under each extension's provisioning tab, what method has been selected for transfer? (Attended/Blind)
• Were the phones reset and reprovisioned after reverting to default templates?
• What provisioning method is used currently?
• Is this only happening when external calls are involved?
• Is the firmware updated to the latest 3CX provides for all your devices?

 

[Daniel_AU]

Hi John,

To answer your questions...

- All our handsets are provisioned with 'Attended/Consultative Transfer.

- Handsets were factory reset after changing templates.

- We use DHCP Option 66 for provisioning handsets.

- Definitely happens when external calls are involved.

- Yes 3CX is fully up to date and using latest handset firmware (from 3CX).

 

[JohnS_3CX]

-> Definitely happens when external calls are involved

Can you see if your trunk that is involved here has the options Supports Re-invite and Supports Replaces as enabled?

 

[Daniel_AU]

-> Definitely happens when external calls are involved

Can you see if your trunk that is involved here has the options Supports Re-invite and Supports Replaces as enabled?

No to both of those.

Only 'Force Invites to be sent to IP of Registrar' & 'PBX Delivers Audio' are enabled.

 

[JohnS_3CX]

Hi Daniel,

That should be fine for now, can you also let me know when you say "user 1 presses transfer again and call remains on hold with initial user":

• So the call remains on hold with user 1 correct? What does User 1 see on their screen when pressing transfer?
• What does User 2 hear as soon as you press the final transfer button? Does their call with User 1 simply end?
• Can User 1 successfully take the original caller of hold and continue?

I'm also wondering whether the User 1 puts the customer on hold, starts a new call with User 2 (instead of pressing transfer) and then when they pick up, they press transfer again. This will not work and will produce the phenomenon you described.

 

[Daniel_AU]

Hi John,

• Yes - the call remains with user 1. User 1 is prompted for an extension number after pressing 'transfer'.
• From memory user 2 is disconnected once user 1 presses the 'transfer' button the second time. User 1 sees the call is on hold.
• User 1 can take the original call, and try transferring again without success. The original call needs to be ended and created again then can transferred.

I understand what you have mentioned, and this was occurring for a little while until the operator got familiar with this new system. However we are very certain that this is not occurring again.

I can also confirm after discussing with a colleague, that we have seen this first hand, and in our case it was trying to transfer an internal call. We do not transfer many internal calls, usually from the receptionist receiving external calls and transferring to other internal extensions.

 

[JohnS_3CX]

No problem, in this case if the operator is transferring correctly and you have also faced it with internal calls then it is worth investigating further.

I would recommend to to run tshark until you capture one of these problematic call cases and then analyze the capture. You could also open a ticket to support if you want for this investigation.