WipeOut wrote:
Asterisk would need some kind of clustering/load balancing ability
(Single IP system image for the IP phones across multiple servers) to be
truely Enterprise Class in terms of both reliability and
scaleability.. Obviously that would not be as relevent for the analog
hard
WipeOut wrote:
Asterisk would need some kind of clustering/load balancing ability
(Single IP system image for the IP phones across multiple servers) to
be truely Enterprise Class in terms of both reliability and
scaleability.. Obviously that would not be as relevent for the analog
hard
On Sun, 2004-01-04 at 12:53, Nick Bachmann wrote:
WipeOut wrote:
Asterisk would need some kind of clustering/load balancing ability
(Single IP system image for the IP phones across multiple servers) to
be truely Enterprise Class in terms of both reliability and
scaleability..
Nick Bachmann wrote:
Yes, I've played with it a bit. It's pretty simplistic... the clustering
just keeps several servers in sync with each other. I suppose that would
be easy to do with Asterisk, especially if configuration data was stored
in a RDBMS that could do replication. Even now,
On Sun, 2004-01-04 at 12:53, Nick Bachmann wrote:
Yes, I've played with it a bit. It's pretty simplistic... the
clustering just keeps several servers in sync with each other. I
suppose that would be easy to do with Asterisk, especially if
configuration data was stored in a RDBMS that could
Hi!
The affinity table makes the RTP stuff OK, but I agree that sharing
SIP registrations is a concern.
These are stored in the Asterisk DB. Type this at your CLI:
database show SIP/Registry
Consequently it shouldn't be a a problem to sync the registry data.
Cheers, Philipp
