SipX SW Architecture & Library Dependencies
From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia
| Important note: This page is work in progress |
Contents |
[edit] sipX Servers
The sipX IP PBX solution consists of 9 application servers and 6 libraries.
Application Servers: Forking Proxy & Authentication Proxy (sipXproxy), Registrar (sipXregistry), Media Server (sipXvxml), Status Server (sipXpublisher), Park Server, Presence Server, and Conference Server (sipXpbx). In addition there is a watchdog application (sipXpbx). The Configuration Server (sipXconfig) is the management and configuration application.
Library Components: sipXportlib, sipXtacklib, sipXmedialib, sipXmediaadapterlib, sipXcommserverlib, and sipXcalllib.
Forking and authentication proxies and the registrar are referred to as the sipX Communications Server.
The sipXpbx project currently includes more than one application (Status Server, Presence Server, Park Server, as well as the Web UI for the Media Server and the watchdog application). You should expect this to be broken out at some point.
The original objective of the sipX project was to build a complete SIP based communications infrastructure that can be easily installed and maintained on a single server. A single file install script simplifies the installation process which otherwise would be much more involved. Starting with release 3.2 sipX became a fully distributed system. The objective of the HA implementation was to create a fully redundant highly available system. The proxy servers can be load balanced using DNS SRV, but prior to release 3.2 the registrar remained a single point of failure. Release 3.2 removed that constraint and provided a fully redundant Communications Server with real-time synchronization between different (initially 2) instances of the registrar.
[edit] The sipX Communications Server
|
|
The sipX Communications Server consists of three applications that together form a highly configurable SIP call router.
Forking Proxy Server: The sipX forking proxy server performas two primary functions: a) Serial and parallel forking of calls, and b) service level routing. The forking is controlled by the Q values in the Contact headers of the 3xx class responses that it receives. The forking proxy recurses the 3xx Contacts by sorting them highest to lowest. The Contacts are then recursed or forked in order of the Q values. Any Q value for which there are multiple contacts are pursued in parallel. Otherwise the Contacts are pursued serially. The service level routing is controlled by an xml file: forwardingrules.xml This file has constructs to define service level routing for SIP requests within the local domain of the proxy. These constructs allow routing decisions based upon the URI host/domain, SIP request METHOD, or header value regular expressions. The next hop routing is directed by the xml constructs and performed by inserting the loose route specified by the xml construct. Simply put, the sipproxy uses forwardingrules.xml to forward messages to the sipregistrar, which in turn follows fallbackrules.xml to send the messages to the PSTN gateway. |
Authentication Proxy Server: The auth proxy performs AAA services (authentication, authorization and accounting). The auth proxy is primarily used to restrict access to a SIP entity within the local domain. The auth proxy relys upon the restricted entity having an access control list that prevents other SIP entities from accessing it without going through the auth proxy. The auth proxy record routes all SIP requests so that it remains in the path for dialogs and continues to gate traffic to the restricted entity. For this reason the auth proxy is also a great place to observer transaction and dialog state within the system. Currently the auth proxy only performs accounting in the form of SIP message logging in the syslog. It does not create any explicit CDR records. The auth proxy uses a number of xml files to perform its functions:
- authrules.xml: File containing xml constructs which define whether to authenticate a message based upon its next hop URI. The xml constructs also specify what authorization or permission the user must have to send this request.
- crediential.xml: File containing user MD5 digest credentials used for authentication of of SIP requests.
- permission.xml: File with elements containing the permissions or authorization privilege that each user possesses.
The auth proxy uses the In Memory DataBase (IMDB) from the sipXcommserverLib project. The IMDB reads the credential.xml and permission.xml files and creates memory based tables for fast access to this data. The IMDB can be updated externally from the auth proxy processes to modify the data live without shutting down the auth proxy. The authrules.xml file is read at start up, but is not stored in the IMDB. The auth proxy must be restarted to make authrules.xml changes effective.
Registrar Server: A SIP Registrar is a server that accepts REGISTER requests and places the information it receives from registering clients into the location service database for the domain it handles.
Placing a SIP call involves a discovery capability where SIP must discover the host(s) or user agents at which the destination user is currently reachable. This discovery process is accomplished by the SIP proxy / redirect server using data provided by the registrar. The registrar's location service therefore provides address bindings for a particular domain.
[edit] The sipX Application Servers
Dale wrote: One feature which is already in the architecture of sipXvxml is that it is separated into two parts -- a VXML execution engine (sipXvxml itself) and an HTTP-based store (with a lot of CGIs). The VXML execution engine does not access its host's disk, and you should be able to run multiple copies on multiple servers, all accessing one HTTP store. (Use DNS SRV records to load-balance the copies of sipXvxml.) In principle, this should increase your maximum users because a lot of the CPU and memory on a unified sipXvxml server are taken up converting the audio to/from RTP.
Configuring such a system could be troublesome, because nobody has done it before. You also need to work out how the sipXvxml's authenticate themselves to the HTTP server. The server must be secured as otherwise anybody on the Internet can listen to your voicemail. Currently the security policy is "the request must come from 127.0.0.1".
[edit] The sipX Configuration Server
