Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

http://wiki.sipfoundry.org/display/oldxx Architecture Diagram

       

The sipXecs System Architecture Diagram

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

The SIP protocol was designed in support of a fully distributed architecture where different features are provided by servers that again communicate among themselves using the SIP protocol. There is a strict separation between Media and Signaling, which allows a globally scalable system to be built with the necessary redundancy and resiliency. Media streams, once setup, flow directly between end-points (phones and gateways) without any requirement for media to go through a central signaling server.

 

 

 

 

 

Highlights

  • 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 is not based on a B2BUA but implements a true SIP proxy architecture
  • Better Voice Quality: Media goes direct point-to-point between the end points and never through the call control system
  • Standard SIP: sipXecs 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 does not require any special HW. A standard Intel server will do
  • Features: Yes, there are lots of them
  • Roadmap: Yes, got a clear and public roadmap

    Comments

  • B2BUA server (sipXbridge) released with version 4.0
  • Conference bridge included in package
  • Freeswitch based Auto Attendant and Voicemail integrated


 Given its architecture, the sipXecs 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 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 system could be used stand-alone, the focus of the project has been to provide a complete sipXecs IP PBX system out-of-the-box. On Fedora, Red Hat, Debian and Gentoo distributions, the sipXecs system can be installed easily using the distributions's respective package management system from our repository.

Architecture of the Configuration Server

The sipXecs Configuration Server is a Web Services based configuration management system that offers plug & play management for all the sipXecs 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.

User data can be uploaded from LDAP or using a comma-delimited CSV file typically generated by a spreadsheet application. We also started work on integrating an OAM DM stack used to configure "over-the-air" multiband cell phones that support SIP over WiFi.

The following library components are used

  • Jetty: Java HTTP Server and Servlet Container
  • Spring Framework: Java Application Server Framework
  • Tapestry: Apache Jakarta Tapestry
  • Hibernate: Idiomatic Persistence for Java
  • Velocity: Java based Template Engine
  • Lucene*:*Java-based indexing and search 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.
    For persistent storage we use the PostgreSQL database.
    Configuration Server communicates with other sipXecs 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 server; and 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.

 

 

 

 

 

Architecture of the Media Server

The sipXecs Media Server provides voicemail and auto-attendant services. It is based on VXML using the OpenVXI library.

Legend:

  1. Configuration Server generates configuration files for the Media Server and stores them in the file system of the host on which Media Server runs. These configuration files are read by Media Server when it starts.
  2. On an ongoing basis during operation Configuration Server provides updated information on users, their credentials, routing information etc. into the In-Memory Data Base (IMDB) through a replication interface. The transactions are done using HTTPS through the Apache Web server and using the Replication CGI.
  3. The Replication CGI writes the information to the IMB (we use FastDB).
  4. Information is retrieved from the IMDB by the MediaServer CGI
  5. Configuration Server also provides process control for the media server and its components. A Process CGI is used to communicate with the watchdog that runs on every host that participates in a sipX system.
  6. The sipXvxml RPM includes both the OpenVXI component as well as an interface that allows OpenVXI to communicate with MediaServer CGI using HTTP.
  7. MediaServer also communicates with the Status server using HTTPS for the purpose of exchanging Message Waiting status information (MWI)
  8. OpenVXI communicates with the rest of the system using SIP. Calls are transferred to the Media Server.
  9. OpenVXI generates prompts that can be played by Media Server. These prompts are stored to the file system from where Media Server can retrieve them.
  10. Media Server retrieves stored prompts
  • No labels