If you are on a work network, or any network behind a firewall, you may need to speak with your IT department or network administrator. When you do, please give them the websites below to whitelist, and the ports to open.

Websites

hopin.to

hopin.com

tokbox.com

opentok.com

pusher.com

herokuapp.com

mux.com

twilio.com

hopin-analytics-production.herokuapp.com

Ports

Minimum Requirement:

The minimum requirement is that TCP port 443 is open. Some firewall/proxy rules only allow for SSL traffic over port 443. You will need to make sure that non-web traffic can also pass over this port.

Better Experience:

In addition to the minimum requirements being met, we also recommend that UDP port 3478 is open. This port is used by a piece of hardware called STUN server that helps establish the connection between the participants in the call with a firewall in the middle.

Best Experience:

For the best possible experience, we recommend that UDP ports 1025 - 65535 be open. Once these ports are open, there is no need for intermediary STUN/TURN servers which removes a hop from the media traffic.

Affects audio/video on: Backstage, Sessions, and Networking.

Since all segments affected make use of UDP to deliver the best video quality via media streams. When the ports are blocked, the audio/video quality will be impacted and result in: drops in quality, freezes of the stream, downscaling resolution or even audio/video being completely inaccessible as a result of very restrictive firewalls that don’t allow even TCP traffic unless whitelisted.

Whitelisting

Some companies might have restrictive network configurations and may not be able or willing to whitelist all TCP/UDP traffic to have successful sessions.

That is why we share the full list of IPv4 addresses to whitelist for the Sessions and the Stage to function properly (as of Q4, 2020)

"54.69.125.241/32", "74.201.205.0/25", "72.251.224.0/25", "72.251.228.0/25",

"95.172.84.0/25", "117.20.41.128/25","52.41.63.240/28", "52.200.60.16/28",
"52.51.63.16/28", "54.250.250.208/28", "52.65.127.192/27", "52.66.255.192/27",
"54.89.253.64/28", "35.158.127.224/28", "34.218.216.144/28", "13.251.158.0/28",
"52.213.63.176/28", "99.80.88.240/28", "3.123.12.128/28", "34.223.51.192/27",
"34.223.51.224/27", "3.214.145.96/27", "3.234.232.160/27",
"34.222.66.96/28", "99.79.160.16/28", "18.202.216.0/28",
"18.139.118.176/28", "3.248.234.48/28", "44.232.236.96/27",
"3.127.48.224/28", "3.248.243.144/28", "3.234.248.80/28",
"3.248.244.96/27", "18.156.18.0/27", "18.180.159.224/27",
"18.141.165.128/27", "3.7.161.0/26", "3.7.161.48/28",
"18.179.48.208/28","3.25.48.192/28", "18.157.71.112/28",
"3.235.255.176/28", "44.234.90.64/28", "15.228.1.16/28", "168.100.64.0/18"

Note: In case the UDP ranges are blocked, real-time communications (i.e. video/audio in Sessions/Networking/Backstage) will fallback to TCP.

TCP is not recommended for media transfer (plus causes more loads on the internet bandwidth and CPU time) because it requires the receiver to acknowledge the data has been received and the sender tries to send again if there is no acknowledge within the certain window.

Since media data that failed to be delivered a second ago is not that relevant especially when the following seconds of media were delivered seamlessly.

Feel free to reach out to us at [email protected] in case you have questions or need assistance.

Did this answer your question?