Applies to Models: Wisenet WAVE Sync
Wisenet WAVE allows you to connect to a WAVE Server behind a NAT without establishing port forwarding rules.
Explanation of Behavior:
Establishing the ability to maintain a constant connection to a WAVE Server without having to open ports and establishing routing rules for remote access.
Services that take part in WAVE Sync:
- The Mediator is an intermediate service that allows the Server and the Desktop client (each behind its own NAT) to find out the address of each other to establish a direct connection.
- The Relay (proxy) is another cloud service responsible for relaying traffic between the client and the media server in the event that UDP hole punching does not work.
NOTE: For an explanation of NAT Traversal >Click Here<
NOTE: For an explanation of what UDP Hole punching is >Click Here<
- When the Server application starts, it reports all of its local addresses to the mediator. This is needed if the media server is installed on a machine with a public IP.
- The Server connects to the relay and waits for incoming requests.
- The Desktop client takes the following steps to connect to the media server:
- If the Server can be found in a LAN using multicast, then the client establishes a direct TCP connection to that server. In this case, the mediator is not used.
- Otherwise, the client sends a connect request to the mediator.
- The mediator responds with all known addresses of the media server, this includes TCP addresses (forwarded and local) and the UDP address obtained by punching a hole in NAT.
- After receiving this information, the client tries to establish a connection to every address simultaneously.
- At the same time, the client tries to connect to the media server through a cloud relay service.
Note: To minimize connection time, there is no preference between TCP
and UDP. In some network environments, TCP may be the only option while
in others - UDP. Because of this possibility, giving preference to one
of them will slow down the time it takes to connect.
NAT Traversal Methods:
UDP hole punching:
NAT allows a host to send UDP packets to some public UDP service. (Figure 1)
When the host sends a UDP packet, NAT allocates a public port (port1 on address ip1) for that packet and sends the request as if it has been sent from ip1:port1.
When that service sends a response back to the ip1:port1, NAT knows it is actually Server that awaits the response and forwards the response to it.
So, when sending a UDP request from within NAT to the public, NAT punches a hole. This method is used in hole punching to establish a reliable connection over UDP between two peers, each behind its own NAT.
UDP hole punching does not guarantee success in 100% of cases. Success is dependent upon
client and media server NAT types.
All NAT types except for symmetric NAT allow for UDP hole punching. Although a
firewall/antivirus can still block UDP traffic (like any other traffic, actually).
In its initial state right after it starts, the server connects to the mediator. The mediator identifies itself by providing its GUID and waits for connection requests. The server maintains a persistent TCP connection to the mediator. (Figure 2)
The client sends a connect request to the mediator via UDP, providing the GUID of a System/specific server it wants to connect to. (Figure 3)
The mediator identifies the server by its GUID and sends a connection_requested message to the server via the pre-established TCP connection (this message contains the client's UDP address). (Figure 4)
Note: The client can specify the GUID of the whole System, not just a specific server.
In this case, the mediator will select any online server of that System.
The server opens a hole on its side and simultaneously:
- sends a connection_ack request to the mediator using UDP, and
- initiates UDT rendezvous connection with the client address provided in the connection_requested message (i.e., sends a number of UDP packets to the client): (Figure 5)
The mediator receives a connection_ack request from the server and sends a connect_response message to the client. (Figure 6)
The client receives a connect_response message and initiates UDT rendezvous connection to the server address found in connect_response. As a result, we now have a UDT connection between the server and client. (Figure 7)
Opening subsequent connections between the server and the client does not require all these steps to be repeated. Having at least one active UDT connection means that holes are punched in both NATs. Subsequent connections can be established with a regular UDT mechanism (similar to a TCP connection to a directly accessible address).
In this case, all traffic between the client and the server is relayed through the corresponding cloud service. It is the server and the client who are responsible for encrypting traffic. The cloud relay does not force encryption and does not distinguish SSL/non-SSL traffic when relaying.
The server establishes a connection to the relay and waits for requests from the client. (Figure 8)
The client sends a request to the relay asking to provide a relayed connection to the server. (Figure 9)
The relay uses an existing connection established by the server to transfer the client's traffic back to the server. At the same time, the server establishes another connection to the relay and waits for more client requests. To minimize client-side latency, the server always keeps at least 7 inactive connections to the relay (it is common for a client to request multiple connections to the server simultaneously). (Figure 10)
The problems described below will prevent you from connecting to the server.
The server is behind a Squid-like HTTP proxy
This impacts server → mediator (UDP hole punching algorithm (Figure 2)) and/or server → relay (Relaying, (Figure 8)) connections.
The Squid (http://www.squid-cache.org/) does not support any kind of HTTP tunneling (e.g., WebSocket or POST with the infinite body).
As a result, the media server can have problems establishing a persistent HTTP connection to the mediator or the cloud relay.
Other HTTP proxies and firewalls can have different limitations on HTTP dialect.
We address these limitations by introducing multiple HTTP tunneling methods, probing and selecting the most suitable one for the location (introduced in 3.2 patch).
UDP packets from the cloud do not reach the client
Impacts client → mediator message exchange (UDP hole punching algorithm, (Figure 5)).
Various intermediate networking hardware/software (e.g., firewall/antivirus) can lead to non-working UDP. As a result, the response from the mediator never reaches the client and the connection fails.
This is addressed by duplicating a UDP request with a TCP request in VMS 4.0.
How to locate the Cloud System ID:
What is the WAVE Sync System ID?
The WAVE Sync System ID is a unique identifier for the System on WAVE Sync. It is a combination of numbers and letters used to identify resources. It follows a standard format described in RFC 4122.
The WAVE Sync System ID is generated when the WAVE Media Server is connected to WAVE Sync for the first time.
How can I locate the Cloud System ID?
1. Open your browser
2. Enter sync.wavevms.com
3. Log in to your WAVE Sync Account
4. You will see the portal and the system tiles on your screen
5. Click on the System that you want to obtain the WAVE System ID of
6. The WAVE system ID is found in the URL and appended to /systems/
NOTE: WAVE still uses ports, and services. For a complete list
>Click Here< for our Firewall Whitelist.