Activity Switch 1

[becca1jane]

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. When I check SMDR logs it looks like some of the first calls I send to them are not getting answered by the trks to their system. 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....

 

[kwbMitel]

I would change the schedule of the activity switch to a different time AND/OR day to prove out the relationship.

Might be a coincedence.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

What software version is running on the 2K and what model telephones are they using. This "first call of the day" thing sounds hauntingly familiar.

What else can you tell us about the 2K? How many per nodes, how many total DNIC instruments and if any, how many attendant consoles?

Are there any PKM modules involved or are there any PKM modules in use on the same card?

I vote with kwbMitel on this, esp. if it's happening every day or every other day (ie, can be associated with one plane). Maybe turn off the activity switch for a couple days (do not put an activity freeze on it). Don't let it run more than 3~4 days like that as you will eventually run out of resources (memory).

If you run out of things to try and if they are using DNIC sets, try turning off DNIC background diagnostics for a few days and note the result (command = back off dni & back on dni)

 

[MitelInMyBlood]

Okay, I see after morning coffee and rereading that this is a T1-extended system. What make/model of key system (not that it would matter, just curious)?

 

[becca1jane]

Activity switch was at 2am - I switched it to 3am and the problem followed. The far end has a Nortel BCM 400 - I'm routing calls there to 4 different routes depending on how they wanted to receive digits. The first few calls almost always don't get through after an activity switch - then a call or two may, and then another call may fail. So I don't think it's a sync issue - if it was I'd think once the first call got through all subsequent calls would be ok. It's almost as if I'm not getting a wink back from them. Even if I do a direct trk select on the trks over to them and dial digits right after the activity switch, I still can't get through. Another thing - once a trk has been hit (even if the call failed) next call on that trk will be successful.

 

[becca1jane]

Software on the 2K is 33.3.1.5

 

[kwbMitel]

Nasty,

I'd like to help but i think we're beyond my experience.

Your thought about wink is worth looking into or any other protocol issues. QSIG for e.g.

Good luck

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

What kind of trunks are you using, PRI or E&M?
Start type wink or immediate?

 

[becca1jane]

e&m, wink start.

 

[MitelInMyBlood]

What is the state of the trunks before you attempt a call? Idle or Indeterminate?

What happens if you man-busy the trunk group then return to service then try a call?

 

[becca1jane]

Trunks are indeterminate - because they haven't been hit since the activity switch. If I busy them out and rts, trunks obviously appear idle, but I still get the same response. A direct trunk select also gets the same response. But the second call to the same trunk always is successful.

 

[becca1jane]

MitelInMyBlood - I've been reading previous threads - looks like there have been other issues with connecting a 2K with other Nortel systems which in your words "is a veritible "cluster-#@*!" because if the span goes down the M1 trunks will not recover without human intervention to reset them." Sounds vaguely familiar....I wonder if it's a similiar issue here - I'm not convinced this is occurring due to the activity switch - they are clocking off of us, dtst shows a slip on that link when the activity switch occurs - maybe all it takes for them to see that span drop is one slip and then they have a hard time recovering? I've had other PBX's trunked back to us and no problems.

 

[MitelInMyBlood]

There is a gentleman by the name of Gene over in the Nortel forum in whom I would place the utmost faith in his opinion. If you have not already, I would post over there. From what you describe it sure does not sound like any problem on the Mitel side.

The best thing we ever did was sell off the business unit that had the Nortel 81C trunked to us. It was a freakin' nightmare. We had a full DS3 between us using identical Adtran muxes at each end and partitioning out two time slots of the DS3 for PRI trunks.

We never could get the PRIs working between us (Q.sig issues coupled with a lot of finger-pointing) and wound up configuring them for E&M, but even then it took human intervention at the Nortel side anytime there was a hiccup on the span. It indeed was an absolute cluster-#@*! on the grandest scale imaginable. However, we know beyond any shadow of a doubt that Mitel's Q.SIG works correctly with two other competing brands, one an Intertel (EADS) and the other an IPC Turret (both TDM systems).

 

[becca1jane]

Thanks - I posted on the Nortel BCM site yesterday - have rec'd one response so far - will ask the Nortel tech on the far end to verify the setting that was recommended. The guy working on the far end system is supposed to bring a similar system over here to set-up back-to-back (I assume we'll have the same issue - but at least prove to him that telco isn't involved). My vendor also offerred to let me borrow a Toshiba key system to place back-to-back with the 2K to prove to the Nortel tech that an activity switch on the Mitel does not cause problems - that should be proof positive that their finger is pointing in the wrong direction -