Documentation

= SIP Thor description =

[[TOC(SipThorDescription, SipThorPreparations, SipThorInstallation, depth=2)]]

SIP Thor provides scalability and resilience for [wiki:MSPPreparations Multimedia Service Platform]

components. A SIP Thor platform is using the same software components for

the interfaces with the end-user SIP devices like SIP Proxy and Media Proxy

used by [wiki:MSPPreparations Multimedia Service Platform] but it is using a different architecture

to achieve the scalability and resilience in case of failure.

SIP Thor creates an overlay across multiple IP addresses that can run in

different locations, like different data centers or cities or countries. On

each node different software can run to perform a different service (like

SIP Registrar). The sum of all nodes provide a consolidated platform that can

automatically deal with the addition and removal of nodes.

SIP Thor is running fully automatic once in service, there is no need for

monitoring or administrating it as its main purpose is to automatically

self-heal in case of failures. The only parameter that the operator needs to

monitor in a SIP Thor network is the number of active servers that serve a

certain role.

[[Image(http://www.ag-projects.com/images/stories/ag_images/thor-platform-big.png, width=500)]]

SIP Thor architecture introduces several new components to the Multimedia Service Platform. To implement its functions SIP Thor implements a dynamic overlay of several logical network entities called '''roles''' installed on multiple physical machines called '''nodes'''. Each node can run one or multiple roles. An example of such role is '''sip_proxy''' or '''media_relay'''. Nodes that advertise SIP Proxy or Media Relay capabilities, will handle the load associated with the SIP and RTP traffic respectively and will inherit the built-in resilience and load distribution provided by SIP Thor design.

== Scalability ==

SIP Thor is designed around the concept of super peers, a flat level logical network for each role. The peers are dedicated servers that handle native SIP clients that are unaware of the overlay logic employed by the servers. Internally to the network software, the lookup of a resource (a node that handles a certain subscriber for a given role at the moment of the query) is a one step lookup in a hash table and the call flow of any application that uses SIP Thor involves a maximum of two nodes regardless of the number of nodes, subscribers or devices handled by the SIP Thor network. Shall SIP devices be SIP Thor aware and able to make lookups in the overlay, this could greatly improve the scalability of the overal system as less SIP traffic and less queries will be generated through the network.

The current implementation allows SIP Thor to grow to accomodate thousands of servers, which can handle the traffic of any size of a real-time communication service deployable in the real world (e.g. if a  SIP Proxy/Registrar server implementation can handle 100K subscribers, 100 nodes (roughly the equivalent of three 19 inch racks of data center equipment) are required to handle 10 million subscribers. The service scalability is in reality limited by the performance of accounting sub-system used by the operator.

== Load sharing ==

SIP Thor is designed to share the traffic equally between all available nodes. This is done by simply returning a random limited slice of the DNS records, which are managed internally by a special role '''thor-dns''' on multiple nodes assigned as DNS servers in the network. This simple DNS query/response mechanism achieves a near perfect distribution without introducing any intermediate load balancer.

== Security ==

All communication between the nodes of the SIP Thor network is encrypted by using Transport Level Security (TLS). Each node part of the SIP Thor network is uniquely identified by a X.509 certificate provisioned by the operator of the platform. The X.509 certificate and various attributes it contains are used for authentication and authorization of the nodes when they exchange overlay messages within SIP Thor network. 

== Thor Event server ==

'''thor-eventserver''' is an event server, which is the core of the messaging system that is used by the SIP Thor network to implement communication between the network

members.  The  messaging  system  is based on publish/subscribe messages that are exchanged between network members.  Each entity in the network publishes its own

capabilities and status for whomever is interested in the information. At the same time each entity may subscribe to certain types of information which  is  published by the other network members based on the entity's functionality in the network.

Multiple event servers can be run as part of a SIP Thor network (on different systems, that are preferably in different hosting facilities) which will improve the

redundancy of the SIP Thor network and its resilience in the face of network/system failures, at the expense of linearly increasing the  messaging  traffic  with

the number of the network members. It is recommended to run at least 3 event servers in a given SIP Thor network.

== Thor Manager ==

'''thor-manager''' is the SIP Thor network manager, which has the role of maintaining the consistency of the SIP Thor network as members join and leave the network. The manager  will  publish  the  SIP  Thor  network status regularly, or as events occur to inform all network members of the current network status, allowing them to adjust their internal state as the network changes.

Multiple managers can be run as part of a SIP Thor network (on different systems, that are preferably in different hosting  facilities), which  will  improve  the redundancy  of  the  SIP Thor network and its resilience in the face of network/system failures, at the expense of a slight increase in the messaging traffic with each new manager that is added. If multiple managers are run, they will automatically elect one of them as the active one and the others will be  idle until the active manager stops working or leaves the network. Then a new manager is elected and becomes the active manager.  It is recommended to run at least 3 managers in a given SIP Thor network preferably in separate hosting facilities.

== Thor Database ==

'''thor-database''' is a component of the SIP Thor network that runs on the central database(s) used by the SIP Thor network. Its purpose is to publish the location of the provisioning database in the network, so that other SIP Thor network members know where to find the central database if they need to access information from it.

== Thor DNS ==

'''thor-dns''' is a component of the SIP Thor network that runs on the authoritative name servers for the SIP Thor domain. Its purpose is to keep the  DNS  entries for the SIP Thor network in sync with the network members that are currently online. Each authoritative name-server needs to run a copy of the DNS manager in combination with a DNS server. The SIP Thor DNS manager will update the DNS backend database with the appropriate records as nodes join/leave the SIP Thor network,  making  it reflect the network status in realtime.

== Thor Node ==

'''thor-node''' is to be run on a system that wishes to become a SIP Thor network member. By running this program, the system will join the SIP Thor network and  become part of it, sharing its resources and announcing its capabilities to the other SIP Thor network members.

The network can accomodate one or more nodes with this role, SIP Thor takes care automatically of the additions and removal of each instance. The currently supported roles are '''sip_proxy''' in combination with OpenSIPS and '''voicemail_server''' in combination with Asterisk. Other roles are directly built in MediaProxy ('''media_relay'''), NGNPro ('''provisioning_server''') and OpenXCAP ('''xcap_server'''), for these resources no thor-node standalone component is required. 

== Thor Monitor ==

'''thor-monitor''' is a utility that shows the SIP Thor network state in a terminal. It can be used to monitor the SIP Thor network status and events. Example:

{{{

SIP Thor network for sipthor.net at 01:33:54 Sun 20 Sep 2009:

-------------------------------------------------------------

  media_relay members:

    81.23.228.129  

    81.23.228.150  

    85.17.186.6    

    85.17.186.7    

  provisioning_server members:

    81.23.228.144  

    81.23.228.164  

  sip_proxy members:

    81.23.228.129  

    81.23.228.150  

    85.17.186.7    

  thor_database members:

    10.0.0.131      priority=10  mysql://sipthor:xxxxxx@db-log.dns-hosting.info/sipthor

    10.0.0.132      priority=10  mysql://sipthor:xxxxxx@db-log.dns-hosting.info/sipthor

    85.17.186.8     priority=50  mysql://sipthor:xxxxxx@10.30.30.8/sipthor

  thor_dnsmanager members:

    80.247.197.195 

    81.23.228.150  

    85.17.186.8    

  thor_manager members:

    81.23.228.150   priority=50 

    85.17.186.8     priority=50 

  thor_monitor members:

    81.23.228.150   myself

  voicemail_server members:

    81.23.228.143  

  xcap_server members:

    81.23.228.144  

    81.23.228.164  

}}}

== NGNPro ==

NGNPro component performs the provisioning server role. It saves all changes persistently in the bootstrap database and caches the data on the responsable node at the moment of the change. The network can accomodate multiple nodes with this role, SIP Thor takes care automatically of the additions and removal of each instance.

NGNPro exposes a [wiki:ProvisioningGuide SOAP/XML interface] to the outside world and bridges them with the distributed data structures employed by SIP Thor nodes.

== New roles ==

Adding new roles to the system can be realized programatically by obeying to the SIP Thor API and depending on the way of working of the component that needs to be integrated in the SIP Thor network. In any case the software will need to implement a component that publishes its availability in the network (this task can be programmed outside of the specific software by adding it to the generic thor_node configuration and logic) and must be able to lookup resources in the SIP Thor network and use the results of a lookup  in its own application logic. Depending of the inner-working of the application performed by the new role, other roles may need  to be updated in order to serve it (e.g. adding specific entries into the DNS or moving provisioning data).