Media pathways for Video Call
An overview of the media network pathways used by Video Call - for IT staff
Video Call relay server address: vcct.healthdirect.org.au
Achieving the best-quality connection
1. For most network paths, the negotiation will likely result in a valid media connection.
- Direct peer-to-peer via UDP provides the best connection, but will often be unavailable across institutional networks, due to the security constraints of their network policies.
- A secure tunnelled TCP connection is the least-desirable option for media transfer, but most likely to be supported with no network security changes.
Recommended option: For many networks, allowing NAT egress to UDP port 3478 on the relay server (network path 2, above) will provide low latency with little overhead. This should require only a minor, low-risk change to your network configuration.
2. To make sure Video Call traffic is prioritised as real time communication please look at the options below:
- If your router is capable of prioritising traffic with DSCP field value of 34 (aka Assured Forwarding 41 or AF41) can you please configure this. All real-time WebRTC traffic is marked this way and this will improve the quality of Video Call and other video conferencing solutions.
- If your router is not capable of the above functionality you can set QoS to prioritise UDP packets in the 5000-40000 port range and this will help prioritise video packets and reduce any lag. WebRTC uses RTP protocol to deliver media streams and RTP generally uses UDP 5000-40000. Doing this may prioritise some packets which do not need it but the majority will be RTP packets. Setting up QoS in this way will ensure that video streams will have the least amount of interruptions and jitter.
Video Call will attempt to use the best network path that it can find.
The following table lists the network paths it will look for, in order of preference:
| Network path | STUN/Relay server port |
|---|---|
|
1: Direct peer-to-peer UDP, with STUN server-assisted NAT traversal Each endpoint will discover its external Internet address using the provided STUN Server. This address is provided to the other endpoint and used to set up the connection through Network Address Translation. Media flows over randomly selected ports over large range of UDP ports 49152 - 65535. |
3478 (UDP) |
|
2: Via Video Call relay server, using UDP-routed egress If a connection cannot be established using the above direct peer to peer, then the configured TURN server UDP port 3478 will be tried to establish a relay to the remote endpoint. This relay address is provided to the other endpoint and used to set up the connection through the relay, back through the local endpoint's connection to the TURN server. Media flows to UDP Port 3478 on the TURN server. |
3478 (UDP) |
|
3: Via Video Call relay server, using TCP-routed egress If a connection cannot be established using UDP to the TURN Server, the connection to the TURN Server is established via TCP 443 not UDP 3478. Media flows outwards to TCP port 443 on the TURN Server. |
3478 (TCP) |
|
4: Via Video Call relay server, using TCP tunnelling through a local web proxy server If a routed connection via NAT cannot be established to the TURN Server, a tunnelled connection to TCP port 443 will be attempted via the browsers configured web proxy server. Media flows outwards through the web proxy, to TCP Port 443 on the TURN Server. |
443 (TCP) |
|
5a, 5b: Via Video Call relay server, using Secure TCP As for 3 or 4 above, but using a TLS TCP connection to the TURN Server. |
443 (TCP/TLS) |
For more information, see Video Call relay servers.