Merge branch 'l7mp:main' into staging

docs/examples/benchmark/README.md

@@ -86,7 +86,7 @@ An example for:
 
 The below command will open:
 
-- one or more `turncat` clients at `127.0.0.1:90XY` (90XY are ports used for measurement purposes starting from 9000) to open a connection through STUNner to the iperf server. Traffic will be forwared to the STUNner public address obtained from STUNner configuration
+- one or more `turncat` clients at `127.0.0.1:90XY` (90XY are ports used for measurement purposes starting from 9000) to open a connection through STUNner to the iperf server. Traffic will be forwarded to the STUNner public address obtained from STUNner configuration
 - an `iperf` client sending its traffic to the turn
 
 `STUNner` and `iperf` are running inside the Kubernetes Cluster.
@@ -107,11 +107,11 @@ An example for:
 The output will be a standard `iperf` server output trimmed to show only the results. There are per-connections results and summarized results.
 
 * **Per-connection results:** The number of connections are set with the `-n` argument of the helper script. Rows starting like `[  4]` show per-connection results (e.g., throughput, jitter, and latency).
-* **Summarized results:** The `[SUM]` row summarizes the amount of transfered data, the effective bandwidth, the rate of the dropped/lost packets and the total number of sent packets and finally the packets/second (pps) rate.
+* **Summarized results:** The `[SUM]` row summarizes the amount of transferred data, the effective bandwidth, the rate of the dropped/lost packets and the total number of sent packets and finally the packets/second (pps) rate.
 
 Next, we see an example output for a local measurement and a measurement in Kubernetes.
 
-### Local measurment
+### Local measurement
 
 In a local measurement the output contains a single summarized test.
 You should see a similar output:
@@ -132,7 +132,7 @@ Results
 [SUM] 0.0000-0.9985 sec  5.97 MBytes  50.2 Mbits/sec  5/6265     6269 pps
 ```
 
-### Kubernetes measurment
+### Kubernetes measurement
 
 In case of a Kubernetes measurement, the output contains one or more summarized tests. In case the user reruns the script, `iperf` outputs will be appended. You should see an output similar to this:
 ```
@@ -163,9 +163,9 @@ Notice that the average packets/second rate will be slightly lower in case of a
 
 ## Caveats
 
-* It is advised to repeat the measurment with different packet sizes. Recommended packet sizes in bytes are 64, 128, 256, 512, 1024, and 1200. Small packet sizes result lower effective throughput (when packet drop is < 1%).
+* It is advised to repeat the measurement with different packet sizes. Recommended packet sizes in bytes are 64, 128, 256, 512, 1024, and 1200. Small packet sizes result lower effective throughput (when packet drop is < 1%).
 * Measuring [measuring one-way latency](https://stackoverflow.com/questions/63793030/iperf2-latency-is-a-two-way-or-one-way-latency) with `iperf` requires the clocks at the iperf client and server to be synchronized.  Without this the results may be corrupted, and you may even see negative latencies.
 
 # Help
 
-STUNner development is coordinated in Discord, feel free to [join](https://discord.gg/DyPgEsbwzc).
+STUNner development is coordinated in Discord, feel free to [join](https://discord.gg/DyPgEsbwzc).

docs/examples/direct-one2one-call/README.md

@@ -33,9 +33,9 @@ As the first step, each client registers a unique username with the application
 
 In order start the ICE conversation using STUNner as the STUN/TURN server, the browsers will need to learn an ICE server configuration from the application server with STUNner's external IP addresses/ports and the required STUN/TURN credentials. This must happen *before* the PeerConnection is created in the clients: once the PeerConnection is running we can no longer change the ICE configuration.
 
-We solve this problem by (1) generating a new ICE configuration every time a new client registers with the application server and (2) sending the ICE configuration back to the client in the `registerResponse` message. Note that this choice is suboptimal for [time-locked STUNner authentication modes](/doc/AUTH.md) (i.e., the `ephemeral` mode, see below), because clients' STUN/TURN credentials might expire by the time they decide to connect. It is up to the application server developer to make sure that clients' ICE server configuration is periodically updated.
+We solve this problem by (1) generating a new ICE configuration every time a new client registers with the application server and (2) sending the ICE configuration back to the client in the `registerResponse` message. Note that this choice is suboptimal for [time-locked STUNner authentication modes](/docs/AUTH.md) (i.e., the `ephemeral` mode, see below), because clients' STUN/TURN credentials might expire by the time they decide to connect. It is up to the application server developer to make sure that clients' ICE server configuration is periodically updated.
 
-The default STUNner [install](/doc/INSTALL.md) contains a utility called the [STUNner authentication service](https://github.com/l7mp/stunner-auth-service) that is purposed specifically to generate ICE configurations for the application server. The service watches the running STUNner configuration(s) from the Kubernetes API server and makes sure to generate STUN/TURN credentials and ICE server configuration from the most recent STUNner config.
+The default STUNner [install](/docs/INSTALL.md) contains a utility called the [STUNner authentication service](https://github.com/l7mp/stunner-auth-service) that is purposed specifically to generate ICE configurations for the application server. The service watches the running STUNner configuration(s) from the Kubernetes API server and makes sure to generate STUN/TURN credentials and ICE server configuration from the most recent STUNner config.
 
 The full application server code can be found [here](https://github.com/l7mp/kurento-tutorial-node/tree/master/direct-one2one-call); below we summarize the most important steps needed to call the STUNner authentication service in the application to generate an ICE config for each client.
 
@@ -113,7 +113,7 @@ The full application server code can be found [here](https://github.com/l7mp/kur
    ```js
    var iceConfiguration;
 
-   function resgisterResponse(message) {
+   function registerResponse(message) {
      if (message.response == 'accepted') {
        iceConfiguration = message.iceConfiguration;
      }
@@ -190,7 +190,7 @@ spec:
           namespace: stunner
 ```
 
-Noe that the `stunner/udp-gateway` and `stunner/tcp-gateway` Kubernetes Services are automatically created by STUNner to expose your Gateways, here we merely reuse these as backends.
+Note that the `stunner/udp-gateway` and `stunner/tcp-gateway` Kubernetes Services are automatically created by STUNner to expose your Gateways, here we merely reuse these as backends.
 
 ### Check your configuration
 
@@ -299,4 +299,4 @@ kubectl delete -f docs/examples/direct-one2one-call/direct-one2one-call-stunner.
 
 # Help
 
-STUNner development is coordinated in Discord, feel free to [join](https://discord.gg/DyPgEsbwzc).
+STUNner development is coordinated in Discord, feel free to [join](https://discord.gg/DyPgEsbwzc).

docs/examples/kurento-one2one-call/README.md

@@ -36,9 +36,9 @@ The media server responds with an SDP Answer for both the callee and the caller,
 
 In order to start the ICE conversation using STUNner as the STUN/TURN server, the browsers will need to learn an ICE server configuration from the application server with STUNner's external IP addresses/ports and STUN/TURN credentials. This must happen *before* the PeerConnection is created in the clients: once the PeerConnection is running we can no longer change the ICE configuration.
 
-We solve this problem by (1) generating a new ICE configuration every time a new client registers with the application server and (2) sending the ICE configuration back to the client in the `registerResponse` message. Note that this choice is suboptimal for [time-locked STUNner authentication modes](/doc/AUTH.md) (i.e., the `ephemeral` mode, see below), because clients' STUN/TURN credentials might expire by the time they decide to connect. It is up to the application server developer to make sure that clients' ICE server configuration is periodically updated.
+We solve this problem by (1) generating a new ICE configuration every time a new client registers with the application server and (2) sending the ICE configuration back to the client in the `registerResponse` message. Note that this choice is suboptimal for [time-locked STUNner authentication modes](/docs/AUTH.md) (i.e., the `ephemeral` mode, see below), because clients' STUN/TURN credentials might expire by the time they decide to connect. It is up to the application server developer to make sure that clients' ICE server configuration is periodically updated.
 
-The default STUNner [install](/doc/INSTALL.md) contains a utility called the [STUNner authentication service](https://github.com/l7mp/stunner-auth-service) that is purposed specifically to generate ICE configurations for the application server. The service watches the running STUNner configuration(s) from the Kubernetes API server and makes sure to generate STUN/TURN credentials and ICE server configuration from the most recent STUNner config.
+The default STUNner [install](/docs/INSTALL.md) contains a utility called the [STUNner authentication service](https://github.com/l7mp/stunner-auth-service) that is purposed specifically to generate ICE configurations for the application server. The service watches the running STUNner configuration(s) from the Kubernetes API server and makes sure to generate STUN/TURN credentials and ICE server configuration from the most recent STUNner config.
 
 The full application server code can be found [here](https://github.com/l7mp/kurento-tutorial-node/tree/master/kurento-one2one-call); below we summarize the most important steps needed to call the STUNner authentication service in the application to generate an ICE config for each client.
 
@@ -116,7 +116,7 @@ The full application server code can be found [here](https://github.com/l7mp/kur
    ```js
    var iceConfiguration;
 
-   function resgisterResponse(message) {
+   function registerResponse(message) {
      if (message.response == 'accepted') {
        iceConfiguration = message.iceConfiguration;
      }
@@ -361,7 +361,7 @@ Reload the browser client and re-register: you should see an updated ICE configu
 }
 ```
 
-Ephemeral credentials expire in one day, after which they are either refreshed (e.g., by forcing the users to re-register) or become useless. See more on this in the STUNner [authentication guide](/doc/AUTH.md).
+Ephemeral credentials expire in one day, after which they are either refreshed (e.g., by forcing the users to re-register) or become useless. See more on this in the STUNner [authentication guide](/docs/AUTH.md).
 
 ## Clean up