[Kamailio-Users] Scaling up asterisk using kamailio while keeping features (WAS: re-invite mid call?)

[Olle E. Johansson]

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