2 Jan
2010
2 Jan
'10
11:03 p.m.
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