On Friday 21 December 2012 19:12:00 Moacir Ferreira wrote:
With the above in
mind I would like to see, and of course contribute for, a “how to” to
deploy a Kamailio server with the following specs: - If you thing about
companies with up to 10k employees, each employee with up to 4 SIP
terminals (i.e.: table phone, cellular phone, PC and tablet), then you
would need a solution scalable for 40k devices.
There is no reason to have multiple accounts for multiple device for 1 user.
Just have them register with the same credentials.
- All devices from a user should ring when
receiving a call.
1 account will ring multiple endpoints
- Calling outside (PSTN) should be impersonated so
the user would have a single number seem outside of the company.
Again just use 1 account.
- The solution should have an internal interface
(LAN) and an external Interface (WAN/Internet), promoting RTP relay for
NATed devices.
Behavior is in the default config (atleast the debian packages):
#!define WITH_NAT
- The solution should not interfere with RTP, meaning
no transcoding. If an end point fulfills the other part RTP offer, they
would connect. If not, it would be just rejected.
Default behavior
- The solution should be able to record calls.
Leave that to rtpproxy by using start_recording() from rtpproxy module.
- The solution should be able to use SIP trunk as
the way out to PSTN.
That is in the default config
- The solution should be able to integrate, via
RADIUS or LDAP, with the customer existing directory, most of the cases
Microsoft. Now, when look at these specs,
It has been mentioned before, to authenticate SIP devices you need the
plaintext password (or a specific hash of it), this is a big no no in
centralized user authentication.
Kamilio does all of this! However, it may take one
year before someone
“Kamailio dummy” like myself to get all the knowledge to do it. Of course
I know I must invest on more knowledge but the more companies easily
install and start using Kamailio on the enterprise, the better is my value
if I get to know it in depth. So that is why I would like to see a
“working group” within the existing Kamailio community, with more focus on
easing up the deployment of it on the enterprise. I believe more people
had the same problem I am having: it is a lot to study specially if you
are not a programmer; because of it not a lot of SMB companies are using
it, making investing on learning it, in my case, low return.
TANSTAAFL
You need to (at least invest) time to get required knowledge. If you have some
money to invest take a look at the Advanced Kamailio Training (this really
opened my eyes on how to use/mold Kamailio for my needs). This means your
client has to cough up more money (you have to recoup your investments), which
might mean an out of the (black)box solution might be more affordable (at the
cost of flexibility or added licensing costs on changes).
Make things to easy to install and maintain and suddenly you have a lot more
competition :)