Incoming calls not recieved

General
1

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.

2

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

3

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

2 Likes
4

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.

1 Like
5

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. :blush:

Best regards,
Alexandre

6

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

1 Like