Child pages
  • System Architecture Diagrams

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



sipXcom System Architecture Diagram

The sipXecs sipXcom system is built based on a modular architecture with different components that communicate over TCP/IP for the most part.


  • Modular: 12 different server components that can coexist on one server HW or be distributed to different systems
  • Resilient: Offers HA redundancy between call control components
  • Scalability: Load balancing using the DNS SRV system
  • SIP Proxy based: sipXecs sipXcom is not based on a B2BUA but implements a true SIP proxy architecture
  • B2BUA server (sipXbridge) for connecting to Internet Telephony Service Providers (ITSPs) (not recommended for HA or production)
  • Conference bridge included in package
  • Freeswitch based Auto Attendant and Voicemail integrated
  • Better Voice Quality: Media goes direct point-to-point between the end points and never through the call control system
  • Standard SIP: sipXecs sipXcom is all about a standards compliant implementation
  • Plug & Play Management: Phones are managed plug & play from within the system
  • IT Integration: LDAP, SOAP, and database integration. System looks like and operates like an IT application
  • No Special HW: sipXecs sipXcom does not require any special HW. A standard Intel server will do


Given its architecture, the sipXecs sipXcom system is designed to interoperate with other third party feature servers. In addition, as we accomplished our objective of a truly distributed system, several instances of every component can be run on dedicated hardware and in different geographical locations to render a very scalable system. The sipXecs sipXcom Configuration Server provides plug & play management for core components, all feature servers, as well as connected peripherals such as phones and gateways. An XML-based plug-in framework allows easy inclusion of additional components, both feature servers as well as additional peripherals. Documentation exists about how to add support for additional phones and gateways.

While the different components of the sipXecs sipXcom system could be used stand-alone, the focus of the project has been to provide a complete sipXecs sipXcom IP PBX system out-of-the-box. On Fedora, Red Hat, Debian and SUSE distributions, the sipXecs sipXcom system can be installed easily using the distributions's respective package management system from our repository.

Architecture of the Configuration Server

The sipXecs sipXcom Configuration Server is a Web Services based configuration management system that offers plug & play management for all the sipXecs sipXcom server components including all connected phones and gateways. If connects to the existing IT infrastructure e.g. using LDAP and allows Web Services portals to use its services over a SOAP interface. It also allows integration with Microsoft Active Directory and Exchange 2007.


For persistent storage we use the PostgreSQL database.

A Web browser directly connects to the Jetty HTTP server and the Apache server is no longer required.

Web Services integration is possible using the provided SOAP interface, which can be used for bulk configuration transactions.


Starting with version 4.2 sipXconfig provides a set of REST APIs using RESTlet library. The plan for next releases is to expose all sipXconfig functionalities in REST calls.

Configuration Server communicates with other sipXecs sipXcom server components using the file system or its XML RPC interface. Using the local file system, configuration files are written to the /etc/sipxpbx directory.

Two different mechanisms are supported for phones and gateways to get access to their respective configuration files at boot time:
a) Both an FTP and TFTP server provide access to the tftproot directory on the sipXecs sipXcom server;
b) HTTP Web access is possible to the docroot directory. docroot access is provided on port 8090 using the Apache Web server.

Phones and gateways can be auto-configured on the LAN, which further simplifies deployment.