cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11112
Views
0
Helpful
71
Replies

3 Second Delay in Audio

mpaul
Level 1
Level 1

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.

71 Replies 71

If Cisco identified this as a bug, and fixed it with the T017 load, then the load should be made available without needing a tac case.

Has anyone else experienced these issues after upgrading to phone 7.1.1 or later. We still get the issue and have upgraded to 7.1.2 and 4.02aSR1a on the CCM's.

Yes as a matter of fact we are. I did upgrade to 7.1.2 phone load. I am actually on 4.01 call manager. This one is completely baffeling me as well. What I am going to try to do is take off the auto qos and see what happens

I'll join the growing number of people suffering from this issue. Here is my environment

Dual 6509 at the core

Multiple 3750 floor switches

Dual Servers with CCM 4.0(2a)sr1a at HO Site

500 x 7940 phones with firware version 7.1(1.0)

Single Server at Disaster Recovery Site with CCM 4.0(2a)sr1a

DR Site linked to HO site via 4Mb pipe

Packetshaper on Egress WAN port from HO Site

We still have the issue but we have a workaround. The workaround invovles blocking traffic from our DR CCM for TCP port 8002. The minute I unblock this traffic the 3+ second delay in dial tone/audio path re-occurs.

Hopefully this info might help in isolating the real culprit

More information

I've just shown the issue to our engineer and he is baffled as to why blocking TCP 8002 from our remote subscriber should stop the issue.

My question to all other's with the problem is how many subscribers do you have and are any remote from your publisher?

interesting enough, we have a remote subscriber that is on a different network. The city has a fiber campus enivronment. I did notice that this delay is there regardless of the server they are homed too. The interesting thing is when you make a call.. look at your timer. I noticed that the final call setup does not take place for a couple a seconds when the speaker button or handset is lifted. If you speak once the counter reads "00" you are fine. It is almost as if there is an ack that is not recieved in call setup

Do you have the means of blocking specific TCP ports to your remote subscriber?

All our phones are homed to the local subscriber. The DR subscriber is to cover main site outage so it currently is idle

We fixed this issue by upgrading the phones to P00307010200, changing the H323 FastStart to True in the CCM Service Parameters and adding the call start fast command on the gateway under the h323 voice class

voice class h323 1

h225 timeout tcp establish 3

call start fast

We fixed this issue by upgrading the phones to P00307010200, changing the H323 FastStart to True in the CCM Service Parameters and adding the call start fast command on the gateway under the h323 voice class

voice class h323 1

h225 timeout tcp establish 3

call start fast

We've had similar problems since upgrading to 3.3(4)sr2. Have tried different phone loads, including T017 from TAC. Still get an intermittent delay. Also getting same delay when, for example, a user picks up the handset and presses the 'more' softkey. It sometimes takes approx 2 secs before further softkeys are displayed. Same delay with call transfers too. All intermittent and on different phone loads.

Anyone encountered anything similar?

jim.rowlan
Level 1
Level 1

Don't know if this helps, but I had a couple phones do this right after a new installation. I found that the users had connected a headset that was not compatable with Cisco IP Phones. The odd thing was that it wasn't all the time. In fact, one user used his old headset for 3-4 days and it worked fine. All of a sudden it quit working. We replaced the headset with a plantronics and the problem went away.

We have a similar issue with a client as well. CM 4.0.2sr2a with 7.2.2 load. Interestingly enough when the phones are homed to the publisher the delay does not occur, I set up 2 device pools, one to register phones to Pub and one to register to Sub. All phones registered to Publisher do not exhibit delay while phones registered to Subscriber phones do. Cisco case is open and I am waiting for TAC to research.Wil post if i hear anything.