Call volume in and out but does not drop call 1

[cb369]

I have a Merlin Legend Release 7.0 v49.1. I am having an intermittent problem with calls loosing and then regaining volume while on a call. The call never drops just the volume cuts in and out about every 5 seconds for the duration of the call. It happens on both incoming and outgoing calls. It has happened on local and LD calls in SBC's, AT&T's, and Verizon's network.

I have an 8 channel PRI connected to the Legend. I have replaced the CSU, 100D, and upgraded the software. An SBC tech was monitoring calls at the smart jack and saw the problem coming from the CO side.

SBC has "re-engineered the circuit" and problem still persists. Of course they are not able to see any problem when they attach a protocol analyzer because the call never drops. SBC is now starting to point the fault in my equipment.

Has anyone ever seen this? Does anyone have any ideas? Please help!! Thank you. cb

 

[merlinman]

You say it's happening on Local & LD, including the PRI?

If this is failing consistantly, I would start busying out Modules (and pulling them out, 1 at a time) to see if one is a bad actor.

IF you can't isolate, let us know, and I have other ideas as well.

 

[cb369]

I am researching how to busy-out in the Legend system. I am used to the Definity systems and Legend is rather new to me.

Here is my current configuration:
0 - CKE4 CPU
1 - 408 GLM-U
2 - 008 MLX
3 - 800 GS/LS
4 - 100D
5 - 012

I am using a PRI with 10 channels (100D) for incoming and outgoing calls.

MerlinMan- do you think this could be on the PRI? Does the trunk ID always correspond with the same channel? If so then this problem is not isolated to one channel. What card/port should I busyout?

 

[merlinman]

To know the TRUNK NUMBER of the PRI, you would have to know what channels the Vendor is using.

In theory, the ports/channels are (in your t1 card) 813 - 835, with 836 as the D channel. However, since you are only using 10 channels, then you need to know just which channels the Vendor is using.

I would busy out FIRST SLOT 1, see if the trouble changes, then, if not, restore slot 1 and busy out SLOT 2 and see if it changes and then restore slot 2, and then busy out slot 3..... and continue that pattern (skipping slot 4) until I got to slot 5.

ALSO, I would label the Line ports with a unique lable to be able to KNOW what line I am using that fails.

 

[cb369]

The 800 GS/LS failed the internal loopback test:
00 00 00 00 00 00 00 04
03 03 03 03 03 03 03 03

I am having a replacement card sent to me.

The 800 GS/LS is not connected to anything. How could this be the cause of the problem?

I also found "All TTRs Unavailable" 0C03 errors that occur every morning around 3:00 am. I'm thinking this is part of daily health check or could it be an indication of the problem?

Any ideas?

 

[merlinman]

If it's not being used, the 800 MAY OR MAY NOT be causing the problem.

Instead of getting another one, I would just maintenance busy it and then physically take it out, and see if the trouble stays or goes.

PRI is usually quite reliable, and if it's having some type of problem, USUALLY you will see some type of error message.

The 3:00AM TTR issue is just as you suspect, something that happens during a nightly audit the system does.

 

[cb369]

I have a warranty replacement program where I just call for a replacement card. I'll have the card tomorrow.

I wish I could reproduce the problem so I could have an acurate test. I'll have to wait and see if the problem comes back.

 

[merlinman]

YES! - With troubleshooting - MAKING IT FAIL is the GOAL,

With installation, making it work is the goal.

Good Luck!

 

[cb369]

My vendor sent an 800 GS/LS-ID. I tried to get this card to work - replaced card (slot 03), ran renumber, and tested card - failed.

Swapped 100D to slot 03 and 800 GS/LS-ID to slot 04, ran renumber, tested both cards and they passed. Big problem, the T1 ports on the 100D showed maintn busy and was unable to restore.

Swapped cards back 800 GS/LS-ID-slot 03 and 100D-slot 04, ran renumber, tests passed. T1 ports still did not release.

Put original 800 GS/LS back in, ran renumber, and it still failed internal loopback test. Trunk ports still did not release.

Restored back up file and system came back up. 800 GS/LS still failed internal loopback test. Trunk ports available.

This darn thing is giving me a headache!! I started with very little knowledge of this system - it has decided to teach me a thing or two. I am waiting on a call back from a Legend technician. Any ideas?

 

[cb369]

By the way... nothing was/is connected to the 800 GS/LS.

 

[merlinman]

OK, I forgot to ask one VITAL question, WHAT IS THE MODEL NUMBER of the 100 D Module?

IF it is a 517 M 15, that could be the problem with PRI.

That number is on a tag on the top of the module, or, if you do an inventory, I can cross reference the HW FW numbers to what it is.

This is a very critical issue.

 

[cb369]

The 100D is hardware vintage: 2B and firmware vintage: 90

 

[merlinman]

As nearly as I can tell, that means it's a 517e15 (Or earlier), not a bad thing.

The 517M15 - Hardware 0A, Firmware 91 will not work with PRI and 016 cards in the same switch.

 

[cb369]

Per document 555-661-140 pg 4-63: you can remove and insert line/trunk and extension modules with the system power on without affecting normal call processing.

I am going to try it again, this time powering off the system and see if that makes a difference.

When I removed the card as a hot swappable it caused the 100D to fault and caused the system to do a warm restart. Maybe this caused the processor to go cookoo.

 

[merlinman]

Well, Did you busy it out first?

Bell Labs at first touted the "hot swap" feature, but as time went by, it was determined that some cards would cause problems during hot swap.

 

[cb369]

I busied out the card and then hot swapped it. The 100D showed an alarm and then the system performed a warm restart.

We are short staffed today. Hopefully I will be able to go to site tomorrow or Wednesday.

 

[cb369]

This time powered off system replaced 800 GS/LS with 800 GS/LS-ID. Powered on, performed board renumber, busy out card, ran internal loopback test, and test failed:
00 00 00 00 00 00 00 04
03 03 03 03 03 03 03 03

This time the 100D ports are still working, yeah!!

The ports for the 800 GS/LS-ID are 805-812. 812 is programmed as MOH. Removed MOH but port still shows MOH setting under status. I ran a board renumber and the MOH is still showing in the port status. Is this an indication of a problem since the programming is still showing on the status? What would happen if I removed all the trunk programming from this card?

 

[merlinman]

Is it showing that it is the MOH Port, or just the LABEL of MUSIC?

I don't think (if they are not being used) removing the TRUNK PROGRAMMING would cause any problems.

But you can do it and test it too....