atcomsystems.ca/forum Forums TDM Business Telephone Systems Avaya - Lucent Telephones & Systems 400x series IPO: AMI vs B8ZS in VoIP environment

Dawn

Thank you for providing us with the IPO output error message with your other important information on your symptoms. It seems that all symptoms and errors are isolated to only calls associated with your sole AMI/SF T1. If this is true, let's focus on two potential causes for the dropped calls and error messages:

1. A software programming error within the IPO, which is causing the calls being processed from the AMI/SF circuit to drop when bypassing the hub.

OR

2. Some possible rough history between AMI coded and SF framed T1 circuits and the Avaya IPO 400x series systems. This may require considering having that circuit's coding and framing updated to B8ZS/ESF to match all of your other T1s.

Like others here, I'm not an expert with VoIP or the Avaya IPOs. However, I suggest that we consider moving this thread over to our Avaya forum to get some additional input which would be more specific to your system (to include updating the title of this topic to reference the 400x series IPO).

Just let us know, and one of us would be happy to move this discussion over to Avaya. :thumb:

Dawn -

Could it just be the T-1 "Pipe" that's causing the trouble and not the line coding? Have you stress tested the AMI "T"?

If stress testing doesn't show any problems, than by all means, try to change the coding (and then retest to make sure the circuit is good in its new configuration!).


Sam

Hi guys and thanks for the welcome and assistance. I have no problem with the thread being moved over to Avaya, whatever works! In fact the AMI circuit is being disconnected and cutover to a B8ZS circuit Monday 3/31 at 10AM CDT. They are putting us on a new pair, not just moving the existing pair, so I am very hopeful.

We never did stress test the AMI circuit, just the PRI and the T1 to the site where most drops occur (numerous times), we had the occasional slip, but nothing that corresponded with drops. The reason for this was that we were never looking at the origin. Please understand that I was being led around by a BP who I have discovered is less talented than I am (not boasting, I am a rank novice in voice telephony), and it wasn't until I decided to abandon everything the BP had to say that I started focusing on the call origin, and wishing I'd done so half a year ago. Once the cutover is complete, it will take about 5 minutes to determine if the change made a difference (gotta love a 100% drop rate, it'll make it easy to determine if this worked).

-Moved to Avaya, initial posting member notified

Thanks! Dawn

Well, it was worth a try, but the drops remain after the circuit conversion to B8ZS. If anyone has any other ideas, I am all eyes...

Thanks, Dawn

Are the call failures still isolated to only calls from this "B8ZS-updated" circuit that attempt to "automatically bypass the hub site"?

With today's conversion to B8ZS coding:

1. Was the T1's framing also updated from from SF to ESF?

2. Do calls from this updated circuit that are transferred TO the hub site still process OK?

5Etek-mike, yes, the framing was also updated, I did the routers on both ends. And yes, the calls transferred to the Hub still process just fine. The situation is unchanged.

Meanwhile, here is a little more info (the Hwy & 21 references are both spokes):
I was watching system status monitor during test calls, and I hope this makes sense:

If I call the Hub, and have them transfer me to the 21 (the ususal destination for drops) I don't drop, and I can see the call in both status monitors, the Main and the 21mm.

If I call the Hwy (the originating source for all drops) and have them transfer me to the 21, not only will the call drop after about 1:30, but the call vanishes from the Hwy status screen as soon as it is picked up at the 21. It does this if transferred to the Hub too, but stays connected.

If I call the 21 and have them transfer me to either the Hwy or the Main, I can see the call in both status screens throughout the length of the call. Only at the Hwy does the call vanish upon pickup no matter where the call goes.

I might also add that if an internal user calls from the Hwy to another internal user at the 21, the call won't drop. They are incoming calls only.

Hmm Mike asked me to join in on this thread. I seem to remember some of your nightmares on another forum if this is the same Dawn.

As bad of a BP you obviously have/had, he was correct that the line coding etc should have nothing to do with your dropped calls just as you've noticed with the lack of change with the new circuit.

The problems you are having seem to be pointing back to the IP Office as the culprit. Since I haven't followed all of the previous threads please fill in some "blanks".

If I understand the situation properly, all calls come from a PRI in the "hub" then, are routed via IP lines to all of the "spokes"?

So a call is routing from a PRI on one system to another via IP line to a second system, then transfered to a third system that is connected to the original system via a different IP line.??