We have a RingCentral Polycom VVX series VOIP phone behind a Cisco ASA 5506 that will provision, work for about five minutes, go off-line for 20 minutes then reconnect and continue to work unless powered down. The problem can be duplicated and happens at multiple sites with the same configuration.

A review of the packet capture shows that the system disconnects when there are a series of duplicate ACK followed by duplicate retransmissions. After about 20 minutes a RST is sent and all is well.

This is the filtered capture from power on until reset -- phone is at and RingCentral server is at Any thoughts on problem and solution?

packet capture

  • 1
    What makes you think it's the ASA? Did you check the ASA logs? Troubleshooting your Polycom is, sadly, off-topic.
    – Ron Trunk
    Apr 19, 2018 at 18:27
  • Thank you Ron -- nothing unusual in ASA logs. Problem arose when ASAs were upgraded from the 5505 to the 5506 models. Same phones behind 5505 work fine, Cisco phones behind 5506 work fine, different service with same phones behind 5506 work fine. Looking for insight into packet traffic which seems to correspond with the loss of connectivity.
    – opus
    Apr 19, 2018 at 21:13
  • 2
    Where was the capture taken ? If on the inside of the ASA, can you also get a simultaneous capture on the outside? What is the software version on the 5505 and on the 5506? Please include their (sanitized) config in the question.
    – hertitu
    Apr 19, 2018 at 21:57
  • As @hertitu said, capture from inside and outside, and from the CM if you can. This looks like a packet is being dropped. Used to see this from time to time in the days of T1's -- certain bit patterns cause an error that kills that specific packet. (very hard to debug, even harder to get a field tech to understand)
    – Ricky
    Apr 19, 2018 at 23:14
  • Hertitu / Ricky, thank you for the feedback. Initial capture was taken from the ingress / inside interface of the ASA. Completed capture from the egress / outside interface ASA and found that the packets in question are being dropped by the ASA. Using the show asp drop command lists the dropped packets. We will troubleshoot the dropped packets which are causing the VOIP timeout. Thank you for your assistance.
    – opus
    Apr 22, 2018 at 15:06

1 Answer 1


I see that when the traffic goes south, the TSval of the packets rolls over the 2^32 mark and starts again at 0, but the ASA is ACKing back a TSecr of a very high number. It looks like you were hitting Cisco bug ID CSCuq80704. You were running 9.6(2), which was an affected version, and 9.8(2) was a fixed version.


  • Thank you for the follow-up and identifying the Cisco bug.
    – opus
    May 12, 2018 at 2:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.