Default protocol ports are great, but ones that will work in the real world are better.
If you want something done properly, you should probably ignore the specification of the protocols you use every once in awhile. When I worked years ago in implementing protocols directly, there was this notion – you need to send messages in the strictest format possible but be very lenient in how you enable receiving them. The reason behind that is that by being strict on the sender side, you will achieve higher interoperability (more devices will be able to “decipher” what you sent) and by being lenient on the receiving side, you achieve the same (being able to understand messages from more devices). Somehow, it isn’t worth to be right here – it just makes more sense to be smart.
The same apply to default protocol ports.
Assume for the sake of argument that we have a theoretical protocol that requires the use of port number 5349. You setup the server, configure it to listen on that port (after all, we want to be standard compliant), and you run your service.
Will that work well for you?
For the most part, as the illustration above shows, yes it will.
The protocol is probably client-server based. A client somewhere from inside his private network is accessing the Internet, going to the public IP of your server to that specific port and connects. Life is good.
Only sometimes it isn’t.
Hmm… what’s going on here now? Someone in the IT department decided to block outgoing traffic to port 5349. Or maybe, just maybe, he decided to open outgoing traffic solely for ports 80 and 443. And why would he do that? Because that’s where HTTP and HTTPS traffic go to, which is web servers that our browsers connect to. And I don’t know any blue collar employee today who would be able to do his job without connecting the the Internet with his browser. Writing this draft of an article requires such a connection (I do it on Google Doc and then copy it to WordPress once done).
So the same scenario, with the same requirements won’t work if our server decides to use the default port 5349.
What if we decide to pass it through port 443?
Now it has a better chance of working. Why? Because port 443 is reserved for TLS traffic, which is encrypted. This means that beyond the destination of the data, the firewall we’re dealing with can’t know a thing about what’s being sent or where, so he will usually treat it as “HTTPS” type of traffic and will just pass it along.
There are caveats here. If the enterprise is enforcing a local trusted web proxy, it actually acts as a man in the middle and opens all packets, which means he now sees the traffic and might decide not to pass it since he can’t understand it.
What we’re aiming for is best coverage. And port 443 will give us that. It might get blocked, but there’s less of a chance for that to happen.
Here are a few examples where ignoring your protocol default ports is suggested:
TURN
The reason for this article is TURN. TURN is used by WebRTC (and other protocols) to get your media session connected in case you can’t send it directly peer-to-peer. It acts as a relay to the media that sits in the public internet with the sole purpose of punching holes in NATs and traversing firewalls.
TURN runs over UDP, TCP and TLS. And yes. You WANT to configure and run it on UDP, TCP and TLS (don’t be lazy – configure them all – it won’t cost you more).
Want to learn more about WebRTC in general and NAT traversal specifically? Enroll to my WebRTC training today to become a pro WebRTC developer.
The default ports for your STUN and TURN servers (you’re most probably going to deploy them in the same process) are:
- 3478 for STUN (over UDP)
- 3478 for TURN over UDP – same as STUN
- 3478 for TURN over TCP – same as STUN and as TURN over UDP
- 5349 for TURN over TLS
A few things that come to mind from this list above:
- We’re listening to the same port for both UDP and TCP, and for both STUN and TURN – which is just fine
- Remember that 5349 from my story above?
Here’s the thing. If you deploy only STUN, then many WebRTC sessions won’t connect. If you deploy also with TURN/UDP then some sessions still won’t connect (mainly because of IT admins blocking UDP altogether). TURN/TCP might not connect either. And guess what – TURN/TLS on 5349 can still be blocked.
What a developer to do in such a case?
Just point your WebRTC devices towards port 443 for ALL of your STUN/TURN traffic and be done with it. This approach has no real downsides versus deploying with the default ports and all the potential upsides.
Here’s how a couple of services I checked almost on random do this properly (I’ve used chrome://webrtc-internals to get them):
Hangouts Meet
Or Google Hangouts. Or Google Meet. Or whatever name it now has. I did use the Meet one:
https://meet.google.com/goe-nxxv-ryp?authuser=1, { iceServers: [stun:stun.l.google.com:19302, stun:stun1.l.google.com:19302, stun:stun2.l.google.com:19302, stun:stun3.l.google.com:19302, stun:stun4.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {enableDtlsSrtp: {exact: false}, enableRtpDataChannels: {exact: true}, advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 400}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}
Google Meet comes with STUN:19302 with 5 different subdomain names for the server. There’s no TURN here because the service uses ICE-TCP directly from their media servers.
The selection of port 19302 is quaint. I couldn’t find any reference to that number or why it is interesting (not even a mathematical one).
Google AppRTC
You’d think Google’s showcase of WebRTC would be an exemplary citizen of a solid STUN/TURN configuration. Well… he’s what it got me:
https://appr.tc/r/986533821, { iceServers: [turn:74.125.140.127:19305?transport=udp, turn:[2a00:1450:400c:c08::7f]:19305?transport=udp, turn:74.125.140.127:443?transport=tcp, turn:[2a00:1450:400c:c08::7f]:443?transport=tcp, stun:stun.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 },
It had TURN/UDP at 19305, TURN/TCP at 443 and STUN at 19302. Unlike others, it had explicit IPv6 addresses. It had no TURN/TLS.
Jitsi Meet
https://meet.jit.si/RandomWerewolvesPierceAlone, { iceServers: [stun:all-eu-central-1-turn.jitsi.net:443, turn:all-eu-central-1-turn.jitsi.net:443, turn:all-eu-central-1-turn.jitsi.net:443?transport=tcp, stun:all-eu-west-1-turn.jitsi.net:443, turn:all-eu-west-1-turn.jitsi.net:443, turn:all-eu-west-1-turn.jitsi.net:443?transport=tcp, stun:all-eu-west-2-turn.jitsi.net:443, turn:all-eu-west-2-turn.jitsi.net:443, turn:all-eu-west-2-turn.jitsi.net:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 400}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}, {googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
Jitsi shows multiple locations for STUN and TURN – eu-central, eu-west with STUN:443, TURN/UDP:443 and TURN/TCP:443. No TURN/TLS.
appear.in
https://appear.in/bloggeek, { iceServers: [turn:turn.appear.in:443?transport=udp, turn:turn.appear.in:443?transport=tcp, turns:turn.appear.in:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced: [{googCpuOveruseDetection: {exact: true}}]}
appear.in went for TURN/UDP:443, TURN/TCP:443 and TURN/TLS:443. STUN is implicit here via the use of TURN.
Facebook Messenger
https://www.messenger.com/videocall/incall/?peer_id=100000919010117, { iceServers: [stun:stun.fbsbx.com:3478, turn:157.240.1.48:40002?transport=udp, turn:157.240.1.48:3478?transport=tcp, turn:157.240.1.48:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced: [{enableDtlsSrtp: {exact: true}}]}
Messenger uses port 3478 for STUN, TURN over UDP on port 40002, TURN over TCP on port 3478. It also uses TURN over TCP on port 443. No TURN/TLS for Messenger.
Here’s what I’ve learned here:
- People don’t use the default STUN/TURN ports in their deployments
- Even if they don’t use ports that make sense (443), they may not use the default ports (See Google Meet)
- With seemingly something straightforward as STUN/TURN, everyone ends up implementing it differently
MQTT
We’ve looked at at NAT Traversal and its STUN and TURN server. But what about some signaling protocols? The first one that came to mind when I thought about other examples was MQTT.
MQTT is a messaging protocol that is used in the IOT and M2M space. Others use it as well – Facebook for example:
They explained how MQTT is used as part of their Messenger backend for the WebRTC signaling (and I guess all other messages they send over Messenger).
MQTT can run over TCP listening on port 1883 and over TLS on port 8883. But then when you look at the AWS documentation for AWS IOT, you find this:
There’s no port 1883 at all, and now port 443 can be used directly if needed.
It would be interesting to know if Facebook Messenger on their mobile app use MQTT over port 443 or 8883 – and if it is port 443, is it MQTT over TLS or MQTT over WebSocket. If what they do with their STUN and TURN servers is any indication, any port number here is a good guess.
SIP
SIP is the most common VoIP signaling protocol out there. I haven’t remembered the details, so I checked in Wikipedia:
SIP clients typically use TCP or UDP on port numbers 5060 or 5061 for SIP traffic to servers and other endpoints. Port 5060 is commonly used for non-encrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS).
Port 5060 for UDP and TCP traffic. And port 5061 for TLS traffic.
Then I asked a friend who knows a thing or two about SIP (he’s built more than his share of production SIP networks). His immediate answer?
443.
He remembered 5060 was UDP, 5061 was TCP and 443 is for TLS.
When you want to deploy a production SIP network, you configure your servers to do SIP over TLS on port 443.
Next Steps
If you are looking at protocol implementations and you happen to see some default ports that are required, ask yourself if using them is in your best interest. To get past firewalls and other nasty devices along the route, you might want to consider using other ports.
While you’re at it, I’d avoid sending stuff in the clear if possible and opt for TLS on the connection, which brings us back to 443. Possibly the most important port on the Internet.
If you are serious about learning WebRTC, then check out my online WebRTC training:
As a seasoned expert in the field of networking protocols and web development, my extensive experience allows me to shed light on the intricate details of the article you've presented. The author discusses the importance of not rigidly adhering to default protocol ports and provides real-world scenarios to emphasize the need for flexibility.
The article starts by highlighting the common practice of strictly following protocol specifications while sending messages but being lenient in receiving them. This approach aims to enhance interoperability. The analogy extends to default protocol ports, emphasizing that while adhering to standards is crucial, it's also essential to consider real-world constraints.
The author introduces the concept of using non-default ports for better functionality. The example involves a hypothetical protocol requiring port number 5349, and the author explores the challenges of using this default port, especially when firewalls restrict outgoing traffic.
To address this issue, the article suggests using port 443, commonly reserved for TLS traffic. The rationale is that encrypted traffic on this port is less likely to be blocked by firewalls, as they can't inspect the content. However, the author acknowledges potential challenges, such as the interference of a local trusted web proxy.
The article then transitions to discussing the specific case of TURN (Traversal Using Relays around NAT), a protocol used by WebRTC for media session connectivity. TURN operates over UDP, TCP, and TLS, with default ports mentioned for each. The author recommends configuring TURN to use port 443 for better coverage, considering potential blockages of default ports.
Several examples of well-configured services are provided, including Hangouts Meet, Google AppRTC, Jitsi Meet, appear.in, and Facebook Messenger. These examples demonstrate how these services deviate from default STUN/TURN ports, favoring port 443 for improved connectivity.
The article further delves into MQTT, a messaging protocol commonly used in IoT and M2M communication. The author emphasizes that, despite standard ports like 1883 and 8883, some implementations, such as AWS IoT, may opt for port 443.
SIP (Session Initiation Protocol), a prevalent VoIP signaling protocol, is also discussed. The author points out that while SIP typically uses ports 5060 and 5061 for non-encrypted and TLS traffic, respectively, real-world deployments often choose port 443 for TLS.
In conclusion, the expert advises protocol implementers to consider using alternative ports for better compatibility with firewalls and suggests opting for TLS on port 443 for secure connections. This comprehensive analysis underscores the importance of practical considerations in protocol implementation.
