3CX - Attended Transfer Fails

[Dilip]

Hi Team,

I am using the 3CX version:15.5.13103.5 in Linux Debian installation.

The problem is when the user answer external inbound call and try to do attended transfer to the another user the call bounce back to the same person who initiated the transfer the external caller is with him.But the blind transfer works.

This flow sequence
1) An external call arrives (4429226XXXXX)
2) Ext:4002 picks up the phone and answer the call puts the external caller on hold
3) Ext:4002 calls the ext:4008 to check if user is free
4) Ext:4002 try to transfer the call to ext:4008
5)In mean time external caller(4429226XXXXX) hears the hold music
6)Call bounce back to the ext:4002
7)Call transfer fails and external caller(4429226XXXXX) is with ext:4002

We have 8 extension configured for the client all the 8 extension are Stun remote extension the phones used are yealink 5-T46G & 2-T48G all the phones are with latest firmware registered with 3cx system.

I have checked the following options in extension settings
1.[pbx deliver audio,support Re-Invites,Support 'Replaces' header] enabled for all the extensions,
2.Also allow multiple call options also enabled
3.All the extensions set to have own local SIP port and RTP ranges since we have provisioned it as [Direct
SIP -stun remote].
4.Firewall checks all passed
5.I have verified the ALLOWSOURCEASOUTBOUND parameter it is set to 1.

I have verified all the possible settings in the phones, extension and 3cx server parameters but could not find why the attended transfer calls fails.if any one has any answers that would be great.

 

[V..]

In order to rule out an issue with the STUN configuration or with the Yealink handsets please can you try and attempt the same procedure using two extensions registered to the 3CX client for Windows \ Mac.

 

[Dilip]

The client is hesitant to use the 3cx windows application they preferring only desk phones. So I am Unable to test with 3cx app

 

[Dilip]

Could you please suggest any other way to sort this issue.

 

[V..]

I am not suggesting that the solution is to use the softphone. However you need to complete this testing to determine whether the issue lies with the PBX or with either the STUN configuration and the handsets.

 

[Dilip]

Hi V,

As per your suggestion I tried testing the above scenario with 3cx windows PC softphone and it was working I was able to make attended transfer, But when I tried the same scenario with Yealink desk phone the call bounce to the extension which initiated the attended transfer.what would be the cause for this attended transfer issue

Phone model used:Yealink T46G & T48G

 

[leejor]

2) Ext:4002 picks up the phone and answer the call puts the external caller on hold
3) Ext:4002 calls the ext:4008 to check if user is free
4) Ext:4002 try to transfer the call to ext:4008

How does 4002 put the caller on hold?
Are they using another line to call 4008, to see if they are free?
Do they then retrieve (how), the caller on hold, and then what method (button?) is used to initiate a transfer?

What does the Activity Log look like for this scenario?

 

[Dilip]

1.How does 4002 put the caller on hold?
Ext:4002 picks up the phone and answer the external call and then press the transfer button and dial the ext:4008. On pressing the transfer button the external caller(4429226XXXXX) goes to [Music on hold] In meantime ext:4002 to get the confirmation from the ext:4008 to trnasfer the call.Then the Ext:4002 press the transfer key to transfer key to transfer the call.But caller transfer fails and the external caller is with ext:4002

2.Are they using another line to call 4008, to see if they are free?
NO

3.What does the Activity Log look like for this scenario?
08/13/2018 6:31:48 PM - Call(C:1356): Failed to perform attended transfer - invalid state

 

[YiannisH_3CX]

3.What does the Activity Log look like for this scenario?
08/13/2018 6:31:48 PM - Call(C:1356): Failed to perform attended transfer - invalid state

I have seen this error before when performing Attended transfers with STUN provisioned phones in the following 2 scenarios:

1. The phones were not using unique SIP ports or those were not correctly forwarded to the local IPs of the phones.
2. SIP ALG was enabled in the firewall of the remote site.

With that in mind i would recommend making sure that the ports are configured correctly and that SIP ALG or SIP helper is off on the remote firewall. You can confirm that ports are configured correctly by running a wireshark on both ends. One through the web interface of a phone and one on the PBX. You should see the phone using the port configured for it in the management console and you should see the same port arriving in the PBX. If the ports do not match then something is changing the ports and causing the issue.