3 Second Delay in Audio

[mpaul]

I have a Call Manager 4.01 Sr1a implementation with approximately 55 7940/7960 IP Phones. They are connected with 2 3560 48 port inline power phones, a 3550 24 port and then a 3750 24 Port Gigabit switch. I have a voice and data vlan with all the voice servers and phones in the voice vlan. I recently upgraded to the 6.05 firmware load on the phone and noticed a strange thing. For off-net and on-net calls sometimes, maybe 3 out of 10 calls users will hear a delay in the audio. Once a call is established you try to speak and hear nothing for 3 seconds. After the 3 seconds you can hear the other caller. Some delay in the RTP stream. I've opened a TAC case and they helped me take the firmware back to 6.04 but I am still hearing the same delays. They've wanted me to gather packet traces but since this is so random it is difficult to track down. I essentially have to do a port span and be right at the phone to capture the traces correctly. Wondering if anybody has seen this before?

I've swapped switch ports, ethernet cables, phones. I'm using auto qos voip cisco-phone on the switch ports for the QOS features. There's no inter-vlan routing going on for the voice traffic.

The switches are in a hub-and-spoke design with all the switches hanging off the gigabit switch. They're uplinked with each other via copper gigabit.

[rvincent]

I'd like to make sure I'm understanding this:

The latest 7.1 phone load on a 4.0 cm has eliminated the audio delay. But it is casuing other problems with 3.3 cm even though it says it works with 3.3 cm.

The special T017 load with 3.3 cm has eliminated the audio delay without causing any other problems.

Have I got that right?

Thanks

Rob

[tavery2000]

Does anyone have expirence with 7.0 phone load and 7914 side cards with CCM 4.0.2 ?

Thanks

Tom

[jeffkelso]

You must update the 7914 firmware when you upgrade the 7940/7960 firmware.

[jerake]

rvincent:

That is what I am experiencing, yes, you've got it right.

The fact that it says 7.1.1 allegedly works with 3.3 was the first thought that came to mind when I started experiencing problems.

TMH

[rvincent]

I'm having the same problem with a 3.3.4 customer. Has the P0030600T017 load you got from tac resolved the delay & your freezing?

thanks

Rob

[togi]

Rob,

Sorry about the delay but now I'm having some problems with the TFTP server serving out that darned version of the FW. Attempting to have a specialist come out soon and fix that, so I can try to fix the FW issue. Stay tuned.

T

[jerake]

Yes, the P0030600T017 load fixed both the internal echo/delayed audio *and* the freezing; I'm very pleased with it. We've had some other internal echo issues, but that's because of a bandwith "bottleneck" issue we have between two of our locations.

TMH

[rvincent]

thanks

i've just gotten the load from tac and will be giving it a shot on a few phones as a first step. if that resolves issue, i'll use it for all phones

Rob

[jeffkelso]

I loaded the 7.1.1 firmware on Friday. Everything seems to be cleared up and running great. However, I am on CallManager 4.0(2a). I have had no new issues.

[rvincent]

I also loaded the 7.1.1. fw on a 4.0 call mgr today and am hoping for the same "no issue" result.

[togi]

Rob,

I've loaded the 6.0(T0.17) load onto certain 7940/60 phones and it seems to be working with my 3.3(3)sr4a system. More to come but haven't had ANY problems this morning with 3-5 second delay.

T

[dgahm]

I have been following this thread with interest. This seems to be pretty widespread, but I am a bit skeptical that it is really a bug. I have 4 clusters all running 3.3.3 SR4A with about 1500 IP phones (6.0.5), and another 500 plus analog ports. This covers 46 sites in 2 states, includes the full gamut of gateways, routers, switches, yet I have only once seen a similar problem with one phone. In that case a Sniffer showed the Call Manager subscriber delaying the audio cutthrough command. I configured the phone to register with a different subscriber, and the problem never came back.

I guess I should just count my blessings, but it doesn't make sense. What am I missing here?

[rvincent]

You are right. Obviously can't be happening on every site. I have many customers not experiencing any audio delay.

But the last 2 installs are both experiencing it.

The first is 4.0 cm and the problem started right away. The 7.1.1 load was put on a few phones and those are not having any delay. The load will be added systemwide this weekend.

The second site is a 3.3.4 cm. I've put the 6.0(T017) on a few phones and am awaiting feedback.

Rob

[jerake]

I have a 3.3(4)sr2 cluster, just one, that has 600+ IP phones on it...I happened to notice the problem one day while calling one of our other locations (three buildings separated by fiber, one CCM in each location, but they are in one cluster because of the high-speed links). We were using the 6.0.5 load. A few weeks later I was at one of our PC help desks and one of the techs mentioned he had just had the same delayed audio problem. I then started asking my "chronic" users if they'd ever had anything happen like that, and they all reported back that they had...but it was completely random. So it was happening, just not being reported because, I suppose, it was so random.

I was also skeptical that it was a bug at first, but the T017 load has eliminated the problem for us.

TMH

[dugrant]

The problem you guys are running into is probably CSCef07550, which is fixed in P0030600T017.

CSCef07550: Audio resume after hold sometimes takes 5 - 7 seconds

Although the title of the bug indicates the problem was found resuming held calls, the root cause was in the tcp-layer and therefore shouldnt make a difference whether its a resume or new call, conf, etc (as long as the media stream is being setup).

The only way to get P0030600T017 is to open a TAC case.