SDS Distribution Errors Invalid Directory Number

[mitel361]

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.

[acejavelin]

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.

[mitel361]

Thanks for the info and you are on track.  I just cannot pin point the root cause.

User’s 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.

[acejavelin]

Thanks for the info and you are on track.  I just cannot pin point the root cause.

User’s 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.

[mitel361]

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.

[lundah]

I've got a recent install on 9.0.3.24 doing the same thing.

[mitel361]

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.