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