I have NEVER had problems with an activity switch, but another vendor who has a key system on a point-to-point off of one of our 2Ks claims the activity switch is causing them all sorts of problems. I do see 1 slip on the ckt during the hr of the switch, but that shouldn't cause problems. I'm not willing to use them for a clock source (6 other digital links on this PBX and no problems on any of them). Any ideas here? I'm not sure if they're just looking for someone to point their finger at....

What are the problems they're complaining about?
Do their problems only occur at 2am???
It does sound like they're grasping for excuses!

Ok, education time. I'm always willing to learn. Define 'activity switch'. I understand you have a network of pbx/key systems linked by T1/PRI's. John C. (Not Garand)

The SX2000 has redundant processors and hard drives. The system has an ACTIVE plane, and an INACTIVE plane.
By default, at 2am, an ACTIVITY SWITCH occurs, so you're running on a different "brain" on the next day.
The actual process takes about 45 minutes to complete, and the system uses conferencing circuits to make the transition seemless to anyone or anything that's currently on the phone.
The ACTIVITY SWITCH should be seemless to all of the phones and trunks, and in this case, seemless to the T! clocking.

Thank you, you even worded it so I picked it up on the 1st read-thru! NEC2400's have/had that capability, but only switched processors on command or when the active cpu failed. And I'll bet a lot of other large scale systems have the same capability. John C. (Not Garand)

Initially they were having these problems at 2am when the activity switch occurred, so I changed the activity switch to 3am, and their problems started occurring then. They will have issues like phantom calls coming in at the time of the activity switch, they claim the circuit goes down (which I don't see, although I will get SMDR logs on multiple trunks with no digits sent when they claim it goes down), and they get alarms of slips. The only thing I can say is their system is too darn sensitive to what may potentially be 1 slip (at the most!). I've even forced activity switches in the middle of the day while talking to them on that circuit - our calls stay up - (admittedly one time our call did drop - but even that time the circuit didn't drop). Duty cycle 100%, framing losses - 0, bit error rate - 0. Everything looks good.

Could it be that it only happens when going from
A to B, or from B to A???
That would point to a bad processor, which is where the clock is located.

It does happen on both planes. I have noticed that the first 7 or 8 calls that are attempted to get through to them after the activty switch fail, and all subsequent calls seem to get through just fine. There is a software log generated for each failed SMDR log but that software log only appears when Plane B is active.

The calls that fail,,,,,
Are they during the activity switch, later in the day, or both????
Are you using SMDR, or just storing it in the buffers?

The calls that fail occur after the activity switch. No matter when the calls first come in - whether it is at 3:10 or at 6:30 - the first calls that come in to each trunk usually end up not getting through (caller hears dead air) until that trunk is accessed again (trks in circular grp). SMDR logs show abandoned call on 2K trk with digits dialed, but don't show trk to other system. If there are 8 trks in the circular group there are usually 8 failed calls before the first successful call, which will come in on first trunk in grp.
SMDR used only for call acct - I'm just reading logs to help troubleshoot this.
Thanks for your help and ideas!

I'm not sure if this statement is always true (I'll have to test after another activity switch - I've already forced 2 today and don't want to push my luck)- but this might be a simpler explanation:
Indeterminate trunks aren't processing calls, idle trunks are. Once a trunk has been accessed (changing its status from indeterminate to idle) subsequent calls are fine (until the next activity switch, during which trk stats change to indeterminate again).

This may not have ANY bearing on the problem, but what is the clock level in the Mitel and what is the clock level in the problem node? Any chance the Mitel is 4 and the problem node is 3 and loses lock? John C. (Not Garand)