Caller ID issues showing "uknown" to mobile phones

[golfnutx14]

Does anyone know where these settings are at in CM? we are CM6.3 and I cant find them. The issue is that we have some instances on "unknown" showing up on mobile phones. Wind stream is recommending to make these changes and I don't see them. Thank you.

Nature of address indicator ANSI: Unique national (significant) number
Numbering plan indicator: ISDN (Telephony) numbering plan (Recommendation E.164)
Screening indicator: Reserved for ‘User Provided, Passed Network Screening’

 

[wpetilli]

Do calls to other than mobile phones show the number and not unknown?

I had this issue and it was the wireless carrier who had to fix it. They had to to enable/disable some features on his account, which were related to issues with voice over LTE.

 

[golfnutx14]

It is only to Mobile Phones. Check out this message from carrier support:

We have learned that ATT,Verizon and Level 3 and require specific messaging for caller ID to show correctly for caller ID. I have provided you more information below. You will need to engage your phone equipment vendor to resolve this issue.

This is a very common caller ID ticket you will see. CSR reports caller ID to ATT or VZ cells showing “unknown” (with no number). This is ALWAYS a PBX issue and should never be referred out to carriers. The PBX needs to ensure it is populating 3 calling parameters in order for caller ID# to be delivered to these cell carriers. It may work sometimes w/o these parameters but the only way to GUARENTEE CID# delivery to cells is if the PBX has these 3 parameters populated.

Nature of address indicator ANSI: Unique national (significant) number
Numbering plan indicator: ISDN (Telephony) numbering plan (Recommendation E.164)
Screening indicator: Reserved for ‘User Provided, Passed Network Screening’

If anyone of these 3 parameters are incorrect or not populated then this can cause the reported trouble of “unknown” caller ID to cells.

 

[montyzummer]

If you call a landline and present the CLI , this must be at the carrier level during interconnects , is this your scenario? .... what country are you based in ?

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[golfnutx14]

We are USA in Southern California using Windstream. This so far isolated to calling mobile phones. I was able to replicate it after multiple calls to my mobile, 1 finally showed "unknown".

 

[wpetilli]

We called the mobile carrier tech support with the user of the device on the phone and the wireless carrier resolved this. I'm not finding where the settings you are referencing in my system.

 

[montyzummer]

So this seems to me that the Mobile carriers are looking for the number to be sent in a certain format / specific length.

So in your public unknown numbering table you will need to by the sound of it add the full specifics of your local CLI , im not familiar with US number parameters , but i would ask the carrier how many digits they are expecting to receive from the pbx and adapt your public table to reflect that requirement.

Unless somebody on here has another suggestion i would not worry about the three requirements from the carrier support team as they could be a bit misleading , effectively im reading them as ... if you send the number in the first place ( send number on trunk group form) and in the correct format / length (public unknown table ) it will work.


APSS (SME)
ACSS (SME)
ACIS (UC)

 

[wpetilli]

Not saying this is the exact issue I encountered, but it is as close to it as possible. To prove me off and this not being something to do with voice settings on LTE, I would try alternate mobile phones on 3/4G and see if the issue occurs. If all other phones get the Caller ID, then it sounds like your pub unknown tables are already defined. Getting the mobile carrier tech support on the line with the actual user is something I'd do right away. I would not log a normal ticket because that auto response is what you'll wind up getting.

 

[McVoIPin]

I am experiencing the same issue when calling AT&T cell phones over Windstream. Telco can provide this feature if they are controling your caller ID, but if you are in control, that's where the problem lies. I haven't experienced this on our Verizon outbound route yet, just Windstream. I opened up a ticket and below was there response. Anyone have any luck with the programming parameters on the Avaya CM?

The caller ID issue you are experiencing is an issue with your phone equipment. ATT Wireless recently made changes to their network in regards to caller id. The call example provided is missing key fields in the caller ID messaging that will need to be set by your phone equipment to support caller id to an ATT Wireless user. These following fields must be populated as such:

• Address signals must be a 10 digit number
• Address presentation restricted indicator must be populated as “Presentation allowed”
• Nature of address indicator must be populated as “Unique national (significant) number”
• Number plan indicator must be populated as “ISDN (Telephony) numbering plan (Recommendation E.164)”
• [highlight #FCE94F]Screening indicator must be populated as “User Provided, Passed Network Screening”[/highlight]

The highlighted field is the one not showing correctly in your provided call example:

Calling party number parameter
00001010 Parameter name 10 Calling party number
00000111 Length indicator 7 $07
0------- Odd even indicator 0 even
-0000011 Nature of address indicator 3 unique national (significant) number
0------- Spare 0 -
-001---- Numbering plan indicator 1 ISDN (Telephony) numbering plan (Recommendation E.164)
----00-- Address presentation restricted indicator 0 presentation allowed
[highlight #FCE94F]------00 Screening indicator 0 reserved (for user provided, not screened)[/highlight]
-------- Address signals [highlight #FCE94F](XXX)XXX-XXXX[/highlight]omitted

If these values are not set caller ID delivery cannot be guaranteed. You will need to contact your equipment vendor to properly program your equipment. We can take control of your caller ID which will properly populate these fields, however we would only be able to send one number for all calls from your trunk group.

 

[jimbojimbo]

Anyone find the specific resolution? I assume this would be either

1. Codset to send display - change to 0
2. ARS - change to natl
3. Route Pattern - change number format to natl-pub.

 

[golfnutx14]

@JimboJimbo, I forgot to reply the fix, but the issue is exactly what WPETELLI described. I tried fixing the settings Windstream talked about in the PBX and they are not all there. Because I ran out of ideas, I called ATT Wireless and described the issue, and lo and behold, they knew what it was.

ATT wireless has validated that they are having an issue in which certain phones, like IPhones, are not always receiving caller ID. They are developing a permanent fix; in the meantime they have a work around. This work around requires the affected users to call ATT Wireless regarding on their own line and ask for a specific feature to be disabled. This feature is called ATT HD Voice on LTE.

The purpose of this feature is to deliver better call quality to mobile phones. There is a risk with the work around: consider that by disabling the feature temporarily, it will resolve the caller ID but it can lead to lower voice call quality. I do want to state that I validated the fix by ATT. I was experiencing the “unknown” caller ID issue coming from my company since it was reported. As soon as ATT Wireless support disabled the feature and I rebooted my phone, the company Caller ID does come thru successfully. ATT Wireless is working on developing a permanent fix and will push the fix out to affected mobile phones when they are ready.

 

[ZeroZeroOne]

We experienced the issue with mobile phones but also some landlines. Some of it could be related to the voice over LTE but making some key changes seems to have fixed the issue:
[ol 1]
[li]Station, Page 2: Per Station CPN - Send Calling Number: Y[/li]
[li]Public-Unknown-Numbering: Make sure all extension ranges have an entry for all trunk groups. If you have multiple gateways and trunks, calls may hit a trunk where only local extensions have been defined.[/li]
[/ol]