grammar fixes

Author: systemcrash

docs/Asterisk_20_Documentation/Upgrading.md

@@ -13,7 +13,7 @@
    in the amd.conf configuration file.
 
 ### app_bridgewait
- * Adds the n option to not answer the channel when
+ * Adds the n option not to answer the channel when
    the BridgeWait application is called.
 
 ### features

docs/Configuration/Applications/External-IVR-Interface.md

@@ -92,7 +92,7 @@ The child process can send one of the following commands:
 * `P,TIMESTAMP`
 * `T,TIMESTAMP`
 
-The `S` command checks to see if there is a playable audio file with the specified name, and if so, clears the generator's playlist and places the file onto the list. Note that the playability check does not take into account transcoding requirements, so it is possible for the file to not be played even though it was found. If the file does not exist it sends a `Z` response with the data element set to the file requested. If the generator is not currently playing silence, then `T` and `D` events will be sent to signal the playlist interruption and notify it of the files that will not be played.
+The `S` command checks to see if there is a playable audio file with the specified name, and if so, clears the generator's playlist and places the file onto the list. Note that the playability check does not take into account transcoding requirements, so it is possible for the file not to be played even though it was found. If the file does not exist it sends a `Z` response with the data element set to the file requested. If the generator is not currently playing silence, then `T` and `D` events will be sent to signal the playlist interruption and notify it of the files that will not be played.
 
 The `A` command checks to see if there is a playable audio file with the specified name, and if so, appends it to the generator's playlist. The same playability and exception rules apply as for the `S` command.
 

docs/Configuration/Channel-Drivers/Local-Channel/Local-Channel-Modifiers.md

@@ -25,7 +25,7 @@ Local/101@mycontext/nj
 
 ## List of Modifiers
 
-* 'n' - Instructs the Local channel to not do a native transfer (the "n" stands for *No release*) upon the remote end answering the line. This is an esoteric, but important feature if you expect the Local channel to handle calls exactly like a normal channel. If you do not have the "no release" feature set, then as soon as the destination (inside of the Local channel) answers the line and one audio frame passes, the variables and dial plan will revert back to that of the original call, and the Local channel will become a zombie and be removed from the active channels list. This is desirable in some circumstances, but can result in unexpected dialplan behavior if you are doing fancy things with variables in your call handling. Read about [Local Channel Optimization](../Local-Channel-Optimization) to better understand when this option is necessary.
+* 'n' - Instructs the Local channel not to do a native transfer (the "n" stands for *No release*) upon the remote end answering the line. This is an esoteric, but important feature if you expect the Local channel to handle calls exactly like a normal channel. If you do not have the "no release" feature set, then as soon as the destination (inside of the Local channel) answers the line and one audio frame passes, the variables and dial plan will revert back to that of the original call, and the Local channel will become a zombie and be removed from the active channels list. This is desirable in some circumstances, but can result in unexpected dialplan behavior if you are doing fancy things with variables in your call handling. Read about [Local Channel Optimization](../Local-Channel-Optimization) to better understand when this option is necessary.
 * 'j' - Allows you to use the generic jitterbuffer on incoming calls going to Asterisk applications. For example, this would allow you to use a jitterbuffer for an incoming SIP call to Voicemail by putting a Local channel in the middle. The 'j' option must be used in conjunction with the 'n' option to make sure that the Local channel does not get optimized out of the call.
 * 'm' - Will cause the Local channel to forward music on hold (MoH) start and stop requests. Normally the Local channel acts on them and it is started or stopped on the Local channel itself. This options allows those requests to be forwarded through the Local channel.
 * 'b' - This option causes the Local channel to return the actual channel that is behind it when queried. This is useful for transfer scenarios as the actual channel will be transferred, not the Local channel.

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Exchanging-Device-and-Mailbox-State-Using-PJSIP.md

@@ -6,7 +6,7 @@ pageid: 29393398
 Background
 ----------
 
-Asterisk has permitted the exchange of device and mailbox state for many versions. This has normally been accomplished using the res_xmpp module for instances across networks or using res_corosync for instances on the same network. This has required, in some cases, an extreme amount of work to setup. In the case of res_xmpp this also adds another point of failure for the exchange in the form of the XMPP server itself. The res_pjsip_publish_asterisk module on the other hand does not suffer from this.
+Asterisk has permitted the exchange of device and mailbox state for many versions. This has normally been accomplished using the res_xmpp module for instances across networks or using res_corosync for instances on the same network. This has required, in some cases, an extreme amount of work to set up. In the case of res_xmpp this also adds another point of failure for the exchange in the form of the XMPP server itself. The res_pjsip_publish_asterisk module on the other hand does not suffer from this.
 
 Operation
 ---------

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Migrating-from-chan_sip-to-res_pjsip.md

@@ -60,7 +60,7 @@ This examples shows the configuration required for:
 * two SIP phones need to make calls to or through Asterisk, we also want to be able to call them from Asterisk
 * for them to be identified as users (in the old chan_sip) or endpoints (in the new res_sip/chan_pjsip)
 * both devices need to use username and password authentication
-* 6001 is setup to allow registration to Asterisk, and 6002 is setup with a static host/contact
+* 6001 is set up to allow registration to Asterisk, and 6002 is set up with a static host/contact
 
 | sip.conf | pjsip.conf |
 | --- | --- |

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Authentication.md

@@ -117,7 +117,7 @@ SHA2-512/256(stdin)= f8c3d34ce5ae6550740eaed0bff78a8aed354e87f2364813e4dbe9624bf
 You can specify multiple `password_digest` parameters in an auth object but no more than one for each digest hash algorithm.
 
 /// note | Line Endings
-Note that the examples show using the `-n` parameter in the `echo` command.  This tells `echo` to not output any line endings after printing the string.  This is important because you don't want those line endings included in the hash calculation.
+Note that the examples show using the `-n` parameter in the `echo` command.  This tells `echo` not to output any line endings after printing the string.  This is important because you don't want those line endings included in the hash calculation.
 ///
 
 /// warning | Algorithm Names

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Configuration-Sections-and-Relationships.md

@@ -80,7 +80,7 @@ callerid=Spaceman Spiff <6001>
 
 Configure how res_pjsip will operate at the transport layer. For example, it supports configuration options for protocols such as TCP, UDP or WebSockets and encryption methods like TLS/SSL.
 
-You can setup multiple transport sections and other sections (such as endpoints) could each use the same transport, or a unique one. However, there are a couple caveats for creating multiple transports:
+You can set up multiple transport sections and other sections (such as endpoints) could each use the same transport, or a unique one. However, there are a couple caveats for creating multiple transports:
 
 * They cannot share the same IP+port or IP+protocol combination. That is, each transport that binds to the same IP as another must use a different port or protocol.
 * PJSIP does not allow multiple TCP or TLS transports of the same IP version (IPv4 or IPv6).
@@ -201,7 +201,7 @@ EXAMPLE BASIC CONFIGURATION
 
 This example shows you how you might configure registration and outbound authentication against another Asterisk system, where the other system is using the older chan_sip peer setup.
 
-This example is just the registration itself. You'll of course need the associated transport and auth sections. Plus, if you want to receive calls from the far end (who now knows where to send calls, thanks to your registration!) then you'll need endpoint, AOR and possibly identify sections setup to match inbound calls to a context in your dialplan.
+This example is just the registration itself. You'll of course need the associated transport and auth sections. Plus, if you want to receive calls from the far end (who now knows where to send calls, thanks to your registration!) then you'll need endpoint, AOR and possibly identify sections set up to match inbound calls to a context in your dialplan.
 
 ```
 [mytrunk]

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Setting-up-PJSIP-Realtime.md

@@ -78,7 +78,7 @@ Then rename the config.ini.sample file to config.ini
 
 ```
 
-Finally, use Alembic to setup the database tables:
+Finally, use Alembic to set up the database tables:
 
 ```bash title=" " linenums="1"
 # alembic -c config.ini upgrade head
@@ -126,7 +126,7 @@ mysql> quit
 
 ## Configuring ODBC
 
-Now that we have our MySQL database created and populated, we'll need to setup ODBC and Asterisk's ODBC resource to access the database.  First, we'll tell ODBC how to connect to MySQL.  To do this, we'll edit the  **/etc/odbcinst.ini** configuration file.  Your file should look something like:
+Now that we have our MySQL database created and populated, we'll need to set up ODBC and Asterisk's ODBC resource to access the database.  First, we'll tell ODBC how to connect to MySQL.  To do this, we'll edit the  **/etc/odbcinst.ini** configuration file.  Your file should look something like:
 
 ```conf title="/etc/odbcinst.ini"
 [MySQL]

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/res_pjsip-Remote-Attended-Transfers.md

@@ -79,7 +79,7 @@ The big reason why Asterisk calls into the dialplan instead of automatically sen
 Writing your `external_replaces` extension
 ==========================================
 
-Now that the theory has been presented, you'll need to write your `external_replaces` extension. One option you have is to not write an `external_replaces` extension at all. This will prevent any remote attended transfers from succeeding.
+Now that the theory has been presented, you'll need to write your `external_replaces` extension. One option you have is not to write an `external_replaces` extension at all. This will prevent any remote attended transfers from succeeding.
 
 If you do want to write an `external_replaces` extension, the first thing you want to do is determine if you want to perform the remote attended transfer.  `SIPREFERTOHDR`, and values provided by the `CHANNEL()` dialplan function can help you to decide if you want to allow the transfer. For instance, you might use `CHANNEL(endpoint)` to see which PJSIP endpoint is performing the transfer, and you can inspect `SIPREFERTOHDR` to determine if the transfer is destined for a trusted domain.
 

docs/Configuration/Channel-Drivers/Unistim/Introduction-to-the-Unistim-channel.md

@@ -183,8 +183,8 @@ You can use the following entries in unistim.conf
 
 * As always, NAT can be tricky. If a phone is behind a NAT, you should port forward UDP 5000 (or change [general] port= in unistim.conf) and UDP 10000 (or change [yourphone] rtp_port=)
 * Only one phone per public IP (multiple phones behind the same NAT don't work). You can either :
-	+ Setup a VPN
-	+ Install asterisk inside your NAT. You can use IAX2 trunking if you're master asterisk is outside.
+	+ Set up a VPN
+	+ Install asterisk inside your NAT. You can use IAX2 trunking if your master asterisk is outside.
 	+ If asterisk is behind a NAT, you must set [general] public_ip= with your public IP. If you don't do that or the bindaddr is invalid (or no longer valid, eg dynamic IP), phones should be able to display messages but will be unable to send/receive RTP packets (no sound)
 * Don't forget : this work is based entirely on a reverse engineering, so you may encounter compatibility issues. At this time, I know three ways to establish a RTP session. You can modify [yourphone] rtp_method= with 0, 1, 2 or 3. 0 is the default method, should work. 1 can be used on new firmware (black i2004) and 2 on old violet i2004. 3 can be used on black i2004 with chrome.
 * If you have difficulties, try unistim debug and set verbose 3 on the asterisk CLI. For extra debug, uncomment #define DUMP_PACKET 1 and recompile chan_unistim.