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

[Raúl Alexis Betancor Santana]

On Saturday 02 January 2010 15:31:33 Antonio Goméz Soto wrote:
> 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.

Hi Antonio, I think that you are "blocked" with the limited vision that 
Asterisk gives you about VoIP world ... let me explain that ...

> We actually use:
>
> - flash operator panel to transfer calls

That could be done with xmlrpc calls if you use SEMS+Kamailio

> - call recording (mid-call using *1)

SEMS have support for call-recording, we use it.

> - call pickup

Well, this is a little bit complex ... but still doable.

> - barge-in
...
 barge-in definition - telecom
A feature of a key telephone system (KTS) or PBX, barge-in allows an 
authorized user from an authorized station to join, without invitation, an 
active call on a call in progress through the use of an authorization code 
the user enters via the telephone keypad.
...

Umm ... a type of chanspy I suppose ... well, this would be complicated ... 
but still doable.

> - conferences

Supported by SEMS

> - call forwarding

Supported by Kamailio with script routing.

> - ACD functions + listening through ChanSpy

Umm ... maybe LB+Dispatcher

> - and various other things

You will have to specify.

> 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.

Trust me ... if you use VoIP phones (hardphones, no softphones), the will be 
not difference between G711 local calls and G729 local calls ... if phones 
are goog enought. No matter of what you do ... you could build a VoIP system 
with no "central point", it's just a matter of time,knowleadge and bugget

> 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.

You are wrong here, if you follow the "asterisk path" ... Asternic FOP 2.0 
allow you to easly control more than one asterisk.
On the other hand, you could also develop your own panels to control 
SEMS+Kamailo, you could build a VoIP infraestructure on witch you use SEMS as 
B2BUA withouth the need to forward all RTP traffic throught it, so you will 
get a very good and scalable Asterisk replacement.


> 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.

Functions to mangling the SDP are out there, but you will have to do the work, 
or hire someone to doit.

> 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.

If you want it to be "undetectable" and don't want to use a RTP proxy, if you 
have the needed network hardware, you still could do it.

> Also recording of G729 calls rules out SEMS and basically all other
> opensource solutions except asterisk.

You could use G729 with sems, we use it, you only need to write down some 
lines of C++ code to use the Intel G.729 ipp libraries, for example ... or 
you could develop a wrapper an use Asterisk .so files of G729 codecs, or a 
hardware card, it's a matter of time, knowleadge and bugget

> 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.

Yes, you have the tools, now it's time to beging to work, no pre-made systems, 
no just-click-and-run software.

> 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.

Eint ¿? ... an attended transfer it's no more than two calls A call B, B puts 
A on hold, B calls C, C accept the transfer, B transfer A to C ... it just 
work with the basic example .cfg of kamailio, because it's a work of the UA's 
involved on that calls, not a task of the proxy.

Call-pickup could also be done at proxy level, if your UA's support that 
supplementary services, if not .. a B2BUA must be used.

> Scaling up our asterisk system while preserving all of its features seems
> to be a lot more involving than I initially thought...

Yes, it is ... a very big and very good challenge.

> 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 ;-)

Could be used, it's a matter of knowing how to do it and that's the hard 
part  ... ;-)

-- 
Raúl Alexis Betancor Santana
Dimensión Virtual