Hi;
I've been asked to look at a large asterisk system implementation, which
would be a candidate for either a large cluster of PCs or a smaller
cluster based on Signate's SGI box(es).
I've waded through the requirements document, and I think I have more or
less all of the requirements covered with the exception of a group of
operator consoles (probably 4 of them).
There are, as I see it, a couple of issues (and probably ones that I
haven't thought through yet, too!). Please bear with me while I think
out loud :
1) physical screen real-estate.
This means that we can't use any of the static operator consoles out
there - there's just no way to represent 1600 or so users on a PC
screen, so we'll have to come up with a way of representing only those
users an operator is interested in, and doing so in a way that still
lets them use a mouse (and/or keyboard) without everything changing
underfoot. I'm thinking something like an old air traffic control
strips system for calls requiring service, a "phone finder" to select
where a call is going, and a visible LRU cache of places you may want to
send a call.
2) aggregating manager data from many clustered asterisk machines.
Obviously we will need some sort of proxy system. The Manager interface
is, of course, pretty dynamic, and the approach taken so far seems to
have been to parse the manager output and build a graphical
representation of state information gleaned in real time. Of course,
we'd need to keep much more state than we could display, and it might be
more sensible for us to have (perhaps) a state engine for each *
machine, and aggregator which in turn broadcasts to Operator clients.
Assuming we use 2 bits for the state of each entity, we would be able to
describe 2000 users in <4kb (<512 bytes) so a frequent broadcast would
not be out of the question.
Of course, we'd lose data about which endpoints were connected to what.
How important have people found that to be in real life ?
Sorry for the ramble. Any ideas really, really welcome.
jd
