Code autogenerated from Kurento/doc-kurento@23adb45

source/knowledge/nat.rst

@@ -21,7 +21,7 @@ Basic Concepts
 Transport Address
 -----------------
 
-A Transport Address is the combination of a host's IP address and a port. When talking about transmission of packets between hosts, we'll refer to them in terms of the transport addresses of both the source and the destination.
+A *Transport Address* is the combination of a host's IP address and a port. When talking about transmission of packets between hosts, we'll refer to them in terms of the transport addresses of both the source and the destination.
 
 
 
@@ -214,62 +214,64 @@ In order to tell one host when it has to perform an outbound transmission to ano
 
 
 
+.. _nat-diy-holepunch:
+
 Do-It-Yourself hole punching
 ----------------------------
 
 It is very easy to test the NAT capabilities in a local network. To do this, you need access to two hosts:
 
-A. One sitting behind a NAT. We'll call this the host **A**.
-B. One directly connected to the internet, with no firewall. This is host **B**.
+A. One sitting behind a NAT. We'll call this the host **[A]**.
+B. One outside the NAT (e.g. by directly connecting it to the internet, with no firewall). This is host **[B]**.
 
 Set some helper variables: the *public* IP address of each host, and their listening ports:
 
 .. code-block:: shell
 
-   A_IP="198.51.100.1" # Public IP address of the NAT which hides the host A
-   A_PORT="1111"       # Listening port on the host A
-   B_IP="203.0.113.2"  # Public IP address of the host B
-   B_PORT="2222"       # Listening port of the host B
+   A_IP="198.51.100.1" # Public IP address of the NAT which hides the host [A]
+   A_PORT="1111"       # Listening port on the host [A]
+   B_IP="203.0.113.2"  # Public IP address of the host [B]
+   B_PORT="2222"       # Listening port of the host [B]
 
-1. **A** starts listening for data. Leave this running in A:
+1. **[A]** starts listening for data. Leave this running in [A]:
 
    .. code-block:: shell
 
       nc -4nul "$A_PORT"
 
-2. **B** tries to send data, but the NAT in front of **A** will discard the packets. Run in B:
+2. **[B]** tries to send data, but the NAT in front of **[A]** will discard the packets. Run in [B]:
 
    .. code-block:: shell
 
       echo "TEST" | nc -4nu -q 1 -p "$B_PORT" "$A_IP" "$A_PORT"
 
-3. **A** performs a hole punch, forcing its NAT to create a new inbound rule. **B** awaits for the UDP packet, for verification purposes.
+3. **[A]** performs a hole punch, forcing its NAT to create a new inbound rule. **[B]** awaits for the UDP packet, for verification purposes.
 
-   Run in B:
+   Run in [B]:
 
    .. code-block:: shell
 
       sudo tcpdump -n -i eth0 "src host $A_IP and udp dst port $B_PORT"
 
-   Run in A:
+   Run in [A]:
 
    .. code-block:: shell
 
       sudo hping3 --count 1 --udp --baseport "$A_PORT" --keep --destport "$B_PORT" "$B_IP"
 
-4. **B** tries to send data again. Run in B:
+4. **[B]** tries to send data again. Run in [B]:
 
    .. code-block:: shell
 
       echo "TEST" | nc -4nu -q 1 -p "$B_PORT" "$A_IP" "$A_PORT"
 
 .. note::
 
-   - The difference between a Cone NAT and a Symmetric NAT can be detected during step 3. If the *tcpdump* command on **B** shows a source port equal to *$A_PORT*, then the NAT is respecting the source port chosen by the application, which means that it is one of the Cone NAT types. However, if *tcpdump* shows that the source port is different from *$A_PORT*, then the NAT is changing the source port during outbound mapping, which means that it is a Symmetric NAT.
+   - The difference between a Cone NAT and a Symmetric NAT can be detected during step 3. If the *tcpdump* command on **[B]** shows a source port equal to *$A_PORT*, then the NAT is respecting the source port chosen by the application, which means that it is one of the Cone NAT types. However, if *tcpdump* shows that the source port is different from *$A_PORT*, then the NAT is changing the source port during outbound mapping, which means that it is a Symmetric NAT.
 
-   - In the case of a Cone NAT, the data sent from **B** should arrive correctly at **A** after step 4.
+   - In the case of a Cone NAT, the data sent from **[B]** should arrive correctly at **[A]** after step 4.
 
-   - In the case of a Symmetric NAT, the data sent from **B** won't arrive at **A** after step 4, because *$A_PORT* is the wrong destination port. If you write the correct port (as discovered in step 3) instead of *$A_PORT*, then the data should arrive at **A**.
+   - In the case of a Symmetric NAT, the data sent from **[B]** won't arrive at **[A]** after step 4, because *$A_PORT* is the wrong destination port. If you write the correct port (as discovered in step 3) instead of *$A_PORT*, then the data should arrive at **[A]**.
 
 
 

source/user/installation.rst

@@ -324,7 +324,11 @@ If you need to automate this, you could write a script similar to `healthchecker
 Checking RTP port connectivity
 ------------------------------
 
-This section explains how you can perform a quick and dirty connectivity check between a remote client machine and Kurento Media Server. It will let you know if an end user, like a web browser, would be able to send audio and video to the media server. In other words, this is a way to check if the media server itself is reachable from the network that WebRTC or RTP connections will use. If this test fails, it could indicate a cause for missing media streams in your application.
+This section explains how you can perform a quick and dirty connectivity check between a remote client machine and Kurento Media Server, in scenarios where **the media server is not behind a NAT**.
+
+This will let you know if an end user, like a web browser, would be able to send audio and video to the media server. In other words, this is a way to check if the media server itself is reachable from the network that WebRTC or RTP connections will use. If this test fails, it could indicate a cause for missing media streams in your application.
+
+The check proposed here will not work if the media server sits behind a NAT, because we are not punching holes in it (e.g. with STUN, see :ref:`faq-stun-needed`); doing so is outside of the scope for this section, but you could also do it by hand if needed (like shown in :ref:`nat-diy-holepunch`).
 
 **First part (run commands on the Kurento Media Server machine)**
 
@@ -383,7 +387,7 @@ This part describes a connectivity check that should be performed from any end u
    # Check if Kurento's UDP port is reachable from here.
    nc -vuz -w 3 "$KURENTO_IP" "$KURENTO_PORT" || echo "NOT REACHABLE"
 
-If the media server's UDP port is reachable from this machine (as it should), you should see this output from the ``nc`` command:
+If the media server's UDP port is reachable from this machine (as it should), you will see this output from the ``nc`` command:
 
 .. code-block:: text