Caller "lost" ( with Hold-On Music ) after a Consultative Transfer

[Danny_Ghe]

I have a sporatic issue with the consultative transfer.

And the end of a consultative transfer the callee doesn't hear anything, and the caller still hear the hold on music.
If the callee hangs , the call is ended normaly .

Look at this example :

20/08/2019 12:18:51 (Caller) EXT (324) 00:00:17
20/08/2019 12:18:47 EXT (340) EXT (324) 00:00:04
20/08/2019 12:17:55 (Caller) EXT (340)

Extension 324 doesn't hear the Caller at 12:18:51 , and the caller still hear the hold-on music during the 17 seconds

Any idea ?

Thanks in advance,
Danny


I have attached the some part of the real log ...

 

[JohnS_3CX]

Hi Danny,

Does this affect external calls only or does it also happen for internal calls?

Does your trunk have Supports Re-Invite and Supports Replaces turned on?

 

[Danny_Ghe]

Hi,

Apparently external call only .

Supports Replaces and Re-Invite are checked in the Sip Trunk Config.

The problem appears randomly even when calling from the same external number.
This problem is reported in a remote site ( connected via IPSec VPN - SIP ALG is disabled )

 

[Nicholas Butler]

I have a sporatic issue with the consultative transfer.

And the end of a consultative transfer the callee doesn't hear anything, and the caller still hear the hold on music.
If the callee hangs , the call is ended normaly .

Look at this example :

20/08/2019 12:18:51 (Caller) EXT (324) 00:00:17
20/08/2019 12:18:47 EXT (340) EXT (324) 00:00:04
20/08/2019 12:17:55 (Caller) EXT (340)

Extension 324 doesn't hear the Caller at 12:18:51 , and the caller still hear the hold-on music during the 17 seconds

Any idea ?

Thanks in advance,
Danny


I have attached the some part of the real log ...

I am having the exact same issue. I'm on the latest release using yeahlink t48s phones on Wiretap Telecom sip service

 

[Danny_Ghe]

I am having the exact same issue. I'm on the latest release using yeahlink t48s phones on Wiretap Telecom sip service

I'm also running the latest release (16.0.2.910) with Yealink T46S IP Phones ...

 

[JohnS_3CX]

Please uncheck those options in the trunk and try again

 

[Nicholas Butler]

Please uncheck those options in the trunk and try again

Which options do you want us to uncheck?

 

[Nicholas Butler]

I already have Support Replaces and Supports Re-Invite unchecked. I've tried both ways

 

[JohnS_3CX]

Supports Re-Invite and Supports Replaces should be off in the trunk settings, but they should be on in the per-extension settings.

You said the site is connected via VPN, so I'm guessing the phones are configured as "Local LAN" yes?

 

[Nicholas Butler]

For me I have those settings enabled per extension, not on the trunk. Having same issue

 

[JohnS_3CX]

What is the:

-PBX Version
-Trunk Provider
-Phone model and Firmware
-Type of connection between PBX and Phones (LAN/SBC/STUN/VPN)

 

[JohnS_3CX]

Does it also happen when using a softphone/webclient or only on deskphones?

 

[Nicholas Butler]

3cx 16.0.2.910
Sip provider is WireTap Telecom
Yeahlink T48s 66.84..0.35
We are all connected via local lan but using stun. I've used local provisioning and the symptoms were worse. (Can't answer calls, can't transfer etc) but I am using stun to my fqdn using a local DNS server pointing to the local ip. I've also tried the external, same problem. Also we don't use the softphone or web client

 

[Nicholas Butler]

here is whats recorded in the log.. NOT ANSWERED.. even though the other party picks up.. and the caller hangs up after some time on hold..

 

[Cody Schilke]

For those on Wiretap Telecom SIP trunks, please feel free to contact us directly for forwarding interop testing. We're always happy to assist and offer input.

 

[Nicholas Butler]

Cody, could this be an affect of WireTap? The service has been perfect for us.

 

[Cody Schilke]

Hi Nicholas, I'm happy to hear that the service has met your expectations. Although I don't believe our trunking platform is the causative factor here, I do believe that we may be able to adjust to accommodate various conditions. It's possible that the issue appears to be random due to how various at-large NAT'd routers/firewalls process direct media. This said, we can work with you on some testing where we can deny any peer-to-peer bridging, etc.

 

[Nicholas Butler]

Cool deal, I'll call tomorrow. Thanks so much for all you guys do.

 

[Cody Schilke]

Happy to help!!

 

[JohnS_3CX]

Hi all,

Let us know how it goes and kindly share your solution to help future members that might benefit.