RESILIENCY and SDS errors

[Ronan]

Hello,

our main client has suddenly decided that resiliency would be a good idea after all, after 10 years (and one mess caused by an MXe Server giving up).

We have put things in place, and it works.

However there are tons of SDS errors. I have found the reason for some of them, but others, I don't understand.

For starters there is this, each time someone does a call forward :

Action  modify
Form Name  Call Forwarding Profile
Reason  The user information does not exist or is incomplete.
 
Detail   

CHANGE FROM :

Number                        XXXXXX
Call Forward Type         Always

CHANGE TO :

Number                        XXXXXX
Call Forward Type         Always
Forwarding Destination  350999
Forwarding Enabled       On

If you have an idea...

Thanks

[ralph]

I suspect that ext XXXXX is not resilient.

Ralph

[mszodiac]

I've also seen it when the call forward number is on a different call server than the originating number.

[Ronan]

Hi

I forgot to tell an important fact, the SDS errors are between user gateways and the machines where the phones are resilient on.

XXXXXX is configured on node1 with resiliency on node2 and the SDS is from 1 to 2.

The call forward number in my example is indeed on another node (it's a speedcall for nupoint) however the SDS errors also happen with other numbers, mobile phones etc.

[johnkeri]

Welcome to the world of data sharing networks.
Just to avoid simple causes, please verify that your cluster elements are programmed with the necessary Feature DNs.
- also verify that the Feature access codes are programmed and shared
After that it is a simple chase of logic.
Note where the phone is programmed and resilient to.
Note the destination of the call forward.
The SDS error specifies the system that can not update to that data, so go into that system and start at the maintenance command 'Locate number DN'
- does it exist, can it be a forward destination, why would this system has to know about that call forward to begin with
Always remember the 'SDS form sharing' form that defines what is shared and how.
- for resiliency it is always (almost) the resilient pair

In later releases SDS errors are retried automatically, still suggest checking the top box and Retry.
- once you solved the cause of the errors they will resolve and update

[Ronan]

I'm in SDS land since I started Mitel (and telephony) in January 2014, and I thought I had a grip on things. I even dabble in SDS debug and messing with some database entries (carefully).

But here I'm stumped. One of the problems is that we use 3 ISS machines to make all our network (40+ ICPs) resilient. The issue is that with the default database dimensions we're hitting the limits for some tables, like DSS busy lamps, or call history, on the resilient ISS. My bosses don't want to mess with changing the dimensions so I just stopped sharing some stuff.

Call forward though, I want that to be resilient.

[johnkeri]

Call forward and other resiliency features are shared on the Resilient pair level.
This simply means that no other system needs updating than the secondary controller.
- we assume that the resiliency is working and no fault in configuration
The only question is the forward destination: Is it a valid call forward destination in the secondary system?
- my favorite command: Locate Number <DN>

Note:
- if the SDS errors (for this specific scenario) refer to anything else than the secondary controller, then the question is totally different
- if the COS for example is not shared and no forward allowed on the secondary system, or the destination is not valid because of the COS configuration of that DN, then that has to be corrected

PS: understand that you are more familiar with SDS than most others, but they might read these post as well.

[Ronan]

OK I finally figured this one out.

By carefully looking at logs and SDS errors I realized that one of them was critical, mentioning that there was no more room for Call History Records.

A default database can only have 56000 entries, and even with database resizing it only goes up to 65000. The default number of Call History Records is 20 for each phone. So without change you hit a limit at 2800 phones.

I reduced Call History Records to 10 by default, 10 or 0 for all phones (lots of work) and now all is OK.

Ronan

[august]

From Mitel:

Summary
SDS fails to propagate a call forwarding change for a non-prime multicall to the resilient controller
Question
Why does SDS fail to propagate a call forwarding change for a non-prime multicall to the resilient controller ?
Answer
Non-prime multicalls use Class of Service 1. Check COS 1 on the resilient controller to ensure Call Forwarding Internal and External are enabled.

[Ronan]

Yes, this is kind of a problem for us, as we made a point of never using COS 1 and wanted to keep it as a reference.

That is the reason for some of the SDS errors, but not the majority, I thought at the time that the cause was the same. The main problem was that phones were simply unknown by the resilient controller that wouldn't add them because of the Call History Records problem.