On 17/07/17 05:28, Colton Conor wrote:
I know UDP seems to be the gold standard for SIP, and is in use by most service providers that are offering hosted voice today. My question is why not use TCP instead of UDP for SIP signaling?
Overall with small business clients we run into firewalls with SIP ALGs, short UDP session time out limits, and all sorts of connectivity issues with UDP. Some small business routers and modems have built in SIP ALGs that can't be disabled at all. The second we switch to TCP for signaling most of the issues go away for our hosted voice customers. Overall TCP just always seems to work, and UPD depends on the situation of the network. TCP is better for battery consumption on mobile sip applications as well.
With more providers switching to encryption using TLS which uses TCP, is there any need for us UDP for signaling anymore? Assuming most IP phones from Polycom, Yealink, and Cisco support TCP why not use it? Is it more resouce intensive on the SBCs?
What about on the media side? Does the RTP use UDP or TCP? If it uses UDP can TCP be used? What about for encryption like SRTP? Is SRTP TCP or UDP?
We switched to TCP 2 years ago since we need TLS. And experience with end-points was mostly positive. Not all of them quite same but its much improvement over UDP for us. pros - Better timeouts if you consider default UDP (where its 32s) - Server which reset your registration usualy send tcp.rst, which allow client to immediately start try re-register (not all of them do that) - protect you from async routing of packets (we had issue where we protect TCP stream with VPN tunnel, but at some point something broke at farend side and packets keep flowing around tunnel and UDP gladly accept them since there no session establishing) cons - Its still TCP and putting it on heavy loaded trunk will cause Head of Line blocking from time to time. Same applies to end-points if there is packet lost, but its negligible. RTP will still use UDP there is no need for TCP there it will make it just worse with its HoL problem.