CER issue showing incorrect ELIN & ALI information

[00u1c1e8sgNfbgbZ15d7]

I have a CER system version 12.5.1.

When we run calls to 911, PSAP agent is not watching proper ELIN and wrong ALI information.

PSAP agent is only seeing SP's default main number and address associated to my customer account.

At Web alerts ( from CER user portal) we confirm that CER is providing proper ELIN & location information ( from ALI associated to testing ERL), but PSAP agent does not receive it.

We also confirmed from CER user portal’s call history that proper ERL’s RP & ELIN were used.

My customer is using 2 PRIs ( on MGCP gateways) for integration to PSTN.

I found the customer has one generic RP “12XX.911” to be used for all ERLs, and on this RP the “Use Calling Party’s External Phone Number Mask” option is deselected.

For ERL used on my test calls I created an specific 911 RP using number associated on ERL (my case 1205.911) instead of using generic “12XX.911” and I selected “Use Calling Party’s External Phone Number Mask” option on it.

My questions:

1. Besides my new RP what other recommendation you could suggest to solve wrong ALI & ELIN information received by PSAP agent on my 911 calls?
2. Is a good recommendation to have specific Route Patterns per ERL instead to use a single generic one?

I appreciate your help

Enrique

[TomMar1]

Have you confirmed what ELIN(s) you are sending on outbound calls from various CER ERLs?  The ELINs need to be labelled correctly by your service provider to show the address and more specific location information when presented to the PSAP.  I would confirm with the provider and ask them to send you a copy of your customer specific PSALI records.

[00u1c1e8sgNfbgbZ15d7]

TomMar1, thanks for your comment.

I will validate with the customer that.

I just confirmed from CER User portal that calls are providing proper ELIN

[Adam Pawlowski]

Assuming your call routing works, as mentioned the telephony service provider will have to ensure that you are allowed to send calls with the specified ELIN. In many cases, without such request or accommodation the account's billing telephone number (BTN) or main/pilot number is displayed instead, as the calling party number is discarded by the carrier and replaced.

[kylebrogers]

Sit on your voice gateway and run debugs to see what number you're sending our your PRI/SIP trunk during a test call.  If you see the correct ELIN go out for that ERL but the PSAP sees a different number, then the telco is likely masking all outbound calls on the trunk with a specific number.  That's not unusual.  The telco will need to take off that mask.  

!!!!!!!!IMPORTANT NOTE!!!!!!!  This means that all of your regular calls out that trunk are also being masked by the telco with that number.  So once they remove it, they will fall back to whatever number you send out.  Depending on your configuration, that could be the External Phone Number Mask on each user's line, or just their extension if they don't have an EPNM set or it's set to not use the EPNM.  This can cause issues if the user doesn't want people they're calling to have their DID and that's set as their EPNM.  Or if they don't have anything set and just their extension gets sent out it's possible that the telco will block that call because it's not a number (a full phone number) associated with your trunk.  So do some digging an figure out what will happen to non-CER-affected calls if the mask is removed before you tell the telco to remove it.  

[Adam Pawlowski]

In our case, to get this feature from the carrier required signing a document saying we would only send calls for which we own the number, or in the case of call forwarding, which were received.
We weren't allowed to send *, 12345, other numbers, etc. If someone "doesn't want people to have my number" then yes you'd need a different mask or some other treatment, but mind that if you use CER's off-prem , the unique DID for the caller is based on the external number mask. Privacy is an option assuming the carrier supports privacy flagging, or *67 prepending or similar.

Otherwise you'd want perhaps some sort of treatment on the gateway to transform (....) to your company's BTN or similar to avoid sending something weird.
It may or may not route to some or all destinations if you do and is improper formatting.