Trouble migrating some extensions off of Mitel 5000 to cloud solution

[jjc8008]

The Mitel 5000 at our main location has about 140 phones on it. Almost all follow the same number pattern, lets call it: 666-666-6600 through 6800. Almost all extensions follow the same as the full dialing pattern, i.e. 666-666-6610's extension is 6610, and so on). Roughly 6 phones are at a separate building, connected over BOVPN (we'll call those 666-666-6661 through 6666). We're moving everything to a cloud solution, and decided to start with the 6 phones at the satellite building. We make the switch, phones seem to work fine, all still have their same numbers (666-666-6661 through 6666), we test calling back & forth from the newly migrated phones to cell phones, good to go.

So back at the main location, we test what happens when we call the numbers that have been migrated at the other building, and it rings into the extensions old voicemail box. No big deal, I assume it's likely that 666-666-666_ numbers are still in the Call Routing Tables and since it can't find the extension that it is pointed to, it goes straight to the mailbox associated with it.

I guess the main question at this point is, how should we handle this? Since we have many phantom extensions which work fine, I tried removing one of the lines from the routing tables, deleting the extension and mailbox, and making a phantom extension that is the same four digits as the extension (i.e. 6664), which is forwarded to the external number (666-666-6664) so that they can: A) just dial the extension like they always have, and B) since the full number (666-666-6664) is no longer in the routing table, they can dial the full number if they want. Unfortunately, option A) defaults to our front desk for some reason rather than getting forwarded out to 666-666-6664, and B) rings indefinitely, but we have no idea what is actually ringing or where, because the correct phone shows no sign of ringing, and it doesn’t ring to the front desk like with the phantom extension in scenario A.

On one of the other lines, I connected a phone back to one of the extensions that still exists on the Mitel box (i.e. 6663), hit forward all > 666-666-6663. When called it rings indefinitely just like scenario B above.

It’s as if, despite removing any trace of 666-666-6664 (at least that I can find: Routing Table, Extension, Voicemail), and then rebooting the server, it still tries to keep the call within the Mitel box when dialed rather than going out?

One other thing that seems to support this is that two of the 6 phones we migrated have a secondary number that does work when called from the main building. When I look at one of these phones in the cloud portal, there are two numbers listed for it, we’ll  call them: 666-666-6665 (the legacy number) and 777-777-7777. When calling both from a cell phone they work, and when calling the 777 number from the main building it works, just not the legacy 666 number?

[Tech Electronics]

jjc8008,

Let me see if I understand correctly.

You moved a sight to a new phone system with a DID range of 777-777-7700 thru 7800 instead of porting your old DIDs numbers to the new system? Are you at some point going to port the old DIDs to the new system?

The old phone system still has the DID range of 666-666-6600 thru 6800 and the phones use the last 4 digits of the of the DID as their extension.

When you call out of the new site on the new phones there they seem to work fine when calling a cell phone, as expected.

You deleted the old phone extension and recreated it as a phantom extension that is Forwarded to its own DID which no longer has a route in the Call Routing Table.

IF you didn't port your DIDs to the new phone system then the calls will ring into the old system.

IF the old system can't route the DID anymore because you deleted the Call Routing Table entry it will just ring with no answer if you don't have a + or E entry as a catch all.

I am not sure how you setup your new Phantom extension to make it call the front desk, but look at the associated extensions of that phantom and tell me how they are programmed. Also make sure you setup your System Forwarding to support Internal Calls as by default it doesn't.

Thanks,

TE

[jjc8008]

You moved a sight to a new phone system with a DID range of 777-777-7700 thru 7800 instead of porting your old DIDs numbers to the new system?

(You can ignore the mention of 777-777-777, it's not a new DID range or anything, I'll explain it at the end)

The numbers actually have been ported over - six lines that were originally part of the Mitel system at our main location are now part of the cloud system, those 6 phones are physically located at an offsite, and have retained the same numbers that they originally had when on the Mitel system. Once they did the cutover, we can call the newly ported/migrated phones from any external line (cell phones, external land lines, etc), we just can't call them from the old Mitel system that they used to be part of at the main site, where the other 134 phones are still at.

When I attempt to call one of the ported numbers from the Mitel system, they are still in the Mitel routing table (as 666-666-666_) so it goes straight to the old voicemail for that line. That all makes sense because it still exists in the routing table, and the extension & voicemail are still there. So the question is what's the best way to go about this because I'm only guessing. My first guess was to delete any trace of one of the lines and make a phantom extension that is forwarded to the DID. Here are the phantom settings which are identical to ones that we've been using for things like an after hours answering service (at the end of the day the main reception phone forwards all of their calls to it):

Phantom extension 6661
Associated Extensions:
> Attendant: NONE (also tried with front desk extension here)
> Message Center: (front desk extension)
> Alternate message source: NONE
> Transfer Recall Destination: 6661
> Voice Mail: NONE
> Outgoing Extension: NONE (also tried with 92001 here)
> Agent Help: NONE
> Agent Help User-Keyed ext: NONE
> Emergency Extension: 92001 (that is a CO Trunk Group, description is PRI)
> Associated User Extension: NONE

Forward Information:
> Forward Destination Extension: 92001
> Forward Username: Outside
> Forward Description: PRI
> Forward Outside Number: 1-666-666-6661 (also tried it without 1 for long distance)
> Forward Extension: 355
> Forward Type: 1
> Forward Public Network: Yes

But when I dial the phantom extension (6661), it goes straight to the front desk line. Like I mentioned, we have a bunch of phantom extensions configured exactly like this that successfully go out to the external number set in "Forward Outside Number". The above (666-666-6661) was one that I removed from Routing Table, Extension, and Voicemail, so theoretically Mitel would have no trace of it. Also since you mentioned System Forwarding, it's worth noting that this phantom extension (nor any of the working ones) have anything under Forwarding Paths.

With one that is still in Routing Table, Extension, Voicemail, I tried setting the Forward Information of the extension itself (not a phantom extension) to point to the ported number (i.e. 666-666-6665), but calling that is when it just rings indefinitely to seemingly nowhere, no phone is actually ringing on the other end as far as I can tell.

The 777-777-7777 number isn't a range or anything, just a fake/throwaway number I added to give more troubleshooting clues. Of the 6 lines at our offsite which are now in the cloud portal, if you browse these extensions, one of the lines has a secondary number. I mentioned that it was 777-.... as a throwaway, but it's actually just something random that doesn't seem to follow any numbering pattern in line with our old phone system, local area codes, etc (something random like 684-508-8435). I only included this info because it seemed interesting that, of the two DID numbers listed for that phone in question: one is 666-666-6665 (ported legacy Mitel DID) and 684-508-8435 (only showed up once line was added to cloud system), I can't call the legacy DID number that has been around forever, but I can call the new cloud number.

[Tech Electronics]

jjc8008,

OK, that makes more sense to me now.

First of all, when making an outside call, meaning you dial 8+number, it doesn't use the Call Routing Table to make that call.

The Call Routing Table is for Inbound Calls through the CO Trunk Group that the calls come in on.

The Outbound Call will use the Outgoing Extension of the device to make a call. Typically, you will want this to be the CO Trunk Group Extension [Typically 92001] or 92000[ARS], best if it is ARS.

If it is set to ARS [92000] then it will look at Route Groups under Numbering Plan to decide what type of call it is and then use the Associated Facility Group to pick a trunk to go out of.

I have never seen 92001 in the Forward Destination Extension, but I guess that will work. Typically, we use ARS which is PP040, and it would look more like this.

Forward Information:
> Forward Destination Extension: PP040
> Forward Username: ARS
> Forward Description: ARS Device
> Forward Outside Number: 16666666661
> Forward Extension: 355
> Forward Type: 1
> Forward Public Network: Yes

Did you use the Remote Programming Feature [Default: 359] or just manually set this with Online Monitor?

Now, it could be that the existing Carrier on the MiVO-250 is still routing the DID to itself as it hasn't updated its routing yet which is why the call keep coming back to the MiVO-250 and not the new one. You can test that by putting a Route in the Call Routing Table to send it to a phone on the MiVO-250 that you are standing near and see if it rings there, if it is then it is a Carrier issue.

As for the Operator issue look at what extension is setup for the System Operator. Go to System > Phone-Related Information > Primary Attendants which is typically the first programmed phone 1000 which is usually also the Attendant as that exists in the Phones Extension Programming under Attendant.

Let me know if you need me to explain something in more detail.

Thanks,

TE

[jjc8008]

Now, it could be that the existing Carrier on the MiVO-250 is still routing the DID to itself as it hasn't updated its routing yet which is why the call keep coming back to the MiVO-250 and not the new one. You can test that by putting a Route in the Call Routing Table to send it to a phone on the MiVO-250 that you are standing near and see if it rings there, if it is then it is a Carrier issue.

I think that might be the case - let me know if I did this test correctly:

For one of the numbers that had been ported (i.e. 666-666-6661), it still exists in the Mitel system, so I point the route for 666-666-6661 to an unrelated extension (i.e. 6679) and call 8-666-666-6661 from a different extension entirely (i.e. 6678), and when I dial 8-666-666-6661 it rings on 6679. So if I understand you correctly, the route (as far as the Mitel site is still concerned) is still incorrectly looking back at itself and it's a carrier issue?

Typically, we use ARS which is PP040, and it would look more like this.

There are three total CO Trunk Groups:

92001 - "PRI"
92003 - "fax server"
PP011 - "Unused CO Trunks

For the heck of it, I tried them all (even the ones you mentioned) as the Forward Destination Extensions but no luck. Like I mentioned above I think you're right about it being on the carrier's end...

Any idea where that's actually... set? configured? controlled? Does our carrier have mappings "on their end", or is there some sort of config or settings cached on the Mitel box itself? Either way, we'll reach out to them and see what happens.

Whichever way it shakes out, thanks so much for the info, either way I've learned a lot so far

[Tech Electronics]

jjc8008,

Yes, it looks as though it is a carrier issue and not a Mitel issue.

If you can call 666-666-6661 from you cell phone and it rings the new system, but when you call it from a Mitel phone going out through the PRI [92001] and it comes back in and hits the extension 6697 that you routed it to that is a carrier not routing correctly.

I would contact both of your carriers and let them know what is going on and have them fix their mistake as the losing carrier should know to update their routing to match all the others.

Thanks,

TE