Merge pull request #110 from Metaswitch/signalling-to-signaling

[Reviewer: Rob] Replace signalling with signaling

docs/Application_Server_Guide.md

@@ -8,7 +8,7 @@ What is an application server?
 
 An application server (AS) is a server which is brought into or notified of a call by the network in order to provide call features or other behaviour.
 
-In IMS, an application server is a SIP entity which is invoked by the S-CSCF for each dialog, both originating and terminating, as configured by the initial filter criteria (iFCs) of the relevant subscribers. The application server may reject or accept the call itself, redirect it, pass it back to the S-CSCF as a proxy, originate new calls, or perform more complex actions (such as forking) as a B2BUA. It may choose to remain in the signalling path, or drop out.
+In IMS, an application server is a SIP entity which is invoked by the S-CSCF for each dialog, both originating and terminating, as configured by the initial filter criteria (iFCs) of the relevant subscribers. The application server may reject or accept the call itself, redirect it, pass it back to the S-CSCF as a proxy, originate new calls, or perform more complex actions (such as forking) as a B2BUA. It may choose to remain in the signaling path, or drop out.
 
 The application server communicates with the IMS core via the ISC interface. This is a SIP interface. The details are given in [3GPP TS 24.229](http://www.3gpp.org/ftp/Specs/html-info/24229.htm), especially
 s5.4 (the S-CSCF side) and s5.7 (the AS side). Further useful information can be found in [3GPP TS

docs/Clearwater_Architecture.md

@@ -51,7 +51,7 @@ Traditional telco products achieve reliability using low-level data replication,
 
 The Clearwater approach to reliability is to follow common design patterns for scalable web services - keeping most components largely stateless and storing long-lived state in specially design reliable, scalable clustered data stores.
 
-Both Bono and Sprout operate as transaction-stateful rather than dialog-stateful proxies - transaction state is typically short-lived compared to dialog state. As the anchor point for client connections for NAT traversal, the Bono node used remains on the signalling path for the duration of a SIP dialog. Any individual Sprout node is only in the signalling path for the initial transaction, and subsequent requests are routed through the entire Sprout cluster, so failure of a Sprout node does not cause established SIP dialogs to fail. Long-lived SIP state such as registration data and event subscription state is stored in a clustered, redundant shared data store (memcached) so is not tied to any individual Sprout node.
+Both Bono and Sprout operate as transaction-stateful rather than dialog-stateful proxies - transaction state is typically short-lived compared to dialog state. As the anchor point for client connections for NAT traversal, the Bono node used remains on the signaling path for the duration of a SIP dialog. Any individual Sprout node is only in the signaling path for the initial transaction, and subsequent requests are routed through the entire Sprout cluster, so failure of a Sprout node does not cause established SIP dialogs to fail. Long-lived SIP state such as registration data and event subscription state is stored in a clustered, redundant shared data store (memcached) so is not tied to any individual Sprout node.
 
 Homer and Homestead similar only retain local state for pending requests - all long lived state is stored redundantly in the associated Cassandra cluster.
 

docs/Clearwater_IP_Port_Usage.md

@@ -40,12 +40,12 @@ All-in-one nodes need the following ports opened to the world
         TCP/80
         TCP/443
 
-* STUN signalling:
+* STUN signaling:
 
         TCP/3478
         UDP/3478
 
-* SIP signalling:
+* SIP signaling:
 
         TCP/5060
         UDP/5060
@@ -68,12 +68,12 @@ The Ellis node needs the following ports opened to the world:
 
 The Bono nodes need the following ports opened to the world:
 
-* STUN signalling:
+* STUN signaling:
 
         TCP/3478
         UDP/3478
 
-* SIP signalling:
+* SIP signaling:
 
         TCP/5060
         UDP/5060
@@ -85,15 +85,15 @@ The Bono nodes need the following ports opened to the world:
 
 They also need the following ports open to all other Bono nodes and to all the Sprout nodes:
 
-* Internal SIP signalling:
+* Internal SIP signaling:
 
         TCP/5058
 
 ## Sprout
 
 The Sprout nodes need the following ports open to all Bono nodes:
 
-* Internal SIP signalling:
+* Internal SIP signaling:
 
         TCP/5054
         TCP/5052 (if I-CSCF function is enabled)
@@ -188,7 +188,7 @@ They also need to following ports open to all other Ralf nodes:
 
 Standalone Project Clearwater application servers (e.g. Memento and Gemini) need the following ports open to all Sprout nodes:
 
-* SIP signalling:
+* SIP signaling:
 
         TCP/5054
 

docs/Configuring_an_Application_Server.md

@@ -19,7 +19,7 @@ Bono in both directions.
 
  * The application server must also be able to exchange SIP messages
    (in both directions) with any other application server that may appear in
-   the signalling path of any call going through it.
+   the signaling path of any call going through it.
 
  * Since the application server is in the trusted zone, it should
    *not* be accessible to untrusted SIP entities.
@@ -35,7 +35,7 @@ No special application server configuration is required.
 
  * Your application server should be prepared to accept SIP messages
    from any of your deployment's bono or sprout nodes, and from any
-   SIP entity that may appear in the signalling path of any call going
+   SIP entity that may appear in the signaling path of any call going
    through it.
 
  * If your application server needs to spontaneously originate calls,

docs/Multiple_Network_Support.md

@@ -2,15 +2,15 @@
 
 ## Introduction
 
-As of the Ultima release, Project Clearwater can be configured to provide signalling service (SIP/HTTP/Diameter) on a separate physical (or virtual) network to management services (SNMP/SSH/Provisioning).  This may be used to protect management devices (on a firewalled network) from attack from the outside world (on the signalling network).
+As of the Ultima release, Project Clearwater can be configured to provide signaling service (SIP/HTTP/Diameter) on a separate physical (or virtual) network to management services (SNMP/SSH/Provisioning).  This may be used to protect management devices (on a firewalled network) from attack from the outside world (on the signaling network).
 
 ## Technical Details
 
 ### Network Independence
 
-If traffic separation is configured, the management and signalling networks are accessed by the VM via completely separate (virtual) network interfaces.
+If traffic separation is configured, the management and signaling networks are accessed by the VM via completely separate (virtual) network interfaces.
 
-The management and signalling networks may be completely independent.
+The management and signaling networks may be completely independent.
 
  * There need not be any way to route between them.
  * The IP addresses, subnets and default gateways used on the networks may be the same, may overlap or may be completely distinct.
@@ -29,7 +29,7 @@ The following traffic is carried over the management interface:
  * Ellis provisioning API
  * M/Monit
 
-The following traffic is carried over the signalling interface:
+The following traffic is carried over the signaling interface:
 
  * DNS (for signaling traffic)
  * ENUM
@@ -56,21 +56,21 @@ Due to the varied complexities of IP networking, it would be impractical to atte
 
 The following example commands (when run as root) create a network namespace, move `eth1` into it, configure a static IP address and configure routing.
 
-    ip netns add signalling
-    ip link set eth1 netns signalling
-    ip netns exec signalling ifconfig lo up
-    ip netns exec signalling ifconfig eth1 1.2.3.4/16 up
-    ip netns exec signalling route add default gateway 1.2.0.1 dev eth1
+    ip netns add signaling
+    ip link set eth1 netns signaling
+    ip netns exec signaling ifconfig lo up
+    ip netns exec signaling ifconfig eth1 1.2.3.4/16 up
+    ip netns exec signaling route add default gateway 1.2.0.1 dev eth1
 
-Obviously you should make any appropriate changes to the above to correctly configure your chosen signalling network.  These changes are **not** persisted across reboots on Linux and you should ensure that these are run on boot before the `clearwater-infrastructure` service is run.  A sensible place to configure this would be in `/etc/rc.local`.
+Obviously you should make any appropriate changes to the above to correctly configure your chosen signaling network.  These changes are **not** persisted across reboots on Linux and you should ensure that these are run on boot before the `clearwater-infrastructure` service is run.  A sensible place to configure this would be in `/etc/rc.local`.
 
-Finally, you should create `/etc/netns/signalling/resolv.conf` configuring the DNS server you'd like to use on the signalling network.  The format of this file is documented at <http://manpages.ubuntu.com/manpages/trusty/man5/resolv.conf.5.html> but a simple example file might just contain the following.
+Finally, you should create `/etc/netns/signaling/resolv.conf` configuring the DNS server you'd like to use on the signaling network.  The format of this file is documented at <http://manpages.ubuntu.com/manpages/trusty/man5/resolv.conf.5.html> but a simple example file might just contain the following.
 
     nameserver <DNS IP address>
 
 ### Project Clearwater Configuration
 
-Now that the signalling namespace is configured and has networking set up, it's time to apply it to Project Clearwater.  To do this, change the `local_ip`, `public_ip` and `public_hostname` lines in `/etc/clearwater/local_config` to refer to the node's identities in the signaling network and add the following lines:
+Now that the signaling namespace is configured and has networking set up, it's time to apply it to Project Clearwater.  To do this, change the `local_ip`, `public_ip` and `public_hostname` lines in `/etc/clearwater/local_config` to refer to the node's identities in the signaling network and add the following lines:
 
     signaling_namespace=<namespace name>
     signaling_dns_server=<DNS IP address>
@@ -82,7 +82,7 @@ If you've already installed the Project Clearwater services, run `sudo service c
 
 ## Diagnostic Changes
 
-All the built-in Clearwater diagnostics will automatically take note of network namespaces, but if you are running diagnostics yourself (e.g. following instructions from the [troubleshooting page](http://clearwater.readthedocs.org/en/latest/Troubleshooting_and_Recovery)) you may need to prefix your commands with `ip netns exec <namespace>` to run them in the signalling namespace.  The following tools will need this prefix:
+All the built-in Clearwater diagnostics will automatically take note of network namespaces, but if you are running diagnostics yourself (e.g. following instructions from the [troubleshooting page](http://clearwater.readthedocs.org/en/latest/Troubleshooting_and_Recovery)) you may need to prefix your commands with `ip netns exec <namespace>` to run them in the signaling namespace.  The following tools will need this prefix:
 
  * `cqlsh` - For viewing Cassandra databases
  * `nodetool` - For viewing Cassandra status