Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

MGCP Delayed Audio at branch location

We have one location that is complaining that when making or receiving a call, when answered, there is no audio for about 3-5 seconds. This happens on random calls throughout the day and extremely inconsistently. This can happen with calls onsite onnet. So phone A dials phone B and both are located and registered to the local branch location. When phone B answers, neither hear audio for about 3-5 seconds. I'm thinking this has to do with call setup packets between the phones and the remote call manager server they are registered to. However, bandwidth utilization at the site is low so contention shouldn't be an issue. This is the only site out of hundreds that have this issue which leads me to believe it is either local to the data circuit or the router/switch config. Has anyone else dealt with similar experiences?

Weird issue, could you tell

Weird issue, could you tell us what call control - CUCM/CME, version, phones, firmware version? Is this issue happening on phones on the same switch?

Please rate useful posts.
New Member

MGCP gateway, SCCP phones.

MGCP gateway, SCCP phones. CUCM ver 7.1.5 but will be moving to 9.1 and going to a SIP gateway.


Phones are 79xx series phones. Latest firmware supported for 7.1.5.


Yes, the issue occurs on-net even within the same switch.


I have a TAC case open and based on the logs, he thinks the call setup request is being sent on the data vlan and the phone is not responding, then timing out.  CUCM re-sends the request and then the phone responds and sets up the RTP stream.  


We've had bad luck doing wireshark captures to truly lock down the issue.


Sorry for the delay in response.

CreatePlease to create content