Hang up after 1st missed transfer

[David_K]

Hello

I have this issue on a 3CX server at a customer :

- Hunt group 800 rings
- extension 100, member of the group, picks the call
- caller asks to talk to Mr XXX, who is extension 104
- so extension 100 press Transfer (putting caller on hold) then dials 104
- 104 rings, unfortunately, no answer, so after XXX seconds it says "voicemail for extension 104 not activated" (default behavior because customer did not want indidivual voicemails)
- so 100 swicthes back to the caller that was on hold, and tells him that 104 is not available, and that she'll try to transfer to 105 instead
- so 100 press Transfer --> and this hangs up the call immediately, without even having the time to dial 105

Customer told me they can reproduce 100% of the time : if 1st transfer fails (for any reason like DND, no one answering...), the 2nd transfer trial will hang up immediately

A clue to what's hapening?

I know all extensions have the default "Forward to voicemail" rule when not picking up and that they don't have the voicemail activated.
But that should not hang up 100's transfers.
Especially since the customer told me it was always working before (it seems they have the issue since we've upgraded to v16 some months ago)

 

[Mister VoIP NL]

what are you using on the cliënt side?

- Webcliënt
- 3CX Windows client --> CTI or with headset
- IP Phone --> which model

 

[David_K]

Customer told me that it seems she only have the problem when she uses her Yealink T46S in the office.
Not when she's using the iOS app.

I just went to the list of the phones, and strange, I see her T46s two times in the list, with the same Mac address...

 

[Mister VoIP NL]

That is strange, but for sure that's the cause of the problem. Is the Yealink phone provisioned the right way?

Is the 3CX phone in the local LAN or Cloud? If it's Cloud are you using an SBC or DirectSIP?

Maybe factory default the phone and provisioning the phone again is a solution....

 

[David_K]

It's an onsite 3cx server, so direct LAN connexion

Asked the user to factory reset, but that was 10 minutes ago and I still see the old configuration in Phones, normaly it should show as "New", no?
I even went to the 100 extension and deleted the phone in Phone Provisioning

What bothers me is that the phone was showing in red "Not supported 66.83.0.55" in the firmware version
Hope it'll still be able to connect after factory reset...

 

[Mister VoIP NL]

https://www.3cx.com/community/threads/known-issues-at-firmware-upgrade-yealink-t46s.68838/

Maybe also an issue with this firmware version...normally your phone has to turn up as NEW indeed.

 

[David_K]

I remember now...
This customer has around 80 phones and we had to upgrade them all manually 1 by 1 after we upgraded from 3CX v15 to v16, so we left them like that because we had no time
I'm in the pain to upgrade it manually now, just remembered you first have to yo upgrade to 66.84 firmware before being able to upgrade to 66.85...

 

[David_K]

OK I did upgrade 66.85 but it did not resolve.

I've tried it as the caller by myself.

I call the customer, so 100 picks up the call.
She push Transfer, dials 104, but 104 does not answer and after some seconds, she gets his voicemail
So she switches back to my call, and tells me she'll try to transfer me to 105
So she press Transfer again, and she immediately looses the communication (not even having time to dial 105)
And me, as the caller, I now get connected with 104's voicemail...
That's really strange.
Especially since 104's voicemail is not checked as Enabled in the extension...

And in the log I can see exactly that (replaced my number by XXXXXXX)

09/29/2020 4:25:29 PM	HLB:ELZON (+33XXXXXXXXX)	VMail (104)	00:00:15
09/29/2020 4:24:42 PM	Shirine (100)	VMail (104)	00:00:47
09/29/2020 4:24:17 PM	HLB:ELZON (+33XXXXXXXXX)	Shirine (100)	00:01:12

Meanwhile I'm reading what I'm writing, is it not that she's really connecting me with 104?

 

[David_K]

OK that was it... It's "normal" behavior

In fact user tries to forward to 104 and gets voicemail. Instead of hanging up with the voicemail, she was putting the voicemail "onhold" then switching back to the initial caller, then when pressing "transfer" this was transfering the initial caller to the "onhold voicemail"

 

[Mister VoIP NL]

haha, glad you found the answer!