Voice quality issue after replacement of AdTran 924e

[pmwrightjr]

I have a PRI delivered on fiber via an AdTran 924e.  Last Thursday, after having been installed in October of last year or so, the AdTran 924e shut down abruptly.  A new unit was installed by our local carrier and ever since then, we have had intermittent issues with voice quality that sound very much like packet drops.  The architecture is as follows:    <carrier network> single-mode fiber > CPE > AdTran 924e > PRI > Cisco 2811 > Cisco CallManager.

The carrier is insisting that nothing can be done on their end but I have been over and over our CallManager system and we have crystal-clear audio on all calls within our network.  The only problem calls are those that go out to the PSTN over this PRI and the problems started with the failure and subsequent replacement of the AdTran. I have looked in great detail at the 2811 router and PRI card and find nothing to suggest a cause.  The PRI interface is completely clean with no errors of any kind and the CallManager system itself is showing no evidence of any problems.

One of the carrier's technicians suggested that there are some settings in the AdTran that can, if not set correctly, result in this sort of thing but the problem is not getting solved and I'm caught in the middle of a multi-vendor squabble about where the problem is.  So my question is... how can I isolate the cause of these voice quality issues?  Secondarily, are there peculiarities of running an AdTran PRI against a Cisco router in terms of the setup (e.g. should the clock be set in a certain way on the Cisco side)?  Anything I could suggest to our carrier for what to look for (it's a large multinational but I'm underwhelmed at this point with their expertise in the equipment they operate).

Any advice will be helpful!

thanks,

paul

[Anonymous]

Hello Paul,

The connection between the CPE and Adtran is that a 10/100 Ethernet or T1?

Why can't you bypass the Adtran all together and go straight from the CPE to the 2811?

[Anonymous · Accepted solution]

The Adtran has a feature called VQM (voice quality monitoring) which will monitor RTP traffic and hopefully assist in finding the issue.

You can find more information here:

If the Adtran was provided by the provider there is a good chance they didn't give you access to the device.

Here is a document on how to bypass the passwords:

Good luck

[pmwrightjr]

Good morning!  Thanks for the reply on this holiday morning...  the connection between the AdTran and the CPE is 10/100 Ethernet.  The connection comes into the building as single-mode fiber which goes (IIRC) to a Cisco 3400 Metro Ethernet box which then goes to the AdTran which breaks out the PRI and two data connections.

Because of the converged architecture, I don't believe I can go directly to the CPE.  That was not always the case - when all we had was a PRI coming in via fiber, that was what we did but now I believe the actual delivery mechanism is Metro Ethernet over fiber.

paul

[Anonymous]

OK that make sense since the voice and data are coming out of the same line.

The Cisco 2811 can probably handle it but the provider will want to have control.

[pmwrightjr]

You're right, the AdTran is provided by the carrier and I don't have login access to it, although I do have physical access.

However, the links you provided are right on target so I'm going to look at them right now.  What I am trying to understand is how to establish where the problem is in a case like this - when the PRI is reported as clean by the Cisco router and when the CallManager system works fine in all calls within our network but has these ghastly drops of audio during phone calls to the PSTN, what do you do?  Presumably, the carrier is monitoring VQM and they are claiming they don't see anything.

Well, let me update that with late-breaking news.... the carrier just called back and they found unidirectional packet loss caused by....... ta-dah!!!  interface configuration between the AdTran and the metro Ethernet switch (mis-matched duplex due to failure to auto-negotiate).

As I'm one of those Network Neanderthals who hard-codes every important interface, I can't say I'm terribly surprised.

paul

[Anonymous]

I was just about to suggest you run a ping from the internal network to the internet for about a minute to see if there is packet loss but I guess they found the problem.

Hopefully that takes care of the issue.

Happy 4th.

[pmwrightjr]

Thank you for your reply.  It has now been a month and there has been no recurrence of the issue so I guess the negotiation failure between the AdTran and the Cisco was the issue and now that both interfaces are hard-coded, the former stability has returned.

paul