Solved Emailed voicemails caller and caller name broken in v20

Status
Not open for further replies.

smaloney

Customer
Joined
Jan 3, 2023
Messages
10
Reaction score
2
Prior to v20, the caller number and name (if entered in the company address book) would be substituted for SP1, SP2, etc. in the resulting email.

After v20:

From:SP1
To: 1200" - "John" "Smith"
Received:"Friday, March 15, 2024 1:13:24PM"
Duration:"00:01:15"
File:"vmail_SP1_1205_20240315171324"

PARTIAL CDR:
TerminatedBySrc,Line,,4195555555,Ext.8000,Queue,Main Q,VMail,Ext.9999,1200,ReplacedDst,Chain: 4195555555;Ext.1100;Ext.8000;Ext.1100;Ext.SP1;Ext.1100;Ext.1200;Ext.9999;

If an inbound caller arrives straight to voicemail, it functions as expected.

Any ideas?

Self-hosted: AWS EC2; V20.0 1620
 
Hi, Let us know if you are using an umodified template for a supported provider for these emails......
 
Sorry for the extended delay in my response.

The template is unmodified, and our primary SIP trunk provider is Amazon Chime. We have a second trunk configured with Voip.ms with the same issue.

Additional details:
1. The issue described here occurs whether the inbound caller is in the company address book or not.
2. The issue only occurs when attempting a blind transfer direct to voicemail using *4[extension] after first having been parked.
3. The issue does not occur when attempting a blind transfer to the extension, which ends in voicemail after first having been parked.

So... this really seems to be about whether *4 is still viable, and if not, is there an alternative/workaround?
 
The *4 dial code(by default) is used to connect to a voicemail of an extension, which also requires a PIN.
May i know the exact call scenario and steps to reproduce?
 
Sure!

1. An external inbound call is answered by a live receptionist.
2. Receptionist parks the call (SP1).
3. Receptionist checks whether the call recipient is available.
4. Receptionist picks the inbound call back up, then blind transfers to the recipient's voicemail by pressing transfer, dialing *4, then pressing the appropriate BLF for the recipient.

I've ruled out the use of BLF as the issue occurs even when pressing transfer, dialing *43500 (where 3500 is the desired extension), then pressing transfer again.​
I've also ruled out the desk phone, as the issue occurs when using the windows application dialer:​
Pick up caller from SP1, hit transfer, dial *43500, then press green call button.​
I can also add that the issue DOES NOT occur if the caller is transferred to voicemail using in chrome or windows application panel (right click, transfer, then selecting from the drop down menu the intended recipient's extension, voicemail option).
 
I have also tested this on my side with the exact provided steps and i have the correct information in me email notification.
What is the model and firmware version of the phone?
 
Thank you for your help.

Yealink SIP-T53W and SIP-T53 all running 96.86.0.77
Yealink SIP-T58W running 150.86.0.63

Just keep in mind I can reproduce the issue by doing all of the steps from within the webclient dialer.
 
I have tried all ways but not able to replicate.
Can you also update the PBX to the latest Update 1 and let us know?
 
I applied Update 1 last night and the issue appears to be resolved! Yay!
 
  • Like
Reactions: Charles_3CX
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,953
Messages
589,915
Members
164,850
Latest member
masvty