Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: mitel361 on June 04, 2020, 12:30:30 PM
-
MvB v9sp3. User sets a MiCollab status to dial a mobile number as needed. On the MCD I get an SDS error to the resilient MCD for the Call Forwarding Profile form w/ the reason Invalid Directory Number.
Both MCDs match when checked regarding the users directory number in the form.
If I retry within the SDS form, the error does not clear. I have been advised to use caution when Deleting SDS errors, so I have not used that.
An SDS sync will clear the error.
My question is whether or not this type of error can be Deleted safely w/o impact to a DB entry? Also, if there is any insight as to why this happens.
Regards.
-
This is pretty common in some of my systems that are "geo-diverse" or have trunking solutions with different dialing patterns or outside access codes are different. For example, the users set's their call forwarding to 82221234 and when it propagates to system B 8 is not a valid outside access code, or 2221234 doesn't have a valid match. Seems to me I ran into an issue once in System Options where the outgoing external call prefix for applications was missing from one of the systems. Basically this error is saying the number they are forwarding to is valid in your primary system but invalid in the resilient one.
-
Thanks for the info and you are on track. I just cannot pin point the root cause.
Users MiCollab status forwards to a 10 digit cell number 1234567890. MiCollab adds dialing prefix 9.
Primary MCD has an ARS Digits Dialed of 9NXXXXXX entry (I assume hits this one as the others are not close to matching) Unknown digits to follow List 10
Secondary MCD has both an ARS Digits Dialed of 9NXXXXXX and 9 + 10 to follow not sure which one it would fall into.
The 9NXXXXXX 0 digits to follow > List 9 = Route 9 w/ Digit Mod 9. Digit mod 9 absorbs 1 and inserts 214.
I would assume that would work although pointless as a different area code is added.
The 9 + 10 > List 10 = Route 10 = Route 10 w/ Digit Mod 10. Digit mod 10 absorbs 1 and no insert.
I would say this is the right one to use
and setup correctly.
The COR is fine to the best of my knowledge.
Now that user works from home the majority of the time, the SDS error appears more often.
Any insight as to which List would be used on the Secondary based on the information provided?
Much appreciated.
-
Thanks for the info and you are on track. I just cannot pin point the root cause.
Users MiCollab status forwards to a 10 digit cell number 1234567890. MiCollab adds dialing prefix 9.
Primary MCD has an ARS Digits Dialed of 9NXXXXXX entry (I assume hits this one as the others are not close to matching) Unknown digits to follow List 10
Secondary MCD has both an ARS Digits Dialed of 9NXXXXXX and 9 + 10 to follow not sure which one it would fall into.
The 9NXXXXXX 0 digits to follow > List 9 = Route 9 w/ Digit Mod 9. Digit mod 9 absorbs 1 and inserts 214.
I would assume that would work although pointless as a different area code is added.
The 9 + 10 > List 10 = Route 10 = Route 10 w/ Digit Mod 10. Digit mod 10 absorbs 1 and no insert.
I would say this is the right one to use
and setup correctly.
The COR is fine to the best of my knowledge.
Now that user works from home the majority of the time, the SDS error appears more often.
Any insight as to which List would be used on the Secondary based on the information provided?
Much appreciated.
Look at the SDS error and see what number is being pushed and failing (let's say 912122221234), then go to the resilient controller and go to maintenance commands and enter:
DGT TRACE 912122221234
and you should get some output like this:
DGT Trace started:
912122221234 : ARS 91 + 10, ARS 91 + 10, Route (2)
DGT Trace completed.
Which will tell you what exactly it is matching to, otherwise if there is no match you will see:
DGT Trace started:
No definition found.
DGT Trace completed.
My guess is that you will get the later because there is no proper match.
-
The Primary MCD SDS error reason is Invalid directory number. Number 1234 Call Forward Type Always Forwarding Destination
Forwarding Destination is blank. I have asked the user what they are doing and the response is always setting the MiCollab Status to "Remote".
Checking this status in MiCollab definitely has the entry 'Remote'... Send my calls to CellPHone (1234567890)
I would have expected the 1234567890 to be listed as the Forwarding Destination.
For grins... the user directory number is a valid number in the Secondary. It is shared and does exist.
Thanks again.
-
I've got a recent install on 9.0.3.24 doing the same thing.
-
On the SDS Alert, I assume that there were no digits because it was a CFwd Table update.
The change that fixed was to remove the 9NXXXXXX entry in the ARS Digits Dialed. That referenced a route that would ultimately add 3 more digits via the Digit Modifications.
The system appears to favor the 9 + 10 ARS Digits Dialed.