Direct Inward Dialing Service

[fishhead64]

Every once in a while, an entry in the DID table disappears. Callers just get a failed call.
There are only two of us with access aside from the vendor and we're certain we're not deleting it.

Is this a known issue or is there a log that can tell us who deleted and when?

Thanks!
Al

 

[sarond]

The only thing I've noticed is that if an extension is deleted, then the destination is blank for the DID it had. The DID still exists, there's just no destination for it.

If the entry is completely gone I would check the audit trail log for any hints.

 

[HAPE67]

I have the same problem. If there is a solution for this issue I like to hear it.
The entry is not gone, but the Destination Number is gone.

 

[fishhead64]

Our issue is that the whole entry is gone.
It was suggested on mitelforums that deleting a set with a DID mapping would cause this. We'll have to test.

We did delete a user/phone that may have had a line key appearance of that extension (we're not sure and it's gone now). Not sure why it would delete a DID entry when there still exists the main phone with that extension and the user deleted (if he had that key at all) only had a secondary line key appearance.

 

[AH64Armament]

If you have a number assigned to one extension and you add it to another, it may blank it out from the first.
I have also seen where if you unassign it from a user under the users and devices, it will leave part of the entry in the DID mapping, but clear out parts.

As others mentioned, I would export the audit trail, then you can open it in EXCEL. Then you can search for the DID number.

 

[fishhead64]

Thanks, I looked at the audit file and the only thing I see is me adding the entry back in, not where it got deleted. The log goes well back beyond when it was known working.

I do see the delete record of the suspected phone which ~may~ have had the line key appearance. Is there a log that will show me what keys were on a deleted phone, then we'll know for sure.

Curious the benefit of using DID routing table and working this way. I come from a Nortel background and we never had to touch DIDs. If the 4 digits were assigned to a station, that's where the DID terminated (unless we twisted it intentionally; sent to VM, ring group, ACD queue, etc.). If not, we gave "non working number" message.

 

[AH64Armament]

Thanks, I looked at the audit file and the only thing I see is me adding the entry back in, not where it got deleted. The log goes well back beyond when it was known working.

I do see the delete record of the suspected phone which ~may~ have had the line key appearance. Is there a log that will show me what keys were on a deleted phone, then we'll know for sure.

Curious the benefit of using DID routing table and working this way. I come from a Nortel background and we never had to touch DIDs. If the 4 digits were assigned to a station, that's where the DID terminated (unless we twisted it intentionally; sent to VM, ring group, ACD queue, etc.). If not, we gave "non working number" message.

This DID table is a fairly new feature on the MiVB platform. In the past, we did either matched the extension numbers with the last 4 (or more) digits of the DID number. The only issue with this was that extensions can't begin with a zero or 9 as it conflicted with voicemail services or ARS.
This was very helpful in many cases as sites with one bank of numbers, it was simple to determine your phone number based on the extension number. At the same time, if you have multiple ranges of DID numbers, this could cause overlaps or confusion to the end users. If my Extension number 1234 matches my phone number 2015551234, it could stand to reason that your phone number would be similar if your extension number is 2345. One could think that your phone number might be 2015552345, when it might be associated with another prefix altogether.

Another solution was to assign whatever extensions that you want and add the DID number as a system speedcall to ring that extension. This in my opinion is super confusing in the long run.

Mitel adding the Direct inward dialing service form is simply another way of doing what we've always been doing. It ties into the Users and Services form - service details tab. If the number gets changed in there, it will affect the DID Service form.