Hey Syquest...

[jinxs]

I need some help...I have a Merlin Magix R4 with a PRI. The PRI has been up and running for 5 years without a hitch. No problems at all. All of a sudden, the customer is stating that "sometimes" when they make an outgoing call, they get the Warble tone from the Magix. I have only ever experienced this one time before this and the resolution was for Verizon to build a new PRI and bring it into the building. The PRI is on a DMS-100 with the protocol set to NI1 and I verified the settings are correct with the switchman. No errors on the Physical layer of the T. No clock sync issues, minimal slips, no errored seconds, no misframes, you get the point. I have traced two phones calls, which are very identical, one completed and started to ring, the other went from a setup message being sent from the Magix to a Release Complete message from the DMS-100. I get a cause code of 96 Protocol Error - Mandatory Information Element Missing. As you can see, both setup messages are identical except for the call reference Value. What could possibly be causing this? The T is brought into the building via Fiber. Here are the traces I have recorded:

This is a call that did not complete:

** 09/23/08 15:21:50 fid: 840 SND PRI msg 0005 SETUP
Prot Disc: 8 Orig crv: 90
SETUP
IE: 04 Bearer Capability
Coding Std: CCITT
Xfr Cap: 3.1 Khz Audio
Xfr Mode: Circuit
Xfer Rate: 64Kbit
User Inf. Layer 1
Mu Law

IE: 18 Channel ID
Pref Not_D-Ch B1 Chan
Coding Std: CCITT
Type: B-Channel Units
Numbe: 17

IE: 6C Calling Party
Type: National
Plan: ISDN Rec. E.164
Presentation Ind: Allowed
Screening Ind: User Prov. Not Network Scr.
Number: xx08218
980
IE: 70 Called Party
Type Sub-Address: User Specified
Number: 1xx19211800
** 09/23/08 15:21:51 fid: 840 REC PRI msg 005A RCOMP
Prot Disc: 8 Dest crv: 90
RELease COMplete
IE: 08 Cause
Cod. Std: CCITT
Location: User
Class: Protocol Error - Mandatory IE missing
** 09/23/08 15:21:51 fid: 840 CO initiated disconnect

This is a call that did complete:

** 09/23/08 15:19:25 fid: 834 SND PRI msg 0005 SETUP
Prot Disc: 8 Orig crv: 84
SETUP
IE: 04 Bearer Capability
Coding Std: CCITT
Xfr Cap: 3.1 Khz Audio
Xfr Mode: Circuit
Xfer Rate: 64Kbit
User Inf. Layer 1
Mu Law

IE: 18 Channel ID
Pref Not_D-Ch B1 Chan
Coding Std: CCITT
Type: B-Channel Units
Numbe: 17

IE: 6C Calling Party
Type: National
Plan: ISDN Rec. E.164
Presentation Ind: Allowed
Screening Ind: User Prov. Not Network Scr.
Number: xx08218
980
IE: 70 Called Party
Type Sub-Address: User Specified
Number: 1xx19211800
** 09/23/08 15:19:25 fid: 834 REC PRI msg 0002 CPROC
Prot Disc: 8 Dest crv: 84
CALL PROCeding
IE: 18 Channel ID
Excl Not_D-Ch B1 Chan
Coding Std: CCITT
Type: B-Channel Units
Numbe: 17

** 09/23/08 15:19:27 fid: 834 REC PRI msg 0001 ALERT
Prot Disc: 8 Dest crv: 84
ALERTing
IE: 1E Progress Indicator
Coding Std: CCITT
Location: User
Prog Desc: Inband Treatment Applied

** 09/23/08 15:19:35 fid: 834 SND PRI msg 0045 DISC
Prot Disc: 8 Orig crv: 84
DISConnect
IE: 08 Cause
Cod. Std: CCITT
Location: User
Class: Normal - Normal Clearing
** 09/23/08 15:19:35 fid: 834 REC PRI msg 004D REL
Prot Disc: 8 Dest crv: 84
RELease
** 09/23/08 15:19:35 fid: 834 SND PRI msg 005A RCOMP
Prot Disc: 8 Orig crv: 84
RELease COMplete


Any Help Would be Greatly Appreciated!!!! Thank You in Advance.

 

[MrTelecom1]

You collected this data with TRACE?
It looks different than what I normally use
what command line entries were used?

MrTelecom1
Re-Living the AT&T/Lucent/Avaya issues since 1979!

 

[jinxs]

I used "trace prigon 1". Then you can translate the data by using the Pri icon on the upper right corner of the screen. Make sure you you save the trace file as a .log file. If you don't, winspm will not open the file.

A.J. Wiesner
AT&D Communications

 

[jinxs]

btw, I replaced the digits in the outgoing number with two xx's.

 

[MrTelecom1]

Kool, thank you ..
I am so accustomed to looking at it raw ....

I hadn't seen a processed file in 10 years it seems!


MrTelecom1
Re-Living the AT&T/Lucent/Avaya issues since 1979!

 

[SYQUEST]

Even though you said the DS1 is clean with no alarms, what about the Magix? Are there any Error Codes at all in the system stack? After reading thru your trace printout, I would suspect something in the Magix might be causing this problem.

Did you perform any tests on the 100D module?

This is the first time I have seen a trace printout for the Legend/Magix -very interesting!

....JIM....

 

[jinxs]

Thank you so much for responding...No errors to speak of on the Magix itself. As of yesterday there were no permanent or transient errors. I never did a Board Controller test on the original DCD Card. Still no errors on the T itself as well. We just replaced the 100DCD card and the processor yesterday morning and they are still having the same issues at hand. Imagine my amazement when I found out i didn't have to read through the Octets to see what is actually going on. I made my job that much easier. I didn't have to spend an hour translating it. The only thing that we have discovered is that there seems to be more trouble on the Polycoms (analog) phones than the MLX and TDL phones. Yet, there are still trouble reports from the TDL and MLX phones. I am thinking that there are more critical calls being made from the Polycoms and that they are noticed more often. Even though in the setup message, the Analog setup message is sent out as a 3.1 khz call and the MLX and TDL calls in the setup message are a Voice Call. Any other thoughts?

A.J. Wiesner
AT&D Communications

 

[SYQUEST]

Is this condition random and intermittent? Same stations or random stations and do the sets with displays show anything odd when placing a call? Also, when you place test calls, are you watching the LEDs on the 100DCD module? When placing a test call, if the yellow LED does not lite and you get error tone, that usually indicates the call never got a BCH or it was denied.

Has anything been changed around the Magix, electrically? How is the box bonded and grounded? Could it be some type of interference causing these problems? What is the condition of the AC power receptacles? Power disturbances can cause these types of problems. Especially if everything has been working OK, and all of a sudden the client starts to have weird things happening.

Hope this helps!

....JIM....

 

[MrTelecom1]

Look at your error log before and after the card changes.
Any "same differences" there?
Any interrupt issues the processor doesn't seem to be able to rectify from another module?

On another note, is there a 3150 or other CSU attached externally? ....and is the CSU in the 100 DCD also on?
Ya see where I was goin there I guess.... Just Checkin!



MrTelecom1
Re-Living the AT&T/Lucent/Avaya issues since 1979!

 

[jinxs]

To answer all the questions in order:

The condition is random, as from the error log, we dialed the same number actually 5 times in a row. 4 calls proceeded to ring, 1 call failed. The calls are to random numbers as well, such as 1800, 1xxx, and xxx(local calls).

As far as the stations, most of the complaints are coming from the Polycoms. But there are complaints from Various other users as well. There are over 120 phones in this building, so the complaints are varied.

I can't say what the display does say because it never happened when I was onsite or the LEC for that matter. That is something to look into if I can get the customer to keep a close eye on her display for me.

As far as the LED, that activity light is always on when I am there. Then again there are no pool busy errors in the error log. But I would need to go in early and hopefully find a call that fails to do that.

As far as electrically, all the cabinets are grounded to building steel and all three cabinets are plugged into an APC SU2200. Enough to handle all three cabinets. All though, a good point to be raised is I never did unplug the UPS while trying to make a call. Could be that the UPS's batteries are wearing down.

Again, no errors at all in the error log except for the power up cold start and board renumber from when I did the board swaps the other day.

We are using the internal CSU on the 100dcd, not an external CSU. Good thought though.

My customer sent me another log yesterday with a complaint of the "warble tone" again. After analyzing it I discovered that the customer dialed a long distance number with 12 digits. There was an extra digit on the end. So I am wondering if some of these calls are just fat fingered. I am advising my customer to start to practice dialing the number with the pound sign at the end. Though in the trap above the calls were on the money.

Oh, and for all you Avaya Business Partners out there. I went to my Avaya Distributor the other day to ask about the issue. The answer I got was is that because it's a Magix using NI1. I asked about the possibility of being escalated to Tier 3 and I got a big ol' NO. I would have to go through the TSO and there is now a minimum $600 charge for Tier 3 support. No more freebies on the Magix. From my understanding, there will be no more Tier 3 support at all after March of next year. Sigh, I just wish they could have done a R5 Magix with NI2 support before they did the end of sale. Damn Marketing Department.

A.J. Wiesner

 

[SYQUEST]

That would be a good idea to check and test the SU2200 battery status. See the LED display on the front top. That unit has a simple test mode when on-line. Just press and release the large ON/TEST button and the unit should go thru a load test on batteries, then back to utility.

One other item, on the SU2200 and all APC UPS there is a screw on the back marked "TVSS", this should be connected with a #12 or #10 AWG wire to your Ground Bus Terminal Block where the Magix has its connected. Make sure the Ground Lead connections are TIGHT! This will insure all those items are at the same equipment ground level.

You might also check the "building steel" and make sure it is connected (BONDED) properly to the MAIN UTILITY SERVICE GROUND.

Improper bonding/grounding at any of those levels can and will affect Power Quality!

....JIM....