Voice drops for five to ten seconds during calls

Unanswered Question
Dec 15th, 2009
User Badges:

Hello, thank you for reading my question. I am at wits end!


My company uses Cisco VoIP for our phones, and one such phone is our primary conference phone, a Cisco 7937. If we are on a call that lasts for any extended period of time (45 minutes to an hour) sometime during that call inbound voice will drop. Not just get quiet or choppy, but completely drop. Here is what I have tried so far, and then I will get into more anecdotal symptoms.


Intitially we were using a Cisco 7936, when this error started happening we switched that out with a 7937, no resolution.

We switched cables

We switched ports

We switched switches

We ran a packet capture, and noticed no dropped packets

While pinging the phone, response time is 1-3 ms


So all of the so called basic things have been done as far as I can tell. I am not telephony expert by a long shot (I do databases and application support) so the more advanced options for trouble shooting that you fine people may be aware of are not in my radar. Again the call does not drop completely, it only seems that inbound voice is dropped. Those on the other end do not seem to complain about not being able to hear us so it seems to not be both ways (of course they may just assume it is on their end and not mention it) but all evidence points to inbound only.


It /may/ only be when we are using Cisco MeetingPlace Express but I can not be sure if that is a variable or a constant.


Sorry for the lack of information, as I said not a phone expert but would appreciate any help you could offer

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
asandborgh Wed, 12/16/2009 - 05:22
User Badges:
  • Silver, 250 points or more

Cody,


Have you tried setting the Ethernet port that the phone is on so it has no data VLAN, only voice?


Just a thought.....



Art

roberttimm Tue, 01/05/2010 - 09:11
User Badges:

Have you received a resolution to this yet? I'm having the same issue with 8 different

7937s at a client site.

roberttimm Mon, 01/11/2010 - 16:04
User Badges:

It appears that simply removing the access vlan from the swithport configuration (and leaving in the voice vlan command) fixed the issue. I was able reproduce the problem on demand by simply adding the “switchport access vlan” command back in the config and bouncing the port on the switch. We tested its multiple times and that appears to be controlling it. As soon as I add the command back into the switch and we start a new call, I can watch the “Rcvr Lost Packets” increment steadily within about 30 seconds or so, when I remove it we can keep calls up indefinitely without a single packet drop.

Oddly enough simply adding the access vlan command without the voice vlan command did not fix the problem, it was only when i left the voice vlan and removed the access vlan that it worked

Arturo Alejandr... Tue, 01/11/2011 - 07:17
User Badges:

I have the same issue,



we got almost 30 (7937G) and last week begun this issue.



I double checked the L1 and L2,


I hooked the 7937  in switch WS-C3560-24PS and 7962 too


upgraded the firmware from 1.3(4) to 1.4(3)



I changed config on port


interface FastEthernet0/13
switchport voice vlan 49
end


and


interface FastEthernet0/13
switchport voice vlan 49
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape  10  0  0  0
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
no cdp enable
spanning-tree portfast
end


and multiple configs, but the problem persist.


Someone has resolved his issue, please comment


thanks,

Alex

Arturo Alejandr... Wed, 01/26/2011 - 14:15
User Badges:

Hello



I resolved the issue.



we put an sniffer and saw a lot of packets from IP phones 6900 ... so we decided put the 7937s in a new vlan...


this resolved the issue.



Hope this be useful
MHyperion Mon, 07/14/2014 - 07:25
User Badges:

I have encountered this issue with CUCM 8.6.2 and 7937 phones. Phones have been working fine for months and suddenly people started complaining.

I can confirm that removing the access vlan from the switchport configuration (and leaving in the voice vlan command) fixed the issue.

Actions

This Discussion

Related Content