Doc : fix some minor typos (#43)

_includes/documentation/v3/libmediasoupclient/api/SendTransportListener.md

@@ -71,7 +71,7 @@ std::future<std::string> MySendTransportListener::OnProduce(
       std::make_exception_ptr("'id' missing/invalid in response"));
   }
 
-  // Fullfill the promise with the id in the response and return its future.
+  // Fulfil the promise with the id in the response and return its future.
 	promise.set_value(idIt->get<std::string>());
 
 	return promise.get_future();
@@ -135,7 +135,7 @@ std::future<std::string> MySendTransportListener::OnProduceData(
       std::make_exception_ptr("'id' missing/invalid in response"));
   }
 
-  // Fullfill the promise with the id in the response and return its future.
+  // Fulfil the promise with the id in the response and return its future.
 	promise.set_value(idIt->get<std::string>());
 
 	return promise.get_future();

_includes/documentation/v3/libmediasoupclient/api/TransportListener.md

@@ -55,7 +55,7 @@ std::future<void> MyTransportListener::OnConnect(
 	// [...] Let's assume code execution continues once we get a success response
 	// from the server.
 
-	// Fullfill the promise and return its future.
+	// Fulfil the promise and return its future.
 	promise.set_value();
 
 	return promise.get_future();

documentation/overview.md

@@ -6,7 +6,7 @@ anchors : true
 
 # Overview
 
-An [SFU](https://webrtcglossary.com/sfu/) (Selective Forwarding Unit) receives audio and video streams from endpoints and relays them to everyone else (endpoints send one and receive many). Each receiver endpoint can select which streams and spatial/temporal layers it receives. Compared to a mixer or [MCU](https://webrtcglossary.com/mcu/) (Multipoint Control Unit) this design leads to a better performance, higher throughput and less latency. It's highly scalable and requires much less resources given that it does not transcode or mix media.
+An [SFU](https://webrtcglossary.com/sfu/) (Selective Forwarding Unit) receives audio and video streams from endpoints and relays them to everyone else (endpoints send one and receive many). Each receiver endpoint can select which streams and spatial/temporal layers it receives. Compared to a mixer or [MCU](https://webrtcglossary.com/mcu/) (Multipoint Conferencing Unit) this design leads to a better performance, higher throughput and less latency. It's highly scalable and requires much less resources given that it does not transcode or mix media.
 
 Since endpoints get the other endpoints' media separately, they can have a personalized layout and choose which streams to render and how to display them.
 

documentation/v3/libmediasoupclient/design.md

@@ -32,4 +32,4 @@ Examples:
 
 * [device.GetRtpCapabilities()](/documentation/v3/libmediasoupclient/api/#device-GetRtpCapabilities) blocks the current thread until capabilities are internally retrieved and returns them.
 * [sendTransport.Produce()](/documentation/v3/libmediasoupclient/api/#SendTransport-Produce) internally performs SDP offer/answer in the underlaying `RTCPeerConnection` instance and blocks the thread until done.
-* The [SendTransport::Listener::OnProduce](/documentation/v3/libmediasoupclient/api/#SendTransportListener-OnProduce) event returns a `std::future` and waits for the application to fullfill it (once it communicates to the server).
+* The [SendTransport::Listener::OnProduce](/documentation/v3/libmediasoupclient/api/#SendTransportListener-OnProduce) event returns a `std::future` and waits for the application to fulfil it (once it communicates to the server).

documentation/v3/mediasoup/design.md

@@ -12,7 +12,7 @@ Unlike other existing SFU implementations, mediasoup is not a standalone server
 const mediasoup = require("mediasoup");
 ```
 
-Thus internally, mediasoup can be splitted into two separete components:
+Thus internally, mediasoup can be splitted into two separate components:
 
 * a JavaScript layer exposing a modern ECMAScript API for Node.js, and
 * a set of C/C++ subprocesses that handle the media layer (ICE, DTLS, RTP and so on).

documentation/v3/mediasoup/rtp-parameters-and-capabilities.md

@@ -348,7 +348,7 @@ These parameters influence the mediasoup operation by enabling or disabling some
 
 Parameter      | Type    | Description   | Required | Default
 -------------- | ------- | ------------- | -------- | ---------
-"useinbandfec" | Number  | If 1, mediasoup will use the worst packet fraction lost in the RTCP Receiver Report received from the consuming endpoints and use it into the Receiver Report that mediasoup sends to the OPUS producer endpoint. This will force it to generate more in-band FEC into the OPUS packets to accomodate to the worst receiver. | No | 0
+"useinbandfec" | Number  | If 1, mediasoup will use the worst packet fraction lost in the RTCP Receiver Report received from the consuming endpoints and use it into the Receiver Report that mediasoup sends to the OPUS producer endpoint. This will force it to generate more in-band FEC into the OPUS packets to accommodate to the worst receiver. | No | 0
 "usedtx"        | Number | If 1, mediasoup will not consider the stream as inactive when there is no RTP traffic. Same behavior is achieved by indicating `dtx`: `true` in the corresponding encoding in the RTP send parameters. | No | 0
 
 </div>

documentation/v3/scalability.md

@@ -64,10 +64,10 @@ It's also perfectly possible to inter-communicate mediasoup routers running in d
 <div markdown="1" class="note warn">
 When broadcasting a video stream to many viewers (hundreds or thousands of consumers) it's important to be aware of how video RTP transmission typically works:
 
-* A viewer may eventually loose video packets so would request packet retransmission to mediasoup. Retranmissions are handled per transport (they do not reach the broadcaster endpoint) so there is no limitation here.
+* A viewer may eventually loose video packets so would request packet retransmission to mediasoup. Retransmissions are handled per transport (they do not reach the broadcaster endpoint) so there is no limitation here.
 * A viewer may connect or reconnect, or may change its preferred spatial layer, or may just loose too many packets. Any of those circumstances would imply a video key frame request by means of a RTCP PLI or FIR that reaches the broadcaster endpoint.
 * Upon receipt of a video PLI or FIR, the encoder in the broadcaster endpoint generates a video key frame which is a video packet much bigger than the usual ones.
-* If the encoder receives many PLIs or FIRs (although mediaoup protects the producer endpoint by preventing it from receiving more than one PLI or FIR per second) the sending bitrate of the broadcaster endpoint would increase by 2x or 3x. This may be a problem for the producer endpoint and also for viewers that will receive much more bits per second.
+* If the encoder receives many PLIs or FIRs (although mediasoup protects the producer endpoint by preventing it from receiving more than one PLI or FIR per second) the sending bitrate of the broadcaster endpoint would increase by 2x or 3x. This may be a problem for the producer endpoint and also for viewers that will receive much more bits per second.
   - *NOTE:* This may be mitigated by increasing the default [keyFrameRequestDelay](/documentation/v3/mediasoup/api/#ProducerOptions) value, although that would cause longer "black-video" periods. 
 * And that is the problem.