UCM 6116 firmware 1.0.18.12 DISASTER, calls dropping, need help from grandstream


#41

I can check it tomorrow, but some good people are from US, so they have more time :slight_smile:
But i will suspect misconfiguration or NAT problem.


#42

Callcentric is sending to you (INVITE) on 5060 from 5080 (odd port) but the FROM and CONTACT headers indicates they are correct and looking at their site they indicate they support a range for SIP. Upon receiving the INVITE, the UCM appears to send INVITEs to a bunch of phones (22) in a ring group. This took almost 3 seconds to send the INVITEs. Ext 112 answered the INVITE, from 192.168.1.94, but then asked for the audio to be sent to 10.8.0.10 on port 5074. The CONTACT is also set for 10.8.0.10. So, it appears that perhaps the NAT iP section in the phone is set for 10.8.0.10 when the phone appears to be on the 192.168.1.X LAN segment. The phone is a 2160 running the .108 firmware, whereas the UCM is still running one of the prior versions you regressed to (10.16). Please upgrade the UCM.

Suggest you correct the NAT IP in the phone or, if correct, please provide more details of setup with respect to the internal topology. Check all extensions.

image

Additionally, while not a show stopper, get rid of all the codec settings in the UCM extension settings and the phones. Only have the ones you actually need and plan to use as it lessens the traffic being sent to and fro.

What has me a little confused is the below:
image

The left is the provider, the right the UCM. The UCM did indeed send a 200OK, which the provider ACK’ed. The Cseq is correct for these 2 messages and it seems that for some reason, the UCM never saw the ACK to the 200 and subsequently invoked the t1 timer and kept sending the 200OK in the hopes that the provider would send an ACK that the UCM would see and complete the call setup. This never happened and as a result, once the 32 seconds elapsed from the first 200OK, the UCM sent a bye and disconnected the call.

I did not examine all elements of the call as I have a client call coming up. Suggest you update firmware, check/change NAT IP in phones and then eliminate unneeded codecs and we go from there with another test call following the changes.


#43

32 Seconds is, 99.999% of the time, NAT related. See https://www.smartvox.com/what-are-sip-timers for why.


#44

#45

#46

Thanks to you guys I’m making good progress. Using Wireshark I was able to see the first OK went from the internal IP of the UCM to the callcentric IP, but the ACKs were tagged with the external IP of the UCM.

So in UCM > PBX > SIP > NAT I changed external host to the internal IP of the UCM and rebooted. Now incoming calls no longer drop after 32 seconds! However if you place a call on hold (at the GXP), the caller will hear the on-hold music as usual, but when you come off hold the audio is one-way only (outside caller can hear, the GXP user cannot). I took another capture but couldn’t follow the call once it got placed on hold. I want to see if a call will come off hold correctly when the external IP is set to the actual external IP (the original setting), but I didn’t have a chance to test that condition yet. Then the office got busy so I have to continue later.

BTW the pcap file reflects the fact that the particular GXP used in that test is connected to the local network through an OpenVPN server running at 192.168.1.94. That’s why the audio was sent to 10.8.0.10 - because that’s the OpenVPN IP of the remote GXP phone. The GXPs on the local LAN act the same as the remote phone with respect to the problem at hand.


#47

Check if you still receive packet frok providers.
If yes then TURN off NAT on that extension.
Also add All your VPN network to NAT as they are really not NAT.