Regarding number (2), instead of having different ports to demultiplex incoming traffic, couldn't sipXecs utilize a "virtual name space" mechanism (I do not know if there is a correct term for this, but it is similar to Apache's virtual web service which looks at the network name of the URL to determine the page to serve). An INVITE received on port 5060 to j...@example1.com would go to a different "virtual sipXecs" then an INVITE to j...@example2.org. Apache achieves this the same way, the initial GET is sent to port 80 at the same IP address but Apache looks at the URL to determine what page to serve.
5060 is the well-known port for SIP and I think that any implementation of multi-tenant should support concurrent requests on it. My opinion, standard disclaimers apply. Dan Dale Worley wrote: > On Thu, 2009-09-03 at 14:12 +0100, Simon Stockdale wrote: > >> One of our key areas of expertise is performance testing >> > > Your company may have the skills to diagnose the problems that sipXecs > has with VM systems, and I encourage you to pursue it. > > In regard to "multiple company" deployments, perhaps it is time to get > someone to do the work needed to have multiple sipXecs installations to > run on one host. In theory, this is straightforward, all you need to do > is have each set of sipXecs processes use (1) a different directory tree > for their read-write files, (2) a different set of ports, and (3) a > different "database" in PostgreSQL. Number 2 can be configured through > the web interface already, and number 1 can be configured by rebuilding > from source. I've had 5 copies of sipXecs running on a system at one > time with no problems. > > What we need is to arrange for numbers 1 and 3 to be configurable via > environment variables. Currently, most of the C++ code finds file > directories through one class in sipXcommons, which is initialized via > the Makefile and arguments to ./configure. Other parts of the code are > initialized in more rigid ways. > > What is needed is someone to go through the code completely to adjust > the "plumbing" that transmits these values. We don't need someone who > is a brilliant programmer as much as someone who is thorough and has a > good sense of design (to make sure the ultimate solution is > well-structured). Unfortunately, this is one of those changes that > can't be done incrementally -- it is useless until it is completely > done. > > Dale > > > _______________________________________________ > sipx-users mailing list sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
