HT818 Keeps Losing Audio on Caller-side

bug

#1

Info:
Program – 1.0.11.7 Bootloader – 1.0.11.1 Core – 1.0.11.2 Base – 1.0.11.6
CPE – 1.0.1.117

We have an HT818 grandstream that appears to lose audio connection after a week or so, on the caller side. The caller cannot hear the line connected to the grandstream, but the person on the other end of the grandstream can hear the caller.

NOTE:
At one point when I was testing, I could hear, slightly - the grandstream side. But it was very quiet.

This has only occurred on line 1 of 6 that are registered on the 8 port grandstream.

We have been able to reboot the grandstream and fix the issue each time.

I have the SIP ALG disabled on the router and ports mapped to the LAN IP of the grandstream:
UDP : 1720-1728 and 5060-5081
TCP: 5060-5081 and 52644-52645 and 5222

I have also assigned a static IP to the device so I know it is porting to the right LAN IP.

Lastly, I have a proxy and have enabled the setting to only allow invitations through proxy to prevent direct IP calling that will keep SIPvicious from attacking/scanning the phones.

Profile 1 -> Allow Incoming SIP Messages
from SIP Proxy Only: -> Yes


#2

there are many things to try

  • update the fw
  • activate keep alive at 15 seconds
  • there is a way if I’m not wrong to program a reboot
  • verify the NAT
  • ECC.

#3
  1. I see now that the firmware I have on it is no longer the newest. It looks like 1.0.13.7 is now out of beta. We can try upgrading to this.

  2. Is the keepalive setting we are looking for in the Profile settings? Or elsewhere? What will this do by activating at 15 seconds?

  3. There is a way to program a reboot, but I figured this would be more a utility to check for firmware, assuming we had the device pointed to a specific download server, etc. Would it be expected to have to reboot to fix an issue? Or shouldn’t i be able to let the device run without error?

4 The last two: ‘Verify NAT’ and ‘ECC’. Could you provide more information?


#4

It is not easy to do distance counseling, if you want to try to do what I have indicated, then post improvements or worsening, otherwise they become just unanswered questions.
Regarding NAT, if you don’t know what it is like to verify, it is better to contact a computer scientist.


#5

A few questions

What are ports 1720-1728UDP used for?
What are ports 52644-52645 used for?
What is port 5222 used for?
What is port 5060 TCP used for?

Is the public IP static or dynamic?
If static, is that IP installed in the use NAT IP field in network in the HT? If not, then add.
If dynamic, does you have a DDNS whereby you have a FQDN and is that set in the NAT IP field? If not, consider getting one.

keep-alives cause the HT to send a data packet out at a given interval (you set the interval) and these cause a couple of things:

  1. If your public IP is dynamic you provider may try and recover the IP for use elsewhere if they detect that the IP is not passing data over a certain period. In essence there will be no active sessions, no activity, no use and no need for you to keep when others may have a need. By sending keep-alives, it causes the provider to be less likely to try and retrieve the IP. This is why I am asking about static or dynamic public IP.

  2. Many folks do not forward ports and may not be able to as they may not have control of the router. Keepalives send a packet which in-turn causes the router (most anyway) to open the ports to let the packet out and then keep it open for a period in anticipation of a response. The amount or time left open depends on the protocol being used and the manufacturer of the router. If forwarding is not in place and keepalives not enabled, then when you make a call, the ports will open and all seems well, but once you stop calling… the router will close them and any inbound calls will never be seen.

Unless I am mistaken and you are indeed using TCP, you should only need port 5060UDP and then the ports that are set for the local RTP and this should also be UDP. The default local RTP port is 5004, but perhaps you changed it.

There are only 3 data streams that the device really needs to be concerned about:
SIP - port 5060UDP for the SIP messaging that does the setup and breakdown of the call.
RTP- port 5004UDP which is the stream for audio
HTTP/HTTPS -port 80TCP or 443TCP if you want to access the web gui of the HT remotely. However, be advised that a remap of ports may be needed if these ports are already in use and that exposing the web interface does pose a risk as people will find it and attempt to hack into it.

You do not need a proxy to stop SIP scanners. You can use the other embedded security functions to accomplish the same, which you have, but if working there is no need to change either.
All of the above is simply to set the HT up for success, but may not solve the issue. I don’t recall ever having someone complain about an intermittent issue where one could faintly hear it, but at other times OK and then not. Usually, the issue is no audio or all calls too loud or too soft.

So, the first plan is to ensure the HT is set correctly and then see, and if still an issue, swap the the handset or whatever else is on port 1 and see if the issue stays or moves.
Finally, you could swap ports 1 with another and see if the issue stays with port 1.


#6

tcoomer have you found a fix to this? I am having the same issue. Thanks