Code autogenerated from Kurento/doc-kurento@8d3b4e3

source/knowledge/selfsigned_certs.rst

@@ -51,17 +51,29 @@ This command already includes some useful things:
 Using a local domain
 ====================
 
-You can take advantage of a domain wildcard such the ``*.test.local`` we propose, by simply adding a new entry to the ``/etc/hosts`` file in the secondary computer where you'll be accessing the main machine's services that you are developing.
+With the Hosts file
+-------------------
 
-For example, you could add this line to your *hosts* file:
+You can take advantage of a domain wildcard such as ``*.test.local``, by adding a new entry to the *Hosts file* in client computers that will connect to your main development machine.
+
+For example, on Linux and macOS you could add this line to your ``/etc/hosts`` file:
 
 .. code-block:: text
 
    192.168.1.50  dev.test.local
 
-With this, you can open a Firefox or Chrome browser, put ``dev.test.local`` in the address bar, and access your main development machine at 192.168.1.50.
+After editing the Hosts file like in this example, you can open a Firefox or Chrome browser, put ``dev.test.local`` in the address bar, and access your main development machine at 192.168.1.50.
+
+On Windows you can do the same; the Hosts file is located at ``%SystemRoot%\System32\drivers\etc\hosts``. Different systems have this file in different locations, so check here for a more complete list: :wikipedia:`Hosts_(file)#Location_in_the_file_system`.
+
+
+
+With Zeroconf
+-------------
+
+If editing the Hosts file is not an option, or you would like a more flexible solution, another possibility is to publish your server IP address as a temporary domain name in your LAN. You could do this with a full-fledged DNS server, but a simpler solution is to assign your machine a **discoverable Zeroconf address**.
 
-Alternatively you could publish your main machine's IP as a **Zeroconf address**. This technique is very handy, because practically all modern platforms include an mDNS client to resolve Zeroconf addresses. For example, if your development machine uses Ubuntu you can run this:
+This technique is very handy, because practically all modern platforms include an mDNS client to discover Zeroconf addresses. For example, if your development machine uses Ubuntu, you can run this:
 
 .. code-block:: shell
 
@@ -71,7 +83,7 @@ Alternatively you could publish your main machine's IP as a **Zeroconf address**
 
 .. note::
 
-   As of this writing, Android seems to be the only major platform unable to resolve local Zeroconf addresses. All other systems support them in one way or another:
+   As of this writing, Android seems to be the only major platform unable to resolve Zeroconf addresses. All other systems support them in one way or another:
 
    * Windows: `mDNS and DNS-SD slowly making their way into Windows 10 <https://www.ctrl.blog/entry/windows-mdns-dnssd.html>`__.
    * Mac and iOS include mDNS natively.

source/project/relnotes/v0_TEMPLATE.rst

@@ -2,7 +2,7 @@
 1.22.3 (UNRELEASED)
 ===================
 
-<Short description>
+This is a template for changes that are being added to the next release.
 
 To install Kurento Media Server: :doc:`/user/installation`.
 

source/project/relnotes/v6_16_1.rst

@@ -1,8 +1,8 @@
 ===================
-1.22.3 (UNRELEASED)
+6.16.1 (UNRELEASED)
 ===================
 
-<Short description>
+This is a template for changes that are being added to the next release.
 
 To install Kurento Media Server: :doc:`/user/installation`.
 

source/user/installation.rst

@@ -321,6 +321,76 @@ 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.
+
+**First part (run commands on the Kurento Media Server machine)**
+
+Install required tools:
+
+.. code-block:: shell
+
+   sudo apt update && sudo apt install --yes jq netcat-openbsd
+
+   wget -O /tmp/websocat "https://github.com/vi/websocat/releases/download/v1.7.0/websocat_amd64-linux-static"
+   chmod +x /tmp/websocat
+
+Using the Kurento WebSocket JSON-RPC Protocol, create a MediaPipeline and RtpEndpoint, which is then used to generate an SDP Offer and get from it an UDP listen port:
+
+.. code-block:: shell
+
+   KURENTO_URL="ws://127.0.0.1:8888/kurento"
+
+   # Create a MediaPipeline.
+   PIPELINE="$(
+   /tmp/websocat -1 --jsonrpc "$KURENTO_URL" <<EOF | jq --raw-output .result.value
+   create { "type": "MediaPipeline" }
+   EOF
+   )"
+
+   # Create an RtpEndpoint.
+   ENDPOINT="$(
+   /tmp/websocat -1 --jsonrpc "$KURENTO_URL" <<EOF | jq --raw-output .result.value
+   create { "type": "RtpEndpoint", "constructorParams": { "mediaPipeline": "$PIPELINE" } }
+   EOF
+   )"
+
+   # Generate a new SDP Offer.
+   # This makes Kurento start listening on the RTP ports reported in the SDP.
+   SDP="$(
+   /tmp/websocat -1 --jsonrpc "$KURENTO_URL" <<EOF | jq --raw-output .result.value
+   invoke { "object": "$ENDPOINT", "operation": "generateOffer" }
+   EOF
+   )"
+
+   # Parse the SDP to get the first UDP port found (from either audio or video).
+   KURENTO_PORT="$(echo "$SDP" | grep -Po -m1 'm=\w+ \K(\d+)')"
+   echo "$KURENTO_PORT"
+
+Take note of the ``KURENTO_PORT``, and use it in the next section:
+
+**Second part (run commands on a client machine)**
+
+This part describes a connectivity check that should be performed from any end user machine that should be able to send its media out to Kurento Media Server. In principle, if your server network is configured correctly, this test should be successful. Otherwise, in case of failure this is an indication that there are some issues in the network, which gives you a head start to troubleshoot missing media in your application.
+
+.. code-block:: shell
+
+   KURENTO_IP="203.0.113.2" # The media server's public IP address.
+   KURENTO_PORT="12345"     # The KURENTO_PORT that was obtained in the previous section.
+
+   # 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:
+
+.. code-block:: text
+
+   Connection to 203.0.113.2 12345 port [udp/*] succeeded!
+
+
+
 .. Links
 
 .. _Amazon Web Services: https://aws.amazon.com