Unknown on Calls Forwarded to Cell Phone

[WJB]

I know this has come up many times before since cell phones made the switch to VoLTE, but I'm still struggling to find the solution for our own Mitel 3300 PBX (running Release Level 7.2 SP1 PR1, Active Software Load: 13.2.1.27). Before VoLTE was enabled, extensions from within our company were forwarded to our cell phones (which as a part of a personal ring group) and would show up as a 4 digit extension. However, with VoLTE enabled, they now show up as unknown on the caller ID.

Where should I start looking to try and correct this so that either the full # is passed through or even just the 4 digit extension again?  Or what other information can I provide to help narrow down the scope of this question a bit?

Thank you.

[Dogbreath]

As you've mentioned VoLTE can I assume that calls reach the cellphones over the PSTN? If that's the case then I wouldn't expect a 4-digit caller ID to be passed.

[WJB]

That is correct. Calls do reach the cell phone over the PSTN, but without any number on the caller ID, so it just reports unknown. I'm wondering why the 4 digit extension isn't being re-written with the full set of digits via our existing CPN substitution rules . Or maybe that has nothing to do with this particular issue.

And hopefully I was clear in my original description about incoming calls ringing both the cell phone and internal VoIP phone at the same time.

[Dogbreath]

What type of trunks do you have? If it's SIP I would do a packet capture and see what number is being sent. If you think you're sending the correct number and your carrier isn't passing it on then raise it with them.

[x-man]

I think,IIRC, SIP CPN substitution has to be set in the SIP peer profile rather than the 'normal' place in CPN substition. (assuming VoLTE is SIP).

[ZuluAlpha]

Are you using a softphone over LTE or is this a carrier switch to using VoLTE for PSTN voice traffic?

[WJB]

It's a PRI trunk. We are not using a softphone over LTE. We only have the single Mitel 3300 PBX node.

I should note that our cell phones are set up as phantom devices with their own phantom extension with the cell number being plugged into the External Hot Desking Number field for that device. For example, a desk phone could be 7889 and the cell phone device would be set to ext 8889. Both devices (7889 and 8889) are then configured as a personal ring group.  So if somebody calls 7889, it automatically rings 8889 at the same time. However, since it's only passing 4 digits to the cell phone (i.e. going out through the PSTN) it shows up as unknown on a cell phone's caller ID.

From incredibly similar reported issues its often mentioned that the numbering plan on the PBX needs be updated from unknown to ISDN, but I do not believe that is an option on our particular system unless we were using a E1 embedded PRI.

Let me know if there is any other information I can provide.

[Dogbreath]

In my opinion, presenting 4 digit extension numbers over the PSTN was only ever a fluke if it was working. I could be wrong of course, this might be totally normal in your country.

I think you should focus your efforts on fixing CPN substitution for your EHDU extensions.

[VinceWhirlwind]

In the US, they are allowed to present anything they want - which the phone-spammers love of course.
 
In my setup, the digits presented to the outside world are set in the "CPN" table on the 3300, and allowed through by the MBG.

[PC77375]

In the US, they are allowed to present anything they want - which the phone-spammers love of course.
 
In my setup, the digits presented to the outside world are set in the "CPN" table on the 3300, and allowed through by the MBG.

I will SHAKE this thread up. This is not really the case any longer! Thank you STIR/SHAKEN. It is causing us a major headache right now as we are unable to send originating caller ID on forwarded calls. I am in a back and forth with Lumen over it as I type this. They are only allowing calls from "authorized DID's". Anyone else come across this yet and how to fix it??? I tried configuring MiVB to send the forwarded stations caller ID, but now Lumen said that we are handing them "Unknown". I even tried to use CPN substitution with an "authorized DID", still fails.