Dropped calls on MICS 5.0 with channelized T1 Help!! 1

[capcoms]

Customer is reporting that incoming callers are being disconnected in the middle of established calls. The trouble began early in the morning on 01/05/04. Customer has had this problem before and strangely it seems to happen on Mondays. This is a Hospital, so they are probably getting heavy call volumes on Mondays, particulary since it is the flu season. The carrier is set to send incoming calls to "most idle trunk." The carrier on 01/05/04 (afternoon) looked at their CSU on premise and said they did not see a single error. I looked at the Norstar internal CSU stats01/05/04 (evening) and did not see any errors either, but I did see the events in the system test log (below).

Note: MICS 5.0, 6 port fiber expansion (not combo), services card. The T1 is set to ESF, E&M wink, 21 channels with DID service.

Has anyone seen the Event 820 before?
Can anyone tell me what the Event 820 means in terms of
components failing if any?

In the event manual from options telecom evt 820 says "line driver problem" but the manual is dated 1994. The event is not in the 5.0 installer manual.

Could it be that my E&M channels 17,18 19,20 and 21 are receiving inbound calls after they have seen the event 265-XXX (the trunk is staying idle long enough to be most idle)?

Should I have the carrier change to ascending on incoming calls?

The EVT 265-XXX are events pertaining to T1 channels. XXX may be from 201 = channel 1 to 224 = equals channel 24

We only have 21 E&M wink trunks on the T1 circuit.

The description of Event 265 in the Norstar 5.0 installers manual says "The E&M line port did not receive an expected wink signal or delay dial signal from the far end" but the options telecom manual has a different description for this event "The network did not acknowledge the KSU request to seize the line" which probably means the same thing.


I guess that means when callers are dialing out, the system is going off-hook and is not seeing a wink back from the local carrier.

As you may notice all the 265 errors appear to be 265-217 or 218 or 219 or 220 or 221. The Norstar system is programmed to use the highest channel when extensions place outbound calls starting with channel 21 (port 221)

Following is the system test log from the Norstar telephone system

EVT265-221 S7
TIME 12/23/03 16:26

EVT820-010502S4
TIME 12/23/03 19:41

EVT820-0E0502S4
TIME 12/25/03 19:35

EVT265-219 S7
TIME 12/26/03 09:53

EVT889 S3
TIME 12/26/03 15:42

EVT820-030502S4
TIME 12/26/03 16:13

EVT265-221 S7
TIME 12/26/03 16:58

EVT820-0C0502S4
TIME 12/28/03 14:46

EVT265-221 S7
TIME 12/28/03 19:23

EVT820-131112S4
TIME 12/29/03 08:02

EVT265-219 S7
TIME 12/30/03 08:50

EVT265-219 S7
TIME 12/30/03 10:58

EVT265-221 S7
TIME 12/30/03 12:01

EVT265-219 S7
TIME 12/30/03 12:36

EVT247 S4
TIME 12/30/03 13:02

EVT265-221 S7
TIME 12/30/03 19:09

EVT265-218 S7
TIME 12/31/03 10:47

EVT889 S3
TIME 12/31/03 11:51

EVT265-221 S7
TIME 12/31/03 17:13

EVT265-217 S7
TIME 01/02/04 08:21

EVT265-220 S7 REPEAT 2 TIMES
TIME 01/02/04 15:58

EVT265-219 S7
TIME 01/05/04 08:17

EVT265-217 S7
TIME 01/05/04 12:04

EVT265-219 S7
TIME 01/05/04 13:07

EVT820-0B0502S4
TIME 01/05/04 15:03

EVT820-0B0500S4
TIME 01/05/04 15:03

EVT820-0B0502S4
TIME 01/05/04 15:03

EVT265-217 S7
TIME 01/05/04 15:33

EVT820-000502S4
TIME 01/05/04 15:57

EVT820-0B0502S4
TIME 01/05/04 16:03

EVT820-000502S4
TIME 01/05/04 17:25

Sorry for such a long post, but I wanted to include as much info as possible.

Thanks in advance

 

[LKev]

Haven/t noticed event 820 before. The only reference in my book is that it is not listed as a significant event message. Meaning it doesn/t create a restart. What it is eluding to is not described, but by your event code 265 it must go hand and hand. One most likely trips the other. I think the most important concern is the 265. I know the S7 rating is not good. An S9 is the highest severity rating. I agree with your statement about calling the carrier to change the incoming to ascending, and starting from there to see if that cures the problem. That sounds like a logical place to start.

Hope that helps

 

[cowenby]

I've seen EVT247 and EVT889 before, but can't provide any specifics, except as follows.

My reference shows EVT265 as "Network did not acknowledge the KSU request to seize the line" and suggests checking the line interface with the network to determine if it is operating correctly.

Looking at the subtype, you had 3-217's, 1-218, 6-219's, 1-220 and 6-221's. I'd guess that these relate back to specific channels. You might want to look at these channels, as you have already indicated.

EVT820 shows as "Line driver problem." The subtypes here are:
2 - EVT820-000502S4
1 - EVT820-010502S4
1 - EVT820-030502S4
4 - EVT820-0B0500S4
1 - EVT820-0C0502S4
1 - EVT820-0E0502S4
1 - EVT820-131112S4

EVT889 says "Remote access timed out waiting for a response from the parser" and suggests ensuring that the remote access dialing plan is administered properly.

EVT247 says "An invalid channel related event was received."

MTT logger and protocol analyzer traces might helpful in troubleshooting this problem.

Hope this helps a bit.

Good luck!

 

[capcoms]

Cowenby and LKev thanks for your posts. Cowenby can you suggest a good logger/analyzer. I am sure they are thousands of dollars right?