Merge pull request #2 from Metaswitch/lists_fix

Fix lists and links
Metaswitch · Feb 7, 2015 · ef49757 · ef49757
2 parents c1411af + d29ca3b
commit ef49757
Show file tree

Hide file tree

Showing 57 changed files with 280 additions and 278 deletions.
diff --git a/docs/All in one EC2 AMI Installation.md → docs/All_in_one_EC2_AMI_Installation.md b/docs/All in one EC2 AMI Installation.md → docs/All_in_one_EC2_AMI_Installation.md
@@ -1,14 +1,15 @@
 # All-in-one EC2 AMI Installation
 
-This pages describes how to launch and run an [all-in-one image](All-in-one Images) in Amazon's EC2 environment.
+This pages describes how to launch and run an [all-in-one image](All_in_one_Images) in Amazon's EC2 environment.
 
 ## Launch Process
 
 Project Clearwater's all-in-one node is already available as a pre-built AMI, which can be found in the Community AMIs list on the US East region of EC2.  Launching this follows exactly the same process as for other EC2 AMIs.
 
-Before you launch the node, you will need an EC2 keypair, and a security group configured to provide access to the [required ports](Clearwater IP Port Usage).
+Before you launch the node, you will need an EC2 keypair, and a security group configured to provide access to the [required ports](Clearwater_IP_Port_Usage).
 
 To launch the node
+
 *  From the EC2 console, make sure you're in the US East region, then select "Instances", "Launch instance" and then "Classic Wizard"
 *  Select the "Community AMIs" tab, and search for "Clearwater"
 *  Press "Select" for the Clearwater all-in-one AMI. Take the most recent version unless you have a good reason not to.
@@ -21,4 +22,4 @@ On the last page, press "Launch", and wait for the node to be started by EC2.
 
 Once the node has launched, you can SSH to it using the keypair you supplied at launch time, and username `ubuntu`.
 
-You can then try [making your first call](Making your first call) and [running the live tests](Running the live tests) - for these you will need the signup key, which is `secret`.  You will probably want to change this to a more secure value - see ["Modifying Clearwater settings"](Modifying Clearwater settings) for how to do this.
+You can then try [making your first call](Making_your_first_call) and [running the live tests](Running_the_live_tests) - for these you will need the signup key, which is `secret`.  You will probably want to change this to a more secure value - see ["Modifying Clearwater settings"](Modifying_Clearwater_settings) for how to do this.
diff --git a/docs/All in one Images.md → docs/All_in_one_Images.md b/docs/All in one Images.md → docs/All_in_one_Images.md
@@ -1,12 +1,13 @@
 # All-in-one Images
 
-While Clearwater is designed to be massively horizontally scalable, it is also possible to install all Clearwater components on a single node.  This makes installation much simpler, and is useful for familiarizing yourself with Clearwater before moving up to a larger-scale deployment using one of the [other installation methods](Installation Instructions).
+While Clearwater is designed to be massively horizontally scalable, it is also possible to install all Clearwater components on a single node.  This makes installation much simpler, and is useful for familiarizing yourself with Clearwater before moving up to a larger-scale deployment using one of the [other installation methods](Installation_Instructions).
 
 This page describes the all-in-one images, their capabilities and restrictions and the installation options available.
 
 ## Images
 
 All-in-one images consist of
+
 *   Ubuntu 12.04, configured to use DHCP
 *   bono, sprout, homestead, homer and ellis
 *   Clearwater auto-configuration scripts.
@@ -20,6 +21,7 @@ The image is designed to run on a virtual machine with a single core, 1.7GB RAM
 Since the all-in-one images include all of bono, sprout, homestead, homer and ellis, they are capable of almost anything a full deployment is capable of.
 
 The key restrictions of all-in-one images are
+
 *   hard-coded realm - the all-in-one image uses a hard-coded realm of `example.com` so your SIP URI might be `sip:6505551234@example.com` - by default, SIP uses this realm for routing but `example.com` won't resolve to your host so you need to configure an outbound proxy on all your SIP clients (more details later)
 *   performance - since all software runs on a single virtual machine, performance is significantly lower than even the smallest scale deployment
 *   scalability - there is no option to scale up and add more virtual machines to boost capacity - for this, you must create a normal deployment
@@ -29,8 +31,8 @@ The key restrictions of all-in-one images are
 
 All-in-one images can be installed on EC2 or on your own virtualization platform, as long as it supports [OVF (Open Virtualization Format)](http://dmtf.org/standards/ovf).
 
-*   To install on EC2, follow the [all-in-one EC2 AMI installation instructions](All-in-one EC2 AMI Installation).
-*   To install on your own virtualization platform, follow the [all-in-one OVF installation instructions](All-in-one OVF Installation).
+*   To install on EC2, follow the [all-in-one EC2 AMI installation instructions](All_in_one_EC2_AMI_Installation).
+*   To install on your own virtualization platform, follow the [all-in-one OVF installation instructions](All_in_one_OVF_Installation).
 
 ## Manual Build
 
@@ -39,8 +41,7 @@ If your virtualization platform is not EC2 and doesn't support OVF, you may stil
 1.  install [Ubuntu 12.04 - 64bit server edition](http://releases.ubuntu.com/precise/)
 2.  find the `preseed/late_command` entry in the [all-in-one image's install script](https://github.com/Metaswitch/clearwater-vm-images/blob/master/ubuntu-ovf/ubuntu-server.seed) - as of writing this is as follows, but please check the linked file for the latest version
 
-```
-d-i preseed/late_command string in-target bash -c '{ echo "#!/bin/bash" ; \
+         d-i preseed/late_command string in-target bash -c '{ echo "#!/bin/bash" ; \
                                                      echo "set -e" ; \
                                                      echo "repo=... # filled in by make_ovf.sh" ; \
                                                      echo "echo deb \$repo binary/ > /etc/apt/sources.list.d/clearwater.list" ; \
@@ -55,8 +56,7 @@ d-i preseed/late_command string in-target bash -c '{ echo "#!/bin/bash" ; \
                                                      echo "rm /etc/rc2.d/S99zclearwater-aio-first-boot" ; \
                                                      echo "poweroff" ; } > /etc/rc2.d/S99zclearwater-aio-first-boot ; \
                                                    chmod a+x /etc/rc2.d/S99zclearwater-aio-first-boot'
-```
 
 3.  run the command (stripping the `d-i preseed/late_command string in-target` prefix, filling in the repo variable - the default is `http://repo.cw-ngv.com/stable`, and stripping the `\`) - this will create an `/etc/rc2.d/S99zclearwater-aio-first-boot` script
 4.  run the `/etc/rc2.d/S99zclearwater-aio-first-boot` script - this will install the all-in-one software and then shutdown (ready for an image to be taken)
-4.  restart the node.
+4.  restart the node.
diff --git a/docs/All-in-one OVF Installation.md → docs/All_in_one_OVF_Installation.md b/docs/All-in-one OVF Installation.md → docs/All_in_one_OVF_Installation.md
@@ -1,10 +1,11 @@
 # All-in-one OVF Installation
 
-This pages describes how to install an [all-in-one image](All-in-one Images) on your own virtualization platform using [OVF (Open Virtualization Format)](http://dmtf.org/standards/ovf).
+This pages describes how to install an [all-in-one image](All_in_one_Images) on your own virtualization platform using [OVF (Open Virtualization Format)](http://dmtf.org/standards/ovf).
 
 ## Supported Platforms
 
 This process should work on any virtualization platform that supports OVFs using x86-64 CPUs, but has only been tested on
+
 *   [VMware Player](http://www.vmware.com/products/player/)
 *   [VirtualBox](https://www.virtualbox.org/)
 *   [VMware ESXi](http://www.vmware.com/products/vsphere-hypervisor/overview.html).
@@ -30,8 +31,9 @@ Once you've installed the virtual machine, you should start it in the usual way
 If you attach to the console, you should see an Ubuntu loading screen and then be dropped at a `cw-aio` login prompt.  The username is `ubuntu` and the password is `cw-aio`.  Note that the console is hard-coded to use a US keyboard, so if you have a different keyboard you might find that keys are remapped - in particular the `-` key.
 
 The OVF provides 3 network services.
+
 *   SSH - username is `ubuntu` and password is `cw-aio`
-*   HTTP to ellis for subscriber management - sign-up code is `secret`. You will probably want to change this to a more secure value - see ["Modifying Clearwater settings"](Modifying Clearwater settings) for how to do this.
+*   HTTP to ellis for subscriber management - sign-up code is `secret`. You will probably want to change this to a more secure value - see ["Modifying Clearwater settings"](Modifying_Clearwater_settings) for how to do this.
 *   SIP to bono for call signaling - credentials are provisioned through ellis.
 
 How these network services are exposed can vary depending on the capabilities of the platform.
@@ -42,4 +44,4 @@ How these network services are exposed can vary depending on the capabilities of
 
 *   VMware ESXi runs the host as normal on the network, so you can connect to it directly.  To find out its IP address, log in over the console and type `hostname -I`.  To access ellis, just point your browser at this IP address.  To register over SIP, you'll need to configure an outbound proxy for this IP address.
 
-Once you've successfully connected to ellis, try [making your first call](Making your first call) - just remember to configure the SIP outbound proxy as discussed above.
+Once you've successfully connected to ellis, try [making your first call](Making_your_first_call) - just remember to configure the SIP outbound proxy as discussed above.
diff --git a/docs/Application Server Guide.md → docs/Application_Server_Guide.md b/docs/Application Server Guide.md → docs/Application_Server_Guide.md
@@ -1,7 +1,7 @@
 Application Server Guide
 ========================
 
-You can add new call features or functionality to calls by adding an application server.  Clearwater supports application servers through the standard IMS interface ISC. This article explains the features and limitations of this support. See [Configuring an Application Server](Configuring an Application Server) for details of how to configure Clearwater to use this function, or [Plivo](Plivo) for an open-source application server/framework to work with.
+You can add new call features or functionality to calls by adding an application server.  Clearwater supports application servers through the standard IMS interface ISC. This article explains the features and limitations of this support. See [Configuring an Application Server](Configuring_an_Application_Server) for details of how to configure Clearwater to use this function, or [Plivo](Plivo) for an open-source application server/framework to work with.
 
 What is an application server?
 ==============================
@@ -22,15 +22,15 @@ Clearwater interfaces
 In Clearwater most S-CSCF function, including the ISC interface, is implemented in Sprout. Sprout invokes application servers over the ISC interface, as specified in the iFCs.
 
  * Per the IMS specs, this invocation occurs on dialog-initiating requests such as INVITE, SUBSCRIBE, MESSAGE, etc, and according to the triggers within the iFCs (s5.4.3.2, s5.4.3.3):
-   * When specified, Sprout will route the message to the AS; the AS can either route it onward, act as a B2BUA for e.g. call diversion, or give a final response.
-   * Clearwater has full support for chained iFCs. The original dialog is tracked by Sprout using an ODI token in the Route header. This support includes support for forking ASs at any point in the chain.
-   * Service trigger points (i.e., conditions) are implemented, including SIP method, SIP headers, SDP lines, registration parameters, and request URIs.
-   * Service trigger points can have session case configuration, allowing the AS to only be invoked on originating calls or on terminating calls.
+    * When specified, Sprout will route the message to the AS; the AS can either route it onward, act as a B2BUA for e.g. call diversion, or give a final response.
+    * Clearwater has full support for chained iFCs. The original dialog is tracked by Sprout using an ODI token in the Route header. This support includes support for forking ASs at any point in the chain.
+    * Service trigger points (i.e., conditions) are implemented, including SIP method, SIP headers, SDP lines, registration parameters, and request URIs.
+    * Service trigger points can have session case configuration, allowing the AS to only be invoked on originating calls or on terminating calls.
  * No per-AS configuration is required; ASs are invoked simply by their URI appearing in the iFCs.
  * AS invocation also occurs on REGISTER - this is called third-party registration (3GPP TS 24.229 s5.4.1.7 and 7A):
-   * When a UE registers with Sprout, if the iFCs require it, it passes a third-party registration onto an AS.
-   * Message body handling for third-party registration, per 3GPP TS 24.229 s5.4.1.7A: including optionally service info, a copy of the registration, and a copy of the response.
-   * Network-initiated deregister. If the third-party registration fails and the iFC requests it, we must deregister the UE.
+    * When a UE registers with Sprout, if the iFCs require it, it passes a third-party registration onto an AS.
+    * Message body handling for third-party registration, per 3GPP TS 24.229 s5.4.1.7A: including optionally service info, a copy of the registration, and a copy of the response.
+    * Network-initiated deregister. If the third-party registration fails and the iFC requests it, we must deregister the UE.
 
 Supported SIP headers
 ---------------------
@@ -45,23 +45,23 @@ Points of Note
 --------------
 
  * Trust:
-   - Some ISC signaling is trust-dependent. For Clearwater, all ASs are trusted - we think support for untrusted ASs is unlikely to be required.
+     * Some ISC signaling is trust-dependent. For Clearwater, all ASs are trusted - we think support for untrusted ASs is unlikely to be required.
  * IP Connectivity
-   - We assume that there is no NAT (static or otherwise) between the AS and the Clearwater core.
+     * We assume that there is no NAT (static or otherwise) between the AS and the Clearwater core.
 
 Current Spec Deltas
 -------------------
 
 **The December 2013 release of Clearwater has the following limitation on the ISC interface:**
 
  * Dead AS handling:
-   - Handling of dead ASs (408, 5xx, or no response, not preceded by a 1xx response) should follow the spec: per the iFC, either the response is treated as final or the AS is bypassed.
-   - Clearwater does not attempt to avoid dead ASs on subsequent calls.
+     * Handling of dead ASs (408, 5xx, or no response, not preceded by a 1xx response) should follow the spec: per the iFC, either the response is treated as final or the AS is bypassed.
+     * Clearwater does not attempt to avoid dead ASs on subsequent calls.
  * Change of request URI:
-   - 3GPP TS 24.229 s5.4.3.3 step 3 allows a terminating AS to change the request URI to another URI that matches it (i.e., is canonically equal or an alias) without interrupting the interpretation of the iFCs.
-   - Clearwater only supports this for URIs which are canonically equal; it does not support changing to an alias URI (i.e., a different public identity belonging to the same alias group of the same private identity, per 3GPP TS 24.229 s3.1, 3GPP TS 29.228 sB.2.1).
+     * 3GPP TS 24.229 s5.4.3.3 step 3 allows a terminating AS to change the request URI to another URI that matches it (i.e., is canonically equal or an alias) without interrupting the interpretation of the iFCs.
+     * Clearwater only supports this for URIs which are canonically equal; it does not support changing to an alias URI (i.e., a different public identity belonging to the same alias group of the same private identity, per 3GPP TS 24.229 s3.1, 3GPP TS 29.228 sB.2.1).
  * `Request-Disposition: no-fork` (3GPP TS 24.229 s5.4.3.3 step 10, s5.7.3, RFC 3841)
-   - Clearwater ignores this directive - it always INVITEs all registered endpoints.
+     * Clearwater ignores this directive - it always INVITEs all registered endpoints.
 
 Future phases
 -------------
@@ -98,6 +98,6 @@ Clearwater has a built-in application server, `mmtel.<deployment-domain>`, which
  * Communication Diversion (CDIV)
  * Communication Barring (CB)
 
-Note that Clearwater is also able to support a number of other IR.92 services, either through inherent support (by transparently passing messages between UEs) or through integration with external application servers.  See the [IR.92 Supplementary Services document](IR.92-Supplementary-Services) for more information.
+Note that Clearwater is also able to support a number of other IR.92 services, either through inherent support (by transparently passing messages between UEs) or through integration with external application servers.  See the [IR.92 Supplementary Services document](IR.92_Supplementary_Services) for more information.
 
-The built-in MMTEL application server is invoked only for calls configured to use it. To use it, simply configure a subscriber's iFCs to indicate the use of `mmtel.<deployment-domain>` as an application server. The MMTEL application server can be used on its own, or as one of a chain of application servers handling a call.  The default iFCs configured by Ellis specify that the built-in MMTEL application server should be used for all originating and terminating calls.
+The built-in MMTEL application server is invoked only for calls configured to use it. To use it, simply configure a subscriber's iFCs to indicate the use of `mmtel.<deployment-domain>` as an application server. The MMTEL application server can be used on its own, or as one of a chain of application servers handling a call.  The default iFCs configured by Ellis specify that the built-in MMTEL application server should be used for all originating and terminating calls.