Hosted PBX

From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia

Question: Can the sipXecs PBX be partitioned into many virtual environments capable of serving many different customers each with its own particular isolated interface, settings and else?

sipX is not architected to be partitioned into multiple domains that are completely separate.

If your server is large enough, it is possible to run more than one sipXecs instance on a single server, but they cannot share the standard SIP port (5060), so there may be interoperability problems with some phones that do not handle other port numbers well.

The only known way to do this is to build distinct sets of binaries, one for each domain you wish to service. The process described below is not well tested for any production use; it has been used by developers who have too few machines, but may have severe limitations and may not work at all (since this is not something that is tested regularly).

• Decide on a "prefix" directory for each domain. It will serve as the root containing the prefix/bin, prefix/etc, prefix/var, etc. directories for each sipX instance.

• Build sipX separately *from source* for each instance, specifying the "prefix" directory for each build. The prefix directory is given as the argument to the script, also known as the "destination directory", or you can set the environment variable SIPX_INSTALLDIR when you run configure. Specifying the prefix during building is necessary because the sipX binaries contain references to the prefix directory.

• Allocate a different set of listening ports to the sipX components in each instance. Edit each "prefix"/etc/sipxpbx/config.defs file to specify the correct listening ports for each instance.

• Provide SRV records for each domain, specifying the host and listening port for the sipX instance that services each domain.

• Start and stop each instance with its "prefix"/etc/init.d/sipxpbx.

• Beware that each running instance will occupy its own chunk of virtual memory, so the physical memory needed to get good performance will increase more or less in proportion to the number of running instances.

The CPU power needed will be more or less in proportion to the amount of SIP traffic in total, but most sipX installations are limited more by RAM than CPU power.

It should not be difficult to revise sipX so that all instances can share the same binary and script directories; all that is needed is to provide a way that the binaries/scripts can obtain the prefix from the environment. Sharing binaries would also reduce the need for extra RAM, as all instances would execute the same in-RAM copy of the binaries.