The TCP vs UDP debate

Status
Not open for further replies.

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
In the device settings, you have the choice to set up your device as UDP or TCP. I am assuming you use port 5080 regardless

Now I was told that some of the natting issues I was having would actually benefit by using TCP rather than UDP

Can anyone shed light on this? Does TCP really offer a better path for nat than UDP?

In addition, there were port conflicts from time to time (sip listen ports). So, I assigned a specific port to each yealink T29G in the building
5062, 5064, 5066, 5068 and so on........

this did help with the random drops, but I am trying to fine tune and ensure a rock solid set up. I am currently using UDP

See attached image for my device set up

Any insight, suggestions, ideas are welcomed
 

Attachments

  • deviceshot.jpg
    deviceshot.jpg
    103.5 KB · Views: 15

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
Yes, TCP is much better for NAT.

You absolutely should NOT be using port 5080 for extensions, that is for the external profile only, ie carriers.

You should never have to assign static ports to phones. The only time that ever seems to cause problems is when a SIP ALG is in play and that is the first thing you should be switching off.
 

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,415
376
83
The SIP protocol, is built on UDP for good reason. TCP is recommended as an alternative transport when certain UDP limitations are encountered. UDP has less overhead than TCP, because it is connectionless (fire and forget). TCP set up involves a three way handshake that all takes time to set up and tear down.

Switching to TCP can often mask the symptoms of underlying network issues, rather than being a cure.

Use UDP unless you really have a good reason to switch, if you have trouble with UDP, diagnose it properly first before deciding to switch transports.

Happy New Year!
 
  • Like
Reactions: falk

markjcrane

Active Member
Staff member
Jul 22, 2018
450
162
43
49
It’s easy to exceed UDP header size with UDP. If this happens because of too many codecs or other things that increase the header size then the SIP packet may not even reach the server.

Other things to consider:

Packet loss can also cause many issues.
Do you need the extra scalability?
Is the network really stable?
Do you want to use encryption with SIP TLS?
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
I agree with Adrian about TCP masking underlying network problem but I've personally been moving away from UDP now for years. We should all really be using TLS in 2022 for voip and that needs TCP.

TCP will usually also stop any ghost calls in their tracks as the source port is now a random high one.

NAT tunnels on routers stay open far longer for TCP than UDP generally too.

Then we have the whole issue of packet sizes, from my carrier, opus alone adds an extra 239 bytes!
 
  • Like
Reactions: markjcrane

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,415
376
83
I completely agree with both of you. It is very easy to exceed your UDP packet size (MTU) these days. Using compact headers and reducing the number of codecs offered can help with this. Even using shorter domain names can be a help especially for large BLF NOTIFY messages.

We have had several customers who have insisted on TLS and I'm guessing we will see this more and more. Many customers don't fully understand privacy in communications, they think TLS/ SRTP is a magic bullet, but secrecy only works if it is completely end to end and that includes the customer making sure that no one is stood just outside their office door listening to the conversation! Sure, TLS over part of the path does reduce the attack surface, but it cannot be considered end to end secure.

One more thing to remember, is that if you switch your SIP signalling to TCP, your RTP (audio) will still go UDP.

This is a useful subject to chat about because many people do not understand the pros and cons of different transports.

On the subject of NAT, I'm still waiting for the UK ISPs to properly roll out IPv6...
 
  • Like
Reactions: markjcrane

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Yes, TCP is much better for NAT.

You absolutely should NOT be using port 5080 for extensions, that is for the external profile only, ie carriers.

You should never have to assign static ports to phones. The only time that ever seems to cause problems is when a SIP ALG is in play and that is the first thing you should be switching off.
In my screenshot above, a device set up, you are saying that should not be 5080? It populates by default. Why on a new fusion installation does it autopopluate 5080 on the device set up?

Also, in response to your help with assigning sip listening ports on my yealinks. The reason I did this was because I deployed several Yealink T29G in a local network (my fusion is hosted in the cloud) and registration dropped every few minutes. I verified that Sip ALG was disabled on their Cisco VPN router and it was already disabled. As soon as I assigned static assigned sip listen ports they stayed registered for days. Your input on this is welcomed.
 

Attachments

  • deviceshot.jpg
    deviceshot.jpg
    103.5 KB · Views: 20

markjcrane

Active Member
Staff member
Jul 22, 2018
450
162
43
49
Your screen shot shows the default is 5060. You can tell by looking at the line that is mostly empty. This is a new potentional line for another SIP registration. Notice the SIP port is 5060 and transport is TCP that is the current default. Now look at the line above it is showing 5080 and UDP both of these are not the default.
 
Last edited:

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Thank you very much Mark for clarifying. I stand corrected. You are correct. I’m not sure why but In my installation somehow all my devices set at 5080. Now when I go back and create a new device it is showing 5060. Thank you for your input and your time
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
With regards to the ports, what ports are showing in the registrations in fusionpbx? In general, they should not be the same as the ports on the phones as most routers will be doing PAT (Port Address Translation)

The ones that don't usually work in a mode I have seen described as overload, ie they will use the same source port until another device tries to use that same source port then they will fall over to PAT.
 
Status
Not open for further replies.