Formatting cleanups

* Fixed broken links in the WhatsNew files.
* Fixed missing links and fixed many formatting issues in
  AMI-v2-Specification.  More work probably needs to be done.
* Fixed missing ER Diagram and many formatting issues in
  PJSIP-Configuration-Sections-and-Relationships.
* Added ability to use the new "definition" blocks from
  pymdownx.

Resolves: #40
Resolves: #49
Resolves: #51

Author: gtjoseph

docs/About-the-Project/A-Brief-History-of-the-Asterisk-Project.md

@@ -31,8 +31,7 @@ Asterisk is constantly evolving to meet the needs of the project's user-base. It
 
 * [Asterisk Versions](/About-the-Project/Asterisk-Versions): Shows release time lines, support and EOL schedules.
 * [Roadmap](/Development/Roadmap): Information from developer conferences and planning sessions.
-* [CHANGES](https://github.com/asterisk/asterisk/blob/master/CHANGES): A document in Asterisk trunk, shows functionality changes between major versions.
-* [UPGRADE](https://github.com/asterisk/asterisk/blob/master/UPGRADE.txt): A document in Asterisk trunk, shows breaking changes, deprecation of specific features and important info on upgrading.
+* [ChangeLogs](/latest_api/Whats_New): The Change Logs for the latest version of Asterisk.
 * [Mailing Lists](https://www.asterisk.org/community/discuss): The dev list is a great list to see what hot topics the developers are discussing in real-time.
 * [Forums](https://community.asterisk.org): The community forums are a great place to receive help with issues.
 

docs/Asterisk_18_Documentation/WhatsNew.md

@@ -4,5 +4,5 @@ title: New in 18
 
 # What's New in Asterisk 18
 
-For a complete list of changes and new things in Asterisk 18 please see the [CHANGES document](https://raw.githubusercontent.com/asterisk/asterisk/18/CHANGES) included with Asterisk 18.
+For a complete list of changes and new things in Asterisk 18 please see the [ChangeLogs](https://github.com/asterisk/asterisk/tree/releases/18/ChangeLogs) included with Asterisk 18.
 

docs/Asterisk_20_Documentation/WhatsNew.md

@@ -4,5 +4,5 @@ title: New in 20
 
 # What's New in Asterisk 20
 
-For a complete list of changes and new things in Asterisk 20 please see the [CHANGES document](https://raw.githubusercontent.com/asterisk/asterisk/20/CHANGES) included with Asterisk 20.
+For a complete list of changes and new things in Asterisk 20 please see the [ChangeLogs](https://github.com/asterisk/asterisk/tree/releases/20/ChangeLogs) included with Asterisk 20.
 

docs/Asterisk_21_Documentation/WhatsNew.md

@@ -34,4 +34,4 @@ Asterisk 21 saw fewer new additions than previous versions. Many of the changes
 9. res_monitor: This module was deprecated in Asterisk 16 and is now being removed in accordance with the Asterisk Module Deprecation policy. This also removes the 'w' and 'W' options for app_queue. MixMonitor should be default and only option for all settings that previously used either Monitor or MixMonitor.
 
 
-For a complete list of changes and new things in Asterisk 21 please see the [CHANGES document](https://raw.githubusercontent.com/asterisk/asterisk/21/CHANGES) included with Asterisk 21.
+For a complete list of changes and new things in Asterisk 21 please see the [ChangeLogs](https://github.com/asterisk/asterisk/tree/releases/21/ChangeLogs) included with Asterisk 21.

docs/Certified-Asterisk_18.9_Documentation/WhatsNew.md

@@ -4,4 +4,4 @@ title: New in Certified 18.9
 
 # What's New in Certified Asterisk 18.9
 
-For a complete list of changes and new things in Certified Asterisk 18.9 please see the [CHANGES document](https://raw.githubusercontent.com/asterisk/asterisk/certified/18.9/CHANGES) included with Certified Asterisk 18.9.
+For a complete list of changes and new things in Certified Asterisk 18.9 please see the [ChangeLogs](https://github.com/asterisk/asterisk/tree/releases/certified-18.9/ChangeLogs) included with Certified Asterisk 18.9.

docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/ERD_key.PNG

@@ -1,10 +1,6 @@
----
-title: PJSIP Configuration Sections and Relationships
-pageid: 30278064
----
+# PJSIP Configuration Sections and Relationships
 
-Configuration Section Format
-----------------------------
+## Configuration Section Format
 
 pjsip.conf is a flat text file composed of **sections** like most configuration files used with Asterisk. Each **section** defines configuration for a **configuration object** within res_pjsip or an associated module.
 
@@ -14,17 +10,19 @@ Each section has one or more **configuration options** that can be assigned a va
 
 Every section will have a **type** option that defines what kind of section is being configured. You'll see that in every example config section below.
 
-Syntax for res_sip config objects **[**  SectionName  **]**    
- ConfigOption  **=**  Value   
- ConfigOption  **=**  Value
+Syntax for res_pjsip config objects:
 
-On this Page
+```
+[object name]
+type = <object type>
+<option> = <value>
+<option> = <value>
+```
 
 
-Config Section Help and Defaults
---------------------------------
+## Config Section Help and Defaults
 
-Reference documentation for all configuration parameters is available on the wiki:
+Reference documentation for all configuration parameters:
 
 * [Core res_pjsip configuration options](/latest_api/API_Documentation/Module_Configuration/res_pjsip)
 * [Configuration options for ACLs in res_pjsip_acl](/latest_api/API_Documentation/Module_Configuration/res_pjsip_acl)
@@ -34,32 +32,23 @@ Reference documentation for all configuration parameters is available on the wik
 The same documentation is available at the Asterisk CLI as well. You can use "config show help <res_pjsip module name> <configobject> <configoption>" to get help on a particular option. That help will typically describe the default value for an option as well.
 
 
+/// tip|Defaults
+For many config options, it's very helpful to understand their default behavior. For example, for the endpoint section "transport=" option, if no value is assigned then Asterisk will \*DEFAULT\* to the first configured transport in pjsip.conf which is valid for the URI we are trying to contact.
+///
 
+## Object Names
 
-!!! tip **   ****Defaults**:
-    For many config options, it's very helpful to understand their default behavior. For example, for the endpoint section "transport=" option, if no value is assigned then Asterisk will \*DEFAULT\* to the first configured transport in pjsip.conf which is valid for the URI we are trying to contact.
-
-      
-[//]: # (end-tip)
-
-
-
-Section Names
--------------
-
-In most cases, you can name a section whatever makes sense to you. For example you might name a transport [transport-udp-nat] to help you remember how that section is being used.
+In most cases, you can name a section whatever makes sense to you. For example you might name a transport `[transport-udp-nat]` to help you remember how that section is being used.
 
 However, in some cases, (endpoint and aor types) the section name has a relationship to its function. In the case of endpoint and aor their names must match the user portion of the SIP URI in the "From" header for inbound SIP requests. The exception to that rule is if you have an identify section configured for that endpoint. In that case the inbound request would be matched by IP instead of against the user in the "From" header.
 
-Section Types
--------------
+## Object Types
 
 Below is a brief description of each section type and an example showing configuration of that section only. The module providing the configuration object related to the section is listed in parentheses next to each section name.
 
 There are dozens of config options for some of the sections, but the examples below are very minimal for the sake of simplicity.
 
 
-
 ### ENDPOINT
 
 (provided by module: res_pjsip)
@@ -88,7 +77,7 @@ callerid=Spaceman Spiff <6001>
 
 ```
 
-### **TRANSPORT**
+### TRANSPORT
 
 (provided by module: res_pjsip)
 
@@ -100,17 +89,14 @@ You can setup multiple transport sections and other sections (such as endpoints)
 * PJSIP does not allow multiple TCP or TLS transports of the same IP version (IPv4 or IPv6).
 
 
+/// info|Reloading Config
+Configuration for transport type sections can't be reloaded during run-time unless their `allow_reload` option is set to `yes` 
+///
 
 
-!!! info "**  **Reloading Config:"
-    Configuration for transport type sections can't be reloaded during run-time without a full module unload and load. You'll effectively need to restart Asterisk completely for your transport changes to take effect.
-
-      
-[//]: # (end-info)
-
-
+EXAMPLE BASIC CONFIGURATION
 
-EXAMPLE BASIC CONFIGURATIONA basic UDP transport bound to all interfaces
+A basic UDP transport bound to all interfaces
 
 ```
 [simpletrans]
@@ -136,13 +122,15 @@ method=
 
 ```
 
-### **AUTH**
+### AUTH
 
 (provided by module: res_pjsip)
 
 Authentication sections hold the options and credentials related to inbound or outbound authentication. You'll associate other sections such as endpoints or registrations to this one. Multiple endpoints or registrations can use a single auth config if needed.
 
-EXAMPLE BASIC CONFIGURATIONAn example with username and password authentication
+EXAMPLE BASIC CONFIGURATION
+
+An example with username and password authentication
 
 ```
 [auth6001]
@@ -164,17 +152,25 @@ username=6001
 
 ```
 
-### **AOR**
+### AOR
 
 (provided by module: res_pjsip)
 
-A primary feature of AOR objects (Address of Record) is to tell Asterisk where an endpoint can be contacted. Without an associated AOR section, an endpoint cannot be contacted. AOR objects also store associations to mailboxes for MWI requests and other data that might relate to the whole group of contacts such as expiration and qualify settings.
+A primary feature of AOR objects (Address of Record) is to tell Asterisk where an endpoint can be contacted. Without an associated AOR section, an endpoint cannot be contacted. AOR objects also store associations to mailboxes for MWI requests and other data that might relate to the whole group of contacts such as expiration and qualify settings.  Contact information can be provided one of two ways:
+
+/// define
+Statically
+
+- A `contact` parameter that contains a SIP URI can be added to an AOR.
+
+Dynamically
 
-When Asterisk receives an inbound registration, it'll look to match against available AORs.
+- A remote user agent can send a SIP REGISTER request to Asterisk that contains a Contact URI.  In this case, the name of the AOR section must match the user portion of the SIP URI in the "To:" header of the inbound SIP registration. That will usually be the "user name" set in your hard or soft phones configuration.
 
-**Registrations:** The name of the AOR section must match the user portion of the SIP URI in the "To:" header of the inbound SIP registration. That will usually be the "user name" set in your hard or soft phones configuration.
 
-EXAMPLE BASIC CONFIGURATIONFirst, we have a configuration where you are expecting the SIP User Agent (likely a phone) to register against the AOR. In this case, the contact objects will be created automatically. We limit the maximum contact creation to 1. We could do 10 if we wanted up to 10 SIP User Agents to be able to register against it.
+EXAMPLE BASIC CONFIGURATION
+
+First, we have a configuration where you are expecting the SIP User Agent (likely a phone) to register against the AOR. In this case, the contact objects will be created automatically. We limit the maximum contact creation to 1. We could do 10 if we wanted up to 10 SIP User Agents to be able to register against it.
 
 ```
 [6001]
@@ -201,13 +197,15 @@ contact=sip:203.0.113.1:5060
 
 ```
 
-### **REGISTRATION**
+### REGISTRATION
 
 (provided by module: res_pjsip_outbound_registration)
 
 The registration section contains information about an outbound registration. You'll use this when setting up a registration to another system whether it's local or a trunk from your ITSP.
 
-EXAMPLE BASIC CONFIGURATIONThis 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.
+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.
 
@@ -219,7 +217,6 @@ outbound_auth=mytrunk
 server_uri=sip:[email protected]:5060
 client_uri=sip:[email protected]:5060
 retry_interval=60
-
 ```
 
 And an example that may work with a SIP trunking provider
@@ -237,7 +234,7 @@ retry_interval=60
 
 What if you don't need to authenticate? You can simply omit the **outbound_auth** option.
 
-### **DOMAIN_ALIAS**
+### DOMAIN_ALIAS
 
 (provided by module: res_pjsip)
 
@@ -252,13 +249,15 @@ domain=example.com
 
 ```
 
-### **ACL**
+### ACL
 
 (provided by module: res_pjsip_acl)
 
 The ACL module used by 'res_pjsip'. This module is independent of 'endpoints' and operates on all inbound SIP communication using res_pjsip. Features such as an Access Control List, as defined in the configuration section itself, or as defined in **acl.conf**. ACL's can be defined specifically for source IP addresses, or IP addresses within the contact header of SIP traffic.
 
-EXAMPLE BASIC CONFIGURATIONA configuration pulling from the acl.conf file:
+EXAMPLE BASIC CONFIGURATION
+
+A configuration pulling from the acl.conf file:
 
 ```
 [acl]
@@ -291,13 +290,15 @@ contactpermit=209.16.236.1
 
 All of these configurations can be combined.
 
-### **IDENTIFY**
+### IDENTIFY
 
 (provided by module: res_pjsip_endpoint_identifier_ip)
 
 Controls how the res_pjsip_endpoint_identifier_ip module determines what endpoint an incoming packet is from. If you don't have an identify section defined, or else you have res_pjsip_endpoint_**identifier_ip** loading **after** res_pjsip_endpoint_**identifier_user**, then res_pjsip_endpoint_**identifier_user** will identify inbound traffic by pulling the user from the "From:" SIP header in the packet. Basically the module load order, and your configuration will both determine whether you identify by IP or by user.
 
-EXAMPLE BASIC CONFIGURATIONIts use is quite straightforward. With this configuration if Asterisk sees inbound traffic from 203.0.113.1 then it will match that to Endpoint 6001.
+EXAMPLE BASIC CONFIGURATION
+
+Its use is quite straightforward. With this configuration if Asterisk sees inbound traffic from 203.0.113.1 then it will match that to Endpoint 6001.
 
 ```
 [6001]
@@ -307,46 +308,32 @@ match=203.0.113.1
 
 ```
 
-### **CONTACT**
+### CONTACT
 
 (provided by module: res_pjsip)
 
 The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with an individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section. Manually configuring a CONTACT config object should not be needed, however. AORs with fixed remote hosts will create contacts upon AOR creation, and AORs that accept registrations will create contacts upon each accepted registration.
 
-Relationships of Configuration Objects in pjsip.conf
-----------------------------------------------------
+## Relationships of Configuration Objects in pjsip.conf
 
 Now that you understand the various configuration sections related to each config object, lets look at how they interrelate.
 
 You'll see that the new SIP implementation within Asterisk is extremely flexible due to its modular design. A diagram will help you to visualize the relationships between the various configuration objects. The following entity relationship diagram covers only the configuration relationships between the objects. For example if an **endpoint** object requires authorization for registration of a SIP device, then you may associate a single **auth** object with the endpoint object. Though many endpoints could use the same or different auth objects.
 
 **Configuration Flow**: This lets you know which direction the objects are associated to other objects. e.g. The identify config section has an option "endpoint=" which allows you to associate it with an endpoint object.
 
-
+![](res_sip_configrelationships.png)
 
 | Entity Relationships | Relationship Descriptions |
 | --- | --- |
-| res_sip_configrelationships25919621 | ENDPOINT* Many ENDPOINTs can be associated with many AORs
-* Zero to many ENDPOINTs can be associated with zero to one AUTHs
-* Zero to many ENDPOINTs can be associated with at least one TRANSPORT
-* Zero to one ENDPOINTs can be associated with an IDENTIFY
-
-REGISTRATION* Zero to many REGISTRATIONs can be associated with zero to one AUTHs
-* Zero to many REGISTRATIONs can be associated with at least one TRANSPORT
-
-AOR* Many ENDPOINTs can be associated with many AORs
-* Many AORs can be associated with many CONTACTs
-
-CONTACT* Many CONTACTs can be associated with many AORs
-
-IDENTIFY* Zero to One ENDPOINTs can be associated with an IDENTIFY object
-
-ACL, DOMAIN_ALIAS* These objects don't have a direct configuration relationship to the other objects.
- |
-
-Unfamiliar with ERD? Click here to see a key...![](ERD_key.PNG)
-
+| ENDPOINT|<ul><li>Many ENDPOINTs can be associated with many AORs<li>Zero to many ENDPOINTs can be associated with zero to one AUTHs<li>Zero to many ENDPOINTs can be associated with at least one TRANSPORT<li>Zero to one ENDPOINTs can be associated with an IDENTIFY</ul>|
+| REGISTRATION|<ul><li>Zero to many REGISTRATIONs can be associated with zero to one AUTHs<li>Zero to many REGISTRATIONs can be associated with at least one TRANSPORT</ul>|
+|AOR|<ul><li>Many ENDPOINTs can be associated with many AORs <li>Many AORs can be associated with many CONTACTs</ul>|
+|CONTACT|<ul><li>Many CONTACTs can be associated with many AORs</ul>|
+|IDENTIFY|<ul><li>Zero to One ENDPOINTs can be associated with an IDENTIFY object</ul>|
+|ACL, DOMAIN_ALIAS|<ul><li>These objects don't have a direct configuration relationship to the other objects.</ul>|
 
 
+Unfamiliar with ERD notation? Click [here](https://www.google.com/search?q=entity+relationship+diagram+symbols) for more info courtesy of Google Search.