2 jan 2010 kl. 16.31 skrev Antonio Goméz Soto:
Hi all,
first I want to thank you for providing answers to my numerous questions.
You have made perfectly clear that Kamailio is only a proxy, and is rather
good at that.
Secondly, I now am rather pessimistic about scaling up our current asterisk
system (which is only used by our own office) to be useful for the entire
organisation.
We actually use:
- flash operator panel to transfer calls
- call recording (mid-call using *1)
- call pickup
- barge-in
- conferences
- call forwarding
- ACD functions + listening through ChanSpy
- and various other things
The data network people don't want all calls to flow through some
central point, because of WAN network load, and think they can have phones
talk to each other using g711 when they are one the same LAN, and g729 when
they need to go through a WAN.
But as I see it now, it will be pretty much impossible to scale up using
Kamailio if we still need operator panels in offices here and there, because
there is no operator panel that can manipulate calls through Kamailio
(because that's only a proxy), and there is no operator panel that can handle
multiple parallel asterisk installations or SEMS or whatever.
Switching to different codecs depending on network location might
be doable using an Kamailio extension, but that will require a lot of
work, keeping a database, and manipulating the codec info in the SDP.
Mid-call recording poses it's own problems. If it must go undetected then
ALL calls must go through a rtp proxy, which the network people will oppose,
and even if not, Kamailio will not be the proper tool to enable it.
Also recording of G729 calls rules out SEMS and basically all other
opensource solutions except asterisk.
Of course there also is the question of managing all this. We currently
edit configfiles, but that doesn't scale all too well, so we'll probably
need some management and reporting tools as well.
And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.
Scaling up our asterisk system while preserving all of its features seems to
be a lot more involving than I initially thought...
Thanks,
Antonio
PS: And I'd like a one-to-one chat with some guys on the asterisk mailing list
who simply point to openSER when someone asks for scalability ;-)
Well, to scale you DO need a proxy. The issue here is what you use the proxy for
and how you distribute the telephony services you need. You always have to start with the
services you use. If Asterisk is a simple PSTN gateway for SIP, then it is very easy,
since there's no state involved you are interested in sharing. If you are using
Asterisk for PBX services and you do need blinking lamps, there is a state you are
interested in.
Now, with a decent server, you can manage thousands of simulatenous calls on one Asterisk
server. You can use OpenSER for failover between two Asterisk servers, but only use one in
production in order to preserve states on one machine. That's is one way of making it
easy for yourself.
If you really need to distribute states, there are now multiple ways to do that between
multiple Asterisk servers, with custom device states as one example.
So the people who pointed you to OpenSER/kamailio was not wrong at all. If they said that
it was easy to scale a PBX using OpenSER, they might have been wrong. It's not easy
yet, but many of us are working on making it easier.
/O