[SR-Users] RADIUS authentication

[Daniel Tryba]

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