UCM occasionally not sending ACK when picking up incoming call (GXP2160)


I’m new to VoIP/PBX, so please bear with me!

We recently installed a UCM6510 (firmware for our growing business replacing a purely DECT system. We have two analogue lines connected to FXO that are routed directly into a queue 6501 during office hours. The queue has two GXP2160s and one GXP2130 as static members and ~90% of calls go through fine without any problems.

However, occasionally some calls will encounter a failure where the operator picks up the ringing handset and the phone does not answer the call - it either keeps ringing or opens a new line out. If they put the phone down and pick it up again or try to press one of the flashing BLFs, the phone seems to get confused and more often than not will hang up the incoming call. Sometimes putting the handset back and lifting it again will succesfully pick up the call. Sometimes the call will get put through after waiting a few more seconds!

I have done a packet capture on both 2160s and attached one such incidence of the problem:

I have a pcap dump but am not allowed to upload as a new member.

It looks like the UCM is not promptly responding to the phone’s 200 OK with an ACK, and the phone is trying over and over until it gets a response, therefore it seemed to me like it was the UCM at fault rather than the phone, but I have yet to encounter the same issue on the 2130 (it does however handle a lot fewer calls).

We also had the problem occur once when transferring from one 2160 to the other via blind transfer; on that occasion the receiving phone did get an ACK after a few retries and seemed to connect the call.

Since all our incoming calls are currently FXO (in the UK) we have preferred codec set to PCMA throughout the system.

I’m currently running a packet capture on the UCM itself, waiting for the problem to reoccur again. The phones are on VLAN 20 with OUI tagging from a Netgear L2 switch, with the passthrough going to user PCs on VLAN 1.


remove all codecs and leave only PCMU/A and test


I agree but leave PCMA not PCMU


Well PCMU/A based on where you are obviously, I thought it was in the U.S.


Thanks for the lightning fast replies. I’ve just edited the three extensions and removed all codecs other than PCMA, although it may take a while before we can tell if this solves the problem or not.

Hopefully I can add back one or two HD codecs as we are aiming to add a SIP trunk for more lines in the not too distant future.


you can put the codecs you want, but it always depends on the VoIP provider you use and the phone provider you call, normally PCMA/U is the best codec, moreover avoid transcoding etc…


The issue may well be in codec negotiation. If there are too many codecs the negotiation may take too long on occasions thus timing out…I’ve seen this once or twice. Here in the UK all SIP providers use PCMA so that’s usually the one to go for on your SIP trunks.


A week has passed and, touch wood, we have had no further problems with delayed pick-up. Many thanks for your help!