VMP SMTP Voicemail to Email - Not working for Caller IDs with a Comma

[effectivecommunicat]

HI All,

I wanted to see if others have come across this problem. I have (2) confirmed customers now that have this problem. One has an IP500v2 R9.1 with preferred edition and VM PRO and uses SMTP with google apps for business. The other has server edition with the DL360 Primary Server at R10 and uses SMTP relay with Office 365. The way voicemail pro copies the caller ID of the caller and inserts it in as the email sender name is causing an issue when the caller ID has a comma (typically T Mobile customers). The comma makes it appear as there are 2 senders on the email and rejects it. This has been a problem for users who have VM to email set to forward because they're missing certain voicemails.

Any one else see this out there? I assume it would have to affect most users with VM PRO using SMTP anonymous relay. I have a ticket open with Avaya, but wanted to check with Tek-Tip community.

Thanks

effectivecommunicat
ACIS, ACSS Certified

 

[janni78]

The issue is probably that comma is a valid character in the SIP From header but not in e-mail.

They would need to "wash" that away, unless you have a SBC in which case you could solve it there.

"Trying is the first step to failure..." - Homer

 

[telecomtekperson]

This is a bug that Avaya is aware of and working on a fix.

 

[sizbut]

No its not a bug. If you input an address that is invalid for email no surprise it doesn't work - garbage in, garbage out. The bug, if any, is that the voicemail server tries to send anything - Avaya would be within their rights to fix that by not sending a thing.

As said the cause is external, the world of SIP adopted the name@domain address format but some providers are being rather loose with what they allow in the name part.

To make a fix that sends those emails means they have to alter the source information and hope that doesn't cause further complaint downstream - like when you try to use it for return call functions from whichever app receives the emails.

Stuck in a never ending cycle of file copying.

 

[Westi]

sizbut
the caller ID is not in the address field for the email recipient it is in the subject line so should not matter.
is it at least trying to send or is the vm not even attempting to send

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[effectivecommunicat]

Correct Westi.

Sizbut - When voicemail pro uses SMTP for the sender it captures the Caller ID (Both SIP trunks and PRI) an puts it in as the sender name. So, the email appears as though it is coming from the person that left the voicemail even though the SMTP account is really sending it. When the caller id has a comma, it interrupts the email from being delivered .

The email sender looks like this:
DOE, JOHN <voicemail@abccompany.com>,

with subject line of:
Voicemail Message (DOE, JOHN > Sally Smith) From:7202002000

and for some reason the comma that is pulled from the Caller ID makes the email fail because it thinks there are two sender accounts. I have it happening on users with PRI and SIP trunks... Google Apps for Business and Office 365.

I'm hoping what telecomtekperson says is true, since this is troublesome for many customers.

Thanks for the comments.

effectivecommunicat
ACIS, ACSS Certified

 

[sizbut]

For by the RFC email, the Sender field and the From fields have the same restrictions on what you can include in the local (name) part of an address - commas have to be " " quoted (along with a range of other character. If you don't then the address is invalid.

Stuck in a never ending cycle of file copying.

 

[twitchy087]

I too have been fighting this pest of an issue. This really is on Avaya to fix at the system level so that they do not simply pass anything that they are given. CNAM supports the use of a comma and the IPO simply passes that through as the from address. The source of the issue really is that CNAM and email standards do not align. If you have a middle man (IPO) in play using both tools then it should be able to adjust to make it work. I am working on my end to have our SMTP relay strip the from header and replace is with a constant, acceptable name. This is not yet accomplished but that is the theory that I am going by to fix this until the IPO can send messages that work with email standards.

 

[janni78]

Sure they should fix it...

Meanwhile if you have a SBC that can fix the issue, or VM Pro should able to "wash" $caller_name.

"Trying is the first step to failure..." - Homer