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


#1

We have a busy office with a UCM6116 with 24 GXP2160 desk phones. Recently upgraded the 6116 from 1.0.9.25 to 1.0.18.12 (applying all interim updates one at a time per the release notes) and all 2160’s from 1.0.9.69 to 1.0.9.108.

Now we have major problems: incoming calls on any truck will eventually “timeout”, if you actively speaking with someone the call will just drop right in the middle of the call. Person will call back and let us know the calls was dropped. OUTBOUND CALLS NEVER DROP AND CAN BE ON HOLD FOR LONG PERIOD OF TIME, WITHOUT ANY OF THE SYMPTOMS MENTIONED ABOVE.

We opened a trouble ticket, have been going back & forth with support, uploaded logs files but there has been no response for several days from Grandstream. Our phone system is now a DISASTER!

Any help sorting this out would be a great help. Has anyone else had this issue?


#2

Check your PBX-SIP-NAT External host setting.


#3

There are major changes between where you were and where you are now. Many of which involved how the call set-up and NAT worked.

I assume you are using SIP trunks. Are they register or peer and who is provider? How is the UCM connected to the Internet? Is it behind a router and in which mode switch, dual, route?

If behind a router, what ports are forwarded and is any SIP ALG or helper disabled? What make and model of router?

Knowing how connected determines some of what might need to be changed. By not knowing and making a suggestion, it could go from bad to worse.


#4

Hi. We use two trunks, both are register trunks.

First one (main) is Cablevision. They use an Edgewater device which provides a static IP in our LAN the UCM connects to. So, in this case, it’s not clear now NAT would come into play.

The second trunk is only used for incoming calls, is Callcentric. The LAN & UCM are behind a firewall/router with no ports forwarded to the UCM (never was necessary before). It uses DD/WRT.


#5

forwards and NAT are most likely your issue.

Many people will ignore port forwards because the system seems to work sometimes without them.

Be sure you have forwarded ports in your firewall that accommodate the calls setup and RTP streams as well as making sure SIP ALG is off so it doesn’t rewrite packets.

Check the following:
-port forwards(this is with default settings on the UCM)
UDP 5060 to UCM (can be locked down to just SIP Provider IPs)
UDP 10000-20000 to UCM (must be open to all)

SIP ALG must be off

On the UCM
PBX-SIP-NAT External Host should have static IP or dynamic DNS address in it (this tells the SIP Provider what address to respond to)

-Keep in mind best practice is to change the 5060 port to something else as well as narrowing down the RTP ports to a much smaller amount.


#6

Thank you so much. I forwarded the ports. There was no setting in the router I could determine regarding SIP ALG so I am assuming it is not implemented. As it turns out it seems the incoming only trunk (Callcentric) is showing dropped calls but not Cablevision. Need more investigation to confirm but that would make sense in context of NAT and port forwarding.

For best practices, should SIP Settings > General > Bind UPD port be changed to something else, for example 7060? Then should I also change port forwarding for external port 7060 to internal 7060? How about settings under SIP Settings > NAT > External UDP/TCP/TLS ? Thank you.


#7

On the SBC side of things, NAT does not come in play, but…

The UCM formulates messages based on its awareness of how and where it resides in relation to the devices that it needs to communicate with. In the same section that Lucas indicated about putting in the public IP and checking the SDP box in SIP, NAT, you must also input in the local LAN segment further down below on the same page. Additionally, if the SBC is not on the same LAN segment, it too needs to be set in the same settings with its IP or LAN segment.

The above tells the UCM if it see messages from these segments that it needs to formulate the message such that it will tell the devices to use the local UCM IP when replying; otherwise is will assume the devices are external.

What Lucas provided is telling the UCM which address to implicitly use when needing to message external devices.

In the SIP trunk settings for the Callcentric trunk, un-check NAT if checked and then test. After doing the other suggestions.

As stated, what was then is not what it is now so how it may not have needed port forwarding might still be true today if all the settings and functionality were the same. While port forwarding was not on, it is likely that a keep-alive was in action which forced the port open.If not, then no inbound Callcentric call could have passed thru the firewall as the port should have been closed. When you have control of the router, it is best to port forward as it also establishes a direct route that is not reliant upon PAT tables. Further, most versions of dd/wrt do have SIP ALG and these may also cause issue by re-writing things assuming that one needs help in configuring things. Only a few manufacturers have implemented a SIP ALG implementation well, most others break things rather than help.


#8

Forwarding ports 5060 and 5061 (TCP and UCP) in the router seems to have resolved the problem, I was able to successfully complete a 15 minute test call w/o disconnecting. Hopefully I can call it good. Thank you so much lstutesman and lpneblett, you are the best.


#9

Please be sure to use the “mark as solved” button if you think that your problem was solved. It helps others find similar problems with known solutions.


#10

I may have spoken too soon, the problem is still happening but now seems isolated to certain extensions. That is, when certain extensions in the ring group pick up the call, the call drops after exactly 0:32 (32 seconds). Other extensions can pick up the call and talk for 15 minutes without dropping.


#11

32 Seconds is NAT. It’s a magic number in the SIP world. Here’s why: https://www.smartvox.com/what-are-sip-timers/


#12

if you came from firmware 1.0.9.x then make sure the NAT box on the sip trunk is unchecked and just the SDP box is checked in PBX-SIP-NAT

also make sure your RTP ports are forwarded as well as 5060-5061


#13

I made those changes but it’s still dropping calls.

BTW GS support had suggested on the GXP2160 SIP Settings > Security Settigs> Accept Incoming SIP from Proxy Only: YES – but this made no sense to me.

As a stopgap measure I can call-forward the callcentric number to the cablevision number and disable the callcentric trunk on the UCM. I want to reboot the UCM but this office is very busy, 2-5 calls at any one moment and ringing off the hook all day. I don’t want to give them any more grief than they already have.


#14

If it’s still dropping calls after 32 seconds, then you still have NAT problems. You may have to make more changes like enabling Keep-Alive in the extension settings or something else. But I guarantee you that 32 second drops is NAT.


#15

The next step is looking at a packet capture of the issue occurring.


#16

did you put the local lan segment in?


#17

Yes, local LAN segment is there. Here’s a screenshot…

Callcentric support says “it appears that the UCM6116 issues a BYE packet about 30 secs into the call from what appears to be an issue with it handling/receiving the last ACK packet from our network which is necessary for the initial call negotiation to complete. Due to the incomplete negotiation, the UCM ultimately issues a BYE after continuing to send the same 200 OK for 24 seconds.”


#18

I would reboot.

If the issue persists after that I would do a capture


#19

Vox has it. t1 timer not being satisfied. packet capture needed.


#20

What is the best practice for capturing packets of interest here, and how to interpret them?

Would it be worth a try to put the UCM in a DMZ, fully exposing it to the internet? If I do this, should the NAT settings go away?