Hi, I recently 'upgraded from Grandstream HT503 to a HT802. Now a couple of people tell me that when they call my voip number they usually get a busy signal before the call terminates. Occasionally their calls come through to me. If I call my voip number from my cell phone the call has always connected properly. Voip call record show a lot of failed calls as zero duration. Voip tehcnical support looked at my settings on Voip and my HT802 and said that ‘the channel was not available’ due to ‘unreachable’ status. I don’t know if this info was on the voip website or in my HT802 configuration somewhere. Does anyone have any clue about why this happens and how to stop it? My ATA is plugged into the regular telephone wiring running through my house and I have three phones connected. Thanks.
Hello @Kingsboy48,
I switched from HT701 to HT802 few months ago.
Are you using TLS (secure) SIP connection? If no, I would recommend just for the simple reason that it makes things infinitely simpler with NAT and firewalls, etc. There will be only one connection to voip.ms. This might make things more stable.
If you are using TLS, are you sure you did set all the little settings for it to work properly. I got caught up with this problem. It took me a while to figure it out. Make sure to check the wiki page for detailed instructions:
https://wiki.voip.ms/article/Acrobits_Groundwire#Call_Encryption_-_TLS.2FSRTP
Otherwise, it will be a debug process to find out where is the problem with RTP port range, SIP port forward, etc.
Kind regards,
Alexandre
Alexandre,
Hi, thanks for your reply - sorry about a delayed reply. I think I am using TLS but I readily admit I’m no techy! I had a ‘chat’ with technical support who reviewed my ATA settings and got me to change the SIP Transport from UDP to TCP. I do not understand what that means except that everything appears to be working now. I can check my call records and see which calls did not make it through but since changing to TCP every call has come through. If a problem resurfaces I’ll come back here and take another look at your post etc.
Thanks again,
R
Probably your ISP was killing those lingering UDP connections without anyone noticing, their timeouts were probably too aggressive. It doesn’t help that the only way to “detect” that an UDP connection has stopped is through a timeout, since there are no control messages. TCP solves this problem by forcing your ISP to assign way longer timeouts by virtue of not having to guess when TCP closes its connection, the messages are pretty explicit at that. (Plus, on unstable networks, TCP is more reliable as far as I’ve been able to test, at the cost of a bit more latency).
TL;DR you’re using the better protocol for cases when your ISP is not very cooperative and/or reliable.
Hello @Kingsboy48,
I am glad they could fix it for you. Indeed, TLS (secure) connection only works with TCP connections. Also, UDP packets could probably not reach your device because in that case you need port forwarding, etc. TCP establishes a “connection” between your device and the server. I will not bother you with technicalities. 
Best regards,
Alexandre
Hi @danielfox32bit,
Yeah, the NAT table entry in firewalls (local or ISP), with shorter delays, certainly plays in the equation with UDP protocols. TCP not only helps in this regard, but it goes even more complex when you compare both protocols.
To put it simply:
- In UDP there are no “connections” between two sockets.
- Data packets are just “sent in the air” to a desired destination without any notion of having been received, nor the order they will be received.
- So there is no guarantee on the server side it has been received, and no guarantee on the client side it had to receive something.
- This is the best solution when speed and high traffic is required, like call centres, for example.
The other thing is that SIP/VoIP uses a set of communication ports that are usually blocked on firewalls and also, they need to be sent to a specific device. On top of that add NAT transversal issues for which UDP is way more susceptible. So these things make it technically more challenging to work properly. (Firewall settings, port forwarding, etc.)
The simple solution for small businesses and home users is TCP.
- It establishes a connection between the client and the server.
- Since the client established the connection, there are usually no special firewall settings required (in rare cases depending of each setup).
- All packet exchanges are guaranteed to arrive, and in order, except if the connection drops.
- Potentially gives better call quality, can introduce delays in real-time communications, and can simplify firewall and router issues.
- Concerning router settings, one must usually disable any “ALG” software option in the firewall because it can cause problems with the SIP/TCP connection.
The best solution is TCP/TLS.
- It will provide additional security so people cannot “listen” to your conversations.
- Concerning “ALG” software on routers, when using TLS it can be fine since the protocol is encrypted, but on old implementations of ALG it can still raise connection issues. If uncertain, just disable it too.
Kind regards,
Alexandre
For some reason, incoming calls drop after 4 rings if not answered before that. It also does not go to voicemail. I’ve checked every setting I can think of and don’t see any issues. What could be the problem? I opened a support ticket on this over a week ago and never got a reply. I really need this fixed.
I’m posting here in this existing thread because there doesn’t seem to be a way to post a “new” topic. Must be a bug or poor design in these forums.
Hello @Berto,
For the 4 rings call drop, maybe just check the Ring Time in seconds option in your DID (Manage DID(s)). It might just default to 20 sec, which is 4 rings. Increase it to whatever you need.
For the “New threads” look here:
Kind regards!
The DID setting was already set to 60 seconds.
I found more settings under the sub-accounts named “Internal extension ring time” and I set those to 60 seconds.
Still no change. Call drops after 4 rings.
I also found some settings under Ring Groups named “Ring Time” and changed those to 60 seconds. Still no change. Call still drops after 4 rings.
So DID is pointed to a Ring Group and has ring time in seconds set to 60.
The members in the ring group are set to 60.
And the internal extension ring time is set to 60
The next step would be to look at the device and see if either a device is answering and disconnecting or there is a maximum ring time set on the device itself.
Yes, everything is set to 60 seconds. The devices are NOT picking up. There is something wrong with the Voip.ms service or config since it drops the call after 4 rings.
I don’t know where else to check.
Verified again that it’s not my devices. I have two devices (a Grandstream and a Polycom phone). I unplugged the Grandstream and tested, then plugged it back in and unplugged the Polycom and tested, then unplugged both and tested. Same result every time. Four rings and the call drops.
Thanks for testing. Certainly something odd going on.
Any ideas on what else I can try?
Support still hasn’t responded to my ticket.