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

Hi All, I am new here and found this site looking for info on how one AMI/SF T1 would behave in a VoIP environment where all other T1s are B8ZS. We have an Avaya IPO 400x series and 4 locations connected by T1s. We have had a problem with dropped calls and I believe that the AMI circuit is the cause due to the fact that all calls that come into the location with the AMI circuis and are transferred to a spoke location drop 100% of the time. This doesn't occur when the call is transferred to the hub site, even if the hub then transfers to another spoke. I am having the AMI circuit replaced with a B8ZS circuit on Monday 3/31, and I will have my answer at that time, but I am documenting the issue as we have had this problem for nearly a year and my BP said that the AMI circuit shouldn't be causing problems. Can anyone point me to a white paper or some other documentation that will show that the mix of linecoding can cause serious problems?

If the circuit is designed for and optioned AMI all the way through it should work find. If your equipment calls for B8ZS and you have AMI than it won't. That simple.

Hi justbill. The AMI circuit was installed years ago, before I came to work here, and was intended for use with non-voice data. I am not certain that the Avaya equipment has a specification for B8ZS, but given my BPs overall incompetence, I have no intention of asking, I can find out. The BP didn't even get the original config right, I had a problem for the first 2 months where you would try to call or transfer to a spoke and get and "incompatible" message on the phone screen. The BP spent those 2 months blaming my network and not looking at their config. I found an Avaya forum and they had it solved in one day. So I have no faith in the BP. I was thrown into this by default, and we have combed the network and the IPO configs to the point of absurdity. We've upgraded routers and switches, implemented QoS, combed over physical wiring, all to no avail. We use very little bandwidth overall, so no congestion, no jitter, nearly no packet loss, etc. I have seen several things that indicate that if the signal traverses a B8ZS circuit, then hits an AMI circuit, and then goes to another B8ZS, that this can cause problems. The moment of truth is 10AM Monday morning. IF it solves the problem, I have a little gloating to do over the BP. If it doesn't, well...

I am no VoIP expert, by any stretch of the imagination. I do understand T-1's. If you come out of a switch optioned either it has to be the same on the other end, you can't change in mid stream. You can go (Network wise) from a B8ZS optioned switch into another B8Zs optioned switch out of the switch AMI to another optioned AMI and out B8ZS. It's what happens end to end that matters, what goes on internal to the switch really doesn't matter. Again, I'm not talking Telco to a PBX I'm talking Telco to Telco. So I'm not sure what you mean by going from a B8ZS circuit to an AMI circuit. If it's internal to the switch it doesn't matter.

We've got some good folks here that maybe can make more sense of what I'm trying to convey.

justbill, I am probably not making myself very clear on that. The calls come into the PRI, which is B8ZS, the IPO forwards the call based on the call route for the number called. In this case if the caller calls the number specific to the spoke named Hwy, which has an AMI circuit, then the voice data is going from the B8ZS PRI across the AMI circuit to the Hwy. No problem there. But if the caller wants a different spoke than the one they actually called, and the Hwy transfers to that spoke directly, the traffic is then going back to a B8ZS circuit, and the call will drop 100% of the time. If I am not mistaken, that means that it goes from B8ZS to AMI then back to B8ZS. Incidentally, if the Hwy transfers the call back to the hub, and then the hub transfers to the requested spoke, the calls don't drop. This is the workaround we are using for now. I hope that makes sense and if I'm wrong hopefully someone will correct me

Thanks, Dawn

That’s not an entirely true statement… I’ve have little experience with VoIP but in the TMD world, it’s not uncommon for carriers to be “back to backed” with AMI & B8ZS carrier facilities.

For your situation, if all is configured/optioned correctly there should be no “issues.” The only caveat to this is if “clear channel,” 64 Kb, or “switched 56Kb” is in the mix via optioning for the traffic between offices. In which case the signal would never survived on the AMI carrier to start with. If that was introduced to your “spoke” location I could see how a call could be immediately dropped.

That made me dizzy…

Honestly, I don’t think your AMI T1 could or would be causing your dropped transferred calls problems. The T1 is just a pipe. It seems to me as you describe it your AMI T1 is capable of handling the signaling and voice traffic in and out of the Hwy spoke in all other cases. I don’t see where it would be intruding a problem on transfers back to “hub.”

Well I guess you could say I'm grasping at straws at this point. This has been going on for almost a year and I am desperate to fix it. And I should tell you that the calls don't drop immediately, they stay connected from 30 seconds up to 2 minutes. I have had considerable help from an Avaya forum but we just can't find the problem. Interestingly though we have another spoke that was on AMI and appears to have had the same problem, which appears to have been resolved by conversion to b8zs. I say appears because I hadn't refined the circumstances of the drops until after I had had it converted. I am kicking myself for it now though.

I should also say that there is a huge amount of detail that I haven't posted here. One important thing though is that there is always an error with a drop, and it is always the same. I'm on my phone right now, but when I get home I will post that error and what led me to this point.

Here is my persistent error (call information removed):

176379090mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...[call information]…
176379091mS CD: CALL: 40.64.1 Deleted
176379095mS CMLineTx: v=40
CMReleaseComp
Line: type=IPLine 40 Call: lid=40 id=64 in=1
Cause=2, No route to specific transit network/(5ESS)Calling party off hold

What led me to this point was looking at the call origin rather than the call destination (our orignal heavy focus). Without exception, the dropped calls originate at an AMI spoke and are transferrred directly to a B8ZS spoke, bypassing the hub; it always delivers the error above. We have funny little clusters of the same caller being dropped over and over, and that is obviously because they were always calling back to the same number, and always being directly transferred to the same destination. By transferring the call the to hub first, then transferring it to a spoke destination, the calls remian connected, otherise they all drop in that 30 second to 2 minute timeframe. My study of the error (and there is much more if you look at the whole call from origin) shows me that there are master and slave entities which have to send acks back and forth for the call to be viable, and it appears that somhow that process is breaking down and an ack is not being passed in a timely fasion (I think, this is outside my field of expertise). Attempts to learn more about the second portion of the error, the "no route to specific transit network", have been fruitless. I am prepared to do packet analysis if the new circuit does not solve the problem, but I am unpracticed at that particular skill.