Various minor typo fixes (#2313)

conf/janus.plugin.videoroom.jcfg.sample

@@ -3,8 +3,8 @@
 # is_private = true|false (whether this room should be in the public list, default=true)
 # secret = <optional password needed for manipulating (e.g. destroying) the room>
 # pin = <optional password needed for joining the room>
-# require_pvtid = true|false (whether subscriptions are required to provide a valid
-#			a valid private_id to associate with a publisher, default=false)
+# require_pvtid = true|false (whether subscriptions are required to provide a valid private_id 
+#			to associate with a publisher, default=false)
 # publishers = <max number of concurrent senders> (e.g., 6 for a video
 #              conference or 1 for a webinar)
 # bitrate = <max video bitrate for senders> (e.g., 128000)

html/demos.html

@@ -58,7 +58,7 @@ <h1>Janus WebRTC Server: Demo Tests</h1>
 				</tr>
 				<tr>
 					<td><a href="audiobridgetest.html">Audio Room</a></td>
-					<td>An audio mixing/bridge demo, allowing you join an Audio Room room.</td>
+					<td>An audio mixing/bridge demo, allowing you join an Audio Room.</td>
 				</tr>
 				<tr>
 					<td><a href="textroomtest.html">Text Room</a></td>

html/janus.js

@@ -41,7 +41,7 @@ Janus.isExtensionEnabled = function() {
 		}
 		return Janus.extension.isInstalled();
 	} else {
-		// Firefox of others, no need for the extension (but this doesn't mean it will work)
+		// Firefox and others, no need for the extension (but this doesn't mean it will work)
 		return true;
 	}
 };

html/videoroomtest.js

@@ -524,7 +524,7 @@ function newRemoteFeed(id, display, audio, video) {
 						Janus.log("Successfully attached to feed " + remoteFeed.rfid + " (" + remoteFeed.rfdisplay + ") in room " + msg["room"]);
 						$('#remote'+remoteFeed.rfindex).removeClass('hide').html(remoteFeed.rfdisplay).show();
 					} else if(event === "event") {
-						// Check if we got an event on a simulcast-related event from this publisher
+						// Check if we got a simulcast-related event from this publisher
 						var substream = msg["substream"];
 						var temporal = msg["temporal"];
 						if((substream !== null && substream !== undefined) || (temporal !== null && temporal !== undefined)) {

mainpage.dox

@@ -256,7 +256,7 @@ Janus.init({
  * These properties and callbacks are passed to the method as properties
  * of a single parameter object: that is, the \c Janus constructor takes a
  * single parameter, which although acts as a container for all the available
- * options. The \c success callback is where you tipically start your application
+ * options. The \c success callback is where you typically start your application
  * logic, e.g., attaching the peer to a plugin and start a media session.
  *
  * Here's an example:
@@ -309,7 +309,7 @@ var janus = new Janus(
  * - \c isConnected(): returns \c true if the Janus instance is connected
  * to the server, \c false otherwise;
  * - \c getSessionId(): returns the unique Janus session identifier;
- * - \c attach(parameters): attaches the session to a plugin, creating an handle;
+ * - \c attach(parameters): attaches the session to a plugin, creating a handle;
  * more handles to the same or different plugins can be created at the same time;
  * - \c destroy(parameters): destroys the session with the server, and closes
  * all the handles (and related PeerConnections) the session may have with any plugin as well.
@@ -2703,7 +2703,7 @@ python -m SimpleHTTPServer 9000
  *
  * \section deplyws Using Janus with WebSockets
  *
- * Configuring the usae of WebSockets rather than the REST API in the JavaScript
+ * Configuring the use of WebSockets rather than the REST API in the JavaScript
  * library is quite trivial, as it's a matter of passing a \c ws:// address
  * instead of an \c http:// one to the constructor. That said, most of the same
  * considerations provided for the REST API apply here as well, e.g.,

plugins/janus_recordplay.c

@@ -28,7 +28,7 @@
  * the available recordings that can be replayed.
  *
  * \note The application creates a special file in INI format with
- * \c .nfo extension for each recording that is saved. This is necessary
+ * <tt>.nfo</tt> extension for each recording that is saved. This is necessary
  * to map a specific audio .mjr file to a different video .mjr one, as
  * they always get saved in different files. If you want to replay
  * recordings you took in a different application (e.g., the streaming

plugins/janus_streaming.c

@@ -21,7 +21,7 @@
  *
  * For what concerns types 1. and 2., considering the proof of concept
  * nature of the implementation the only pre-recorded media files
- * that the plugins supports right now are raw mu-Law and a-Law files:
+ * that the plugins supports right now are Opus, raw mu-Law and a-Law files:
  * support is of course planned for other additional widespread formats
  * as well.
  *

plugins/janus_videoroom.c

@@ -54,8 +54,8 @@ room-<unique room ID>: {
 	is_private = true|false (private rooms don't appear when you do a 'list' request, default=false)
 	secret = <optional password needed for manipulating (e.g. destroying) the room>
 	pin = <optional password needed for joining the room>
-	require_pvtid = true|false (whether subscriptions are required to provide a valid
-				 a valid private_id to associate with a publisher, default=false)
+	require_pvtid = true|false (whether subscriptions are required to provide a valid private_id 
+				 to associate with a publisher, default=false)
 	publishers = <max number of concurrent senders> (e.g., 6 for a video
 				 conference or 1 for a webinar, default=3)
 	bitrate = <max video bitrate for senders> (e.g., 128000)
@@ -87,7 +87,7 @@ room-<unique room ID>: {
 	notify_joining = true|false (optional, whether to notify all participants when a new
 				participant joins the room. The Videoroom plugin by design only notifies
 				new feeds (publishers), and enabling this may result extra notification
-				traffic. This flag is particularly useful when enabled with \c require_pvtid
+				traffic. This flag is particularly useful when enabled with require_pvtid
 				for admin to manage listening only participants. default=false)
 	require_e2ee = true|false (whether all participants are required to publish and subscribe
 				using end-to-end media encryption, e.g., via Insertable Streams; default=false)
@@ -112,7 +112,7 @@ room-<unique room ID>: {
  * video room and destroys it, kicking all the users out as part of the
  * process; \c exists allows you to check whether a specific video room
  * exists; finally, \c list lists all the available rooms, while \c
- * listparticipants lists all the active (as in currentòy publishing
+ * listparticipants lists all the active (as in currently publishing
  * something) participants of a specific room and their details.
  *
  * The \c join , \c joinandconfigure , \c configure , \c publish ,
@@ -131,7 +131,7 @@ room-<unique room ID>: {
  * the \c switch request can be used to change the source of the media
  * flowing over a specific PeerConnection (e.g., I was watching Alice,
  * I want to watch Bob now) without having to create a new handle for
- * that; \c finally, \c leave allows you to leave a video room for good
+ * that; finally, \c leave allows you to leave a video room for good
  * (or, in the case of viewers, definitely closes a subscription).
  *
  * \c create can be used to create a new video room, and has to be
@@ -342,7 +342,7 @@ room-<unique room ID>: {
 \verbatim
 {
 	"videoroom" : "success",
-	"rooms" : [		// Array of room objects
+	"list" : [		// Array of room objects
 		{	// Room #1
 			"room" : <unique numeric ID>,
 			"description" : "<Name of the room>",
@@ -408,7 +408,7 @@ room-<unique room ID>: {
  * (although may choose not to, more on this later) publish media in the
  * room, and as such become feeds that you can subscribe to.
  *
- * To specify a handle will be associated with a publisher, you must use
+ * To specify that a handle will be associated with a publisher, you must use
  * the \c join request with \c ptype set to \c publisher (note that, as it
  * will be explained later, you can also use \c joinandconfigure for the
  * purpose). The exact syntax of the request is the following:
@@ -500,7 +500,7 @@ room-<unique room ID>: {
  * to the room configuration (e.g., to make sure the codecs you negotiated
  * are allowed in the room), and will reply with a JSEP SDP answer to
  * close the circle and complete the setup of the PeerConnection. As soon
- * as the PeerConnection has been establisher, the publisher will become
+ * as the PeerConnection has been established, the publisher will become
  * active, and a new active feed other participants can subscribe to.
  *
  * The syntax of a \c publish request is the following:
@@ -895,7 +895,7 @@ room-<unique room ID>: {
  * right info out of band (which is impossible in rooms configured with
  * \c require_pvtid).
  *
- * To specify a handle will be associated with a subscriber, you must use
+ * To specify that a handle will be associated with a subscriber, you must use
  * the \c join request with \c ptype set to \c subscriber and specify which
  * feed to subscribe to. The exact syntax of the request is the following:
  *