Hello,
according to the archive, modules_s/*radius modules were kept because of duplicate and incompatible auth modules at the time there was an attempt to remove them: - http://lists.sip-router.org/pipermail/sr-users/2010-June/064318.html
Now there is a single auth modules, thus I guess the modules_s/*radius can be moved to obsolete.
If anyone has different opinion, reply with the arguments here.
Cheers, Daniel
I am trying to integrate Kamailio as the SIP server for an enterprise company. The challenge is to authenticate the SIP users using the Microsoft RADIUS/AD so the users can use the same Windows user name and password on their PC softphone. As Microsoft has its own RADIUS server integrated with its Active Directory, has anyone has tried to use this kind of set up? Can you share docs, links, examples or whatsoever you think could help me? The only thing I am looking for is replacing the MySQL Kamailio authentication by RADIUS, nothing else. Thanks, Moacir
Hello,
it might not be possible if you don't have the digest authentication module in the radius server. Also, that means the passwords have to be stored in plain text or HA1 hash (md5 hash based on digest auth algorithm). Do you have these available in the M$ radius server?
Cheers, Daniel
On 12/19/12 10:30 PM, Moacir Ferreira wrote:
Yeah... I know it can be a kind of problem. But millions of companies are using MS meaning we need to "adapt" if willing to work for the enterprise market. If we do not offer some kind of integration with AD, then we will end-up having 2 user names and 2 passwords while the "good sense" is forwarding everyone to "single sign-on". Anyway, it is tricky but M$ (I liked the $ thing here) can do MD5. I "would love" to see a "#!define WITH_RADIUS" at kakailio.cfg but we don't have it. However, as long as I understood, the RADIUS module is moving to obsolete as the AUTH module now also includes the RADIUS functionalities. So, can you share any link where I can find some for dummies examples of using the current AUTH module to do RADIUS authentication? Cheers! Moacir Date: Wed, 19 Dec 2012 23:18:58 +0100 From: miconda@gmail.com To: sr-users@lists.sip-router.org CC: moacirferreira@hotmail.com Subject: Re: [SR-Users] RADIUS authentication
Hello,
it might not be possible if you don't have the digest authentication module in the radius server. Also, that means the passwords have to be stored in plain text or HA1 hash (md5 hash based on digest auth algorithm). Do you have these available in the M$ radius server?
Cheers,
Daniel
On 12/19/12 10:30 PM, Moacir Ferreira wrote:
I am trying to integrate Kamailio as the SIP server for an enterprise company. The challenge is to authenticate the SIP users using the Microsoft RADIUS/AD so the users can use the same Windows user name and password on their PC softphone. As Microsoft has its own RADIUS server integrated with its Active Directory, has anyone has tried to use this kind of set up? Can you share docs, links, examples or whatsoever you think could help me? The only thing I am looking for is replacing the MySQL Kamailio authentication by RADIUS, nothing else.
Thanks,
Moacir
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
You should take a look to Radiator:
http://www.open.com.au/radiator/technical.html
It has some authentication methods for Microsoft.
Regards.
El 20/12/2012, a las 15:58, Moacir Ferreira moacirferreira@hotmail.com escribió:
Moacir Ferreira writes:
i used to use radius authentication with kamailio for years, but recently gave up on it due to extra complexity/load introduced by radius queries. if that does not bother you, then there is absolutely no reason why radius auth and other radius functions would not work fine in k.
i think you have misunderstood things. modules_k/auth_radius and misc_radius that i used to use, are not going to be obsoleted.
here are the calls that i used to make:
if (!radius_proxy_authorize("$var(uri_domain)", "$var(uri_user)")) { switch ($rc) { ...
if (!radius_www_authorize("$td")) { switch ($rc) { ...
if (radius_does_uri_user_exist()) { ... radius_load_callee_avps();
if (radius_does_uri_exist()) { ...
if (!radius_does_uri_exist()) { ...
in addition, i had implemented private radius_test function that i used to check health of radius backend:
if (is_method("OPTIONS")) { if ($fU == "sipsak") { if (radius_test()) { options_reply(); } else { xlog("L_ERR", "$rm <$ru> failed radius_test\n"); send_reply("500", "Server Internal Error"); };
hope this helps,
-- juha
On 12/20/12 3:58 PM, Moacir Ferreira wrote:
There is no need for two usernames, but could be the case for two passwords...
Anyway, it is tricky but M$ (I liked the $ thing here) can do MD5.
MD5 is just the hashing algorithm, with is used in www-digest authentication.
The issue here is not that someone hates M$, but it is that SIP phones implement only www-digest authentication mechanism, which requires to store the password in clear text or HA1 format (which is md5 over username, realm and password).
If you try to integrate with an existing system that stored the passwords in some shadow form, it is not just working. For each account you need to store the password in what www-digest can use for authentication.
As Juha pointed in another reply, you misunderstood, radius authentication has to be done using auth_radius module (there were two, only one was removed).
This tutorial is quite old, but still good for starting with: - http://www.kamailio.org/docs/openser-radius-1.0.x.html
Cheers, Daniel
I thanks for the responses. However, I still don’t have a “vision” on how I can address my problem. My key points here are: - Most of the enterprise companies have a directory service implemented already. So it does not make sense to create and maintain a second one just for SIP clients. With this in mind, we may use LDAP or RADIUS to prevent introducing a new directory just for SIP. - As long as I understood from my readings (sorry if I am wrong), Kamailio LDAP will require a change on the customer’s LDAP schema, what most of the times is “undesirable” on large enterprise. So the way out is to use the native operation system RADIUS services from the customer’s environment, most of the time M$. Sorry if I am bugging the community of a “carrier product” trying to adapt it to the enterprise environment. But why not? Kamailio is very stable, very low foot print, very scalable and it is a product that could become the “de facto” standard for “the SIP server” like we have a “de facto” standard for DNS, DHCP, SQL, HTTP, etc. in most of Linux distro. By other hand, most (or all) SIP-PBX servers out there will solve the SIP issues but will also interfere on the RTP, what Kamailio does not do... So my next question is: is it there on the Kamailio community anyone willing to work on a “Kamailio Enterprise Edition”? I believe the enterprise market is just thousands times larger than the carrier one. So, does it worth to create a thread just to discuss using Kamailio on the enterprise? As the last question, am I on the right forum? I mean, am I asking the right thing on the wrong place? Think about it: thousands and thousands of enterprise companies using Kamailio! Why not? Cheers! Moacir Date: Thu, 20 Dec 2012 18:29:55 +0100 From: miconda@gmail.com To: moacirferreira@hotmail.com CC: sr-users@lists.sip-router.org Subject: Re: [SR-Users] RADIUS authentication
On 12/20/12 3:58 PM, Moacir Ferreira wrote:
Yeah... I know it can be a kind of problem. But millions of companies are using MS meaning we need to "adapt" if willing to work for the enterprise market. If we do not offer some kind of integration with AD, then we will end-up having 2 user names and 2 passwords while the "good sense" is forwarding everyone to "single sign-on".
There is no need for two usernames, but could be the case for two passwords...
Anyway, it is tricky but M$ (I liked the $ thing here) can do MD5.
MD5 is just the hashing algorithm, with is used in www-digest authentication.
The issue here is not that someone hates M$, but it is that SIP phones implement only www-digest authentication mechanism, which requires to store the password in clear text or HA1 format (which is md5 over username, realm and password).
If you try to integrate with an existing system that stored the passwords in some shadow form, it is not just working. For each account you need to store the password in what www-digest can use for authentication.
I "would love" to see a "#!define WITH_RADIUS" at kakailio.cfg but we don't have it. However, as long as I understood, the RADIUS module is moving to obsolete as the AUTH module now also includes the RADIUS functionalities.
So, can you share any link where I can find some for dummies examples of using the current AUTH module to do RADIUS authentication?
As Juha pointed in another reply, you misunderstood, radius authentication has to be done using auth_radius module (there were two, only one was removed).
This tutorial is quite old, but still good for starting with:
- http://www.kamailio.org/docs/openser-radius-1.0.x.html
Cheers,
Daniel
Cheers!
Moacir
Date: Wed, 19 Dec 2012 23:18:58 +0100
From: miconda@gmail.com
To: sr-users@lists.sip-router.org
CC: moacirferreira@hotmail.com
Subject: Re: [SR-Users] RADIUS authentication
Hello,
it might not be possible if you don't have the digest authentication module in the radius server. Also, that means the passwords have to be stored in plain text or HA1 hash (md5 hash based on digest auth algorithm). Do you have these available in the M$ radius server?
Cheers,
Daniel
On 12/19/12 10:30 PM, Moacir Ferreira wrote:
I am trying to integrate Kamailio as the SIP server for an enterprise company. The challenge is to authenticate the SIP users using the Microsoft RADIUS/AD so the users can use the same Windows user name and password on their PC softphone. As Microsoft has its own RADIUS server integrated with its Active Directory, has anyone has tried to use this kind of set up? Can you share docs, links, examples or whatsoever you think could help me? The only thing I am looking for is replacing the MySQL Kamailio authentication by RADIUS, nothing else.
Thanks,
Moacir
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Moacir Ferreira writes:
So my next question is: is it there on the Kamailio community anyone willing to work on a “Kamailio Enterprise Edition”?
what do you mean by such an edition? do you want to integrate asterisk like pbx capabilities to k or what? if so, my understanding is that most k folks want to keep them separate and just connect ip pbxes to k like any other sip uas.
-- juha
Don’t get me wrong… Kamailio is just a great product as it is. Actually I think it does much more than it would be necessary as a carrier grade software. My idea is to have more people involved discussing the “enterprise” issues and possible solutions for problems like the one I described. The “impression” that I have is that Kamailio’s community is much more devoted to the “carrier” side of the software than to the use of it on enterprises.
Moacir
Hello,
Kamailio is used a lot in enterprises. Apart of the media processing services (e.g., voicemail, audio conferencing), kamailio offers all needed in an enterprise, including instant messaging and presence.
It still seems to be unclear for you where is the problem with Kamailio and M$ directory or other existing user authentication systems. Let me rephrase: the problem is in the specifications of SIP, respectively in the user authentication mechanism required by this protocol.
SIP requires www-digest authentication mechanims. www-digest authentication requires that password is stored in clear text or in HA1 format. Maybe reading the page at next link puts more light:
- http://en.wikipedia.org/wiki/Digest_access_authentication
Now, the devices are the problem, because they can authenticate to the server only using www-digest. Kamailio cannot do anything alone.
Alternative to www-digest authentication is to use ssl certificates. That is fine for Kamailio, but not many sip phones support it.
Hope is more clear now. Kamailio is as friendly to enterprises as it is for carriers or operators. It is nothing that can be done more to run in enterprise environment.
Cheers, Daniel
On 12/21/12 11:20 AM, Moacir Ferreira wrote:
21 dec 2012 kl. 16:55 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
Kamailio is used a lot in enterprises. Apart of the media processing services (e.g., voicemail, audio conferencing), kamailio offers all needed in an enterprise, including instant messaging and presence.
We've done quite a lot of enterprise-style installations and also integrated with LDAP. As Daniel patiently have repeated, there is a problem with the authentication so we can't simply use LDAP authentication, but have successfully implemented LDAP-based authentication in many places.
Do you have any other concerns or ideas on what we can do in the enterprise sector? We're quite open on discussing it.
/O
Well… Sorry for this long post. I work 100% dedicated to SMB - Small Medium Business. In this market there is an enormous growth of multiples devices in all companies. Most of the SMB I work with are looking for:
- Let their employees bring their own device (BYOD);- Enable chat, voice and video, with presence information in all devices;- Not have to pay for premium solutions like sophisticated SBCs to enable the workforce to work either internally (in the company) or externally (from the Internet);- Have a single number for voice and video in all devices;- Reduced complexity, setup time and maintenance; With all the above in mind, I believe Kamailio is just wonderful, why: - It is inexpensive!!!- No limit or licenses for users. In this way any employee can have their PC, their iPad or Android tablet, their iPhone or Android phone, their table phone, etc. - Using the right device or software client (some of them freeware) they can, once again, reduce cost.
- Very key: Unlike several alternatives on the market, Kamailio does not interfere with the RTP in between SIP clients, it does raw media switching using RTPProxy. So, more complex SIP usage like in video will not be affected by the SIP solution. I know that you can always find the information to deploy such solution with the specs above. However, the information is a kind of “scattered” and, unlike the alternatives that would not address all the exposed issues, it takes quite long to get the server configured to do what we want. And yes, maybe because I am just a newbie to Kamailio, sorry for that. 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.
- All devices from a user should ring when receiving a call.
- Calling outside (PSTN) should be impersonated so the user would have a single number seem outside of the company.
- The solution should have an internal interface (LAN) and an external Interface (WAN/Internet), promoting RTP relay for NATed devices.
- 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.
- The solution should be able to record calls.
- The solution should be able to use SIP trunk as the way out to PSTN.
- 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, 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. Cheers! Moacir
From: oej@edvina.net Date: Fri, 21 Dec 2012 16:58:53 +0100 To: miconda@gmail.com; sr-users@lists.sip-router.org Subject: Re: [SR-Users] RADIUS authentication
21 dec 2012 kl. 16:55 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
Kamailio is used a lot in enterprises. Apart of the media processing services (e.g., voicemail, audio conferencing), kamailio offers all needed in an enterprise, including instant messaging and presence. We've done quite a lot of enterprise-style installations and also integrated with LDAP. As Daniel patiently have repeated, there is a problem with the authentication so we can't simply use LDAP authentication, but have successfully implemented LDAP-based authentication in many places. Do you have any other concerns or ideas on what we can do in the enterprise sector? We're quite open on discussing it. /O
It still seems to be unclear for you where is the problem with Kamailio and M$ directory or other existing user authentication systems. Let me rephrase: the problem is in the specifications of SIP, respectively in the user authentication mechanism required by this protocol.
SIP requires www-digest authentication mechanims. www-digest authentication requires that password is stored in clear text or in HA1 format. Maybe reading the page at next link puts more light:
- http://en.wikipedia.org/wiki/Digest_access_authentication
Now, the devices are the problem, because they can authenticate to the server only using www-digest. Kamailio cannot do anything alone.
Alternative to www-digest authentication is to use ssl certificates. That is fine for Kamailio, but not many sip phones support it.
Hope is more clear now. Kamailio is as friendly to enterprises as it is for carriers or operators. It is nothing that can be done more to run in enterprise environment.
Cheers,
Daniel
On 12/21/12 11:20 AM, Moacir Ferreira wrote:
Don’t get me wrong… Kamailio is just a great product as it is. Actually I think it does much more than it would be necessary as a carrier grade software. My idea is to have more people involved discussing the “enterprise” issues and possible solutions for problems like the one I described. The “impression” that I have is that Kamailio’s community is much more devoted to the “carrier” side of the software than to the use of it on enterprises.
Moacir
> Date: Fri, 21 Dec 2012 10:41:25 +0200
> To: sr-users@lists.sip-router.org
> From: jh@tutpro.com
> Subject: Re: [SR-Users] RADIUS authentication
>
> Moacir Ferreira writes:
>
> > So my next question is: is it there on the Kamailio community anyone
> > willing to work on a “Kamailio Enterprise Edition”?
>
> what do you mean by such an edition? do you want to integrate asterisk
> like pbx capabilities to k or what? if so, my understanding is that
> most k folks want to keep them separate and just connect ip pbxes to k
> like any other sip uas.
>
> -- juha
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Well… Sorry for this long post. I work 100% dedicated to SMB - Small Medium Business. In this market there is an enormous growth of multiples devices in all companies. Most of the SMB I work with are looking for:
- Let their employees bring their own device (BYOD);- Enable chat, voice and video, with presence information in all devices;- Not have to pay for premium solutions like sophisticated SBCs to enable the workforce to work either internally (in the company) or externally (from the Internet);- Have a single number for voice and video in all devices;- Reduced complexity, setup time and maintenance; With all the above in mind, I believe Kamailio is just wonderful, why: - It is inexpensive!!!- No limit or licenses for users. In this way any employee can have their PC, their iPad or Android tablet, their iPhone or Android phone, their table phone, etc. - Using the right device or software client (some of them freeware) they can, once again, reduce cost.
- Very key: Unlike several alternatives on the market, Kamailio does not interfere with the RTP in between SIP clients, it does raw media switching using RTPProxy. So, more complex SIP usage like in video will not be affected by the SIP solution. I know that you can always find the information to deploy such solution with the specs above. However, the information is a kind of “scattered” and, unlike the alternatives that would not address all the exposed issues, it takes quite long to get the server configured to do what we want. And yes, maybe because I am just a newbie to Kamailio, sorry for that. 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.
- All devices from a user should ring when receiving a call.
- Calling outside (PSTN) should be impersonated so the user would have a single number seem outside of the company.
- The solution should have an internal interface (LAN) and an external Interface (WAN/Internet), promoting RTP relay for NATed devices.
- 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.
- The solution should be able to record calls.
- The solution should be able to use SIP trunk as the way out to PSTN.
- 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, 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. Cheers! Moacir
From: oej@edvina.net Date: Fri, 21 Dec 2012 16:58:53 +0100 To: miconda@gmail.com; sr-users@lists.sip-router.org Subject: Re: [SR-Users] RADIUS authentication
21 dec 2012 kl. 16:55 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
Kamailio is used a lot in enterprises. Apart of the media processing services (e.g., voicemail, audio conferencing), kamailio offers all needed in an enterprise, including instant messaging and presence. We've done quite a lot of enterprise-style installations and also integrated with LDAP. As Daniel patiently have repeated, there is a problem with the authentication so we can't simply use LDAP authentication, but have successfully implemented LDAP-based authentication in many places. Do you have any other concerns or ideas on what we can do in the enterprise sector? We're quite open on discussing it. /O
It still seems to be unclear for you where is the problem with Kamailio and M$ directory or other existing user authentication systems. Let me rephrase: the problem is in the specifications of SIP, respectively in the user authentication mechanism required by this protocol.
SIP requires www-digest authentication mechanims. www-digest authentication requires that password is stored in clear text or in HA1 format. Maybe reading the page at next link puts more light:
- http://en.wikipedia.org/wiki/Digest_access_authentication
Now, the devices are the problem, because they can authenticate to the server only using www-digest. Kamailio cannot do anything alone.
Alternative to www-digest authentication is to use ssl certificates. That is fine for Kamailio, but not many sip phones support it.
Hope is more clear now. Kamailio is as friendly to enterprises as it is for carriers or operators. It is nothing that can be done more to run in enterprise environment.
Cheers,
Daniel
On 12/21/12 11:20 AM, Moacir Ferreira wrote:
Don’t get me wrong… Kamailio is just a great product as it is. Actually I think it does much more than it would be necessary as a carrier grade software. My idea is to have more people involved discussing the “enterprise” issues and possible solutions for problems like the one I described. The “impression” that I have is that Kamailio’s community is much more devoted to the “carrier” side of the software than to the use of it on enterprises.
Moacir
> Date: Fri, 21 Dec 2012 10:41:25 +0200
> To: sr-users@lists.sip-router.org
> From: jh@tutpro.com
> Subject: Re: [SR-Users] RADIUS authentication
>
> Moacir Ferreira writes:
>
> > So my next question is: is it there on the Kamailio community anyone
> > willing to work on a “Kamailio Enterprise Edition”?
>
> what do you mean by such an edition? do you want to integrate asterisk
> like pbx capabilities to k or what? if so, my understanding is that
> most k folks want to keep them separate and just connect ip pbxes to k
> like any other sip uas.
>
> -- juha
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Opening the previous message I saw it was messy... Here it goes again: Well… Sorry for this long post. I work 100% dedicated to SMB - Small Medium Business. In this market there is an enormous growth of multiples devices in all companies. Most of the SMB I work with are looking for: - Let their employees bring their own device (BYOD); - Enable chat, voice and video, with presence information in all devices; - Not have to pay for premium solutions like sophisticated SBCs to enable the workforce to work either internally (in the company) or externally (from the Internet); - Have a single number for voice and video in all devices; - Reduced complexity, setup time and maintenance; With all the above in mind, I believe Kamailio is just wonderful, why: - It is inexpensive!!! - No limit or licenses for users. In this way any employee can have their PC, their iPad or Android tablet, their iPhone or Android phone, their table phone, etc. - Using the right device or software client (some of them freeware) they can, once again, reduce cost. - Very key: Unlike several alternatives on the market, Kamailio does not interfere with the RTP in between SIP clients, it does raw media switching using RTPProxy. So, more complex SIP usage like in video will not be affected by the SIP solution. I know that you can always find the information to deploy such solution with the specs above. However, the information is a kind of “scattered” and, unlike the alternatives that would not address all the exposed issues, it takes quite long to get the server configured to do what we want. And yes, maybe because I am just a newbie to Kamailio, sorry for that.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. - All devices from a user should ring when receiving a call. - Calling outside (PSTN) should be impersonated so the user would have a single number seem outside of the company. - The solution should have an internal interface (LAN) and an external Interface (WAN/Internet), promoting RTP relay for NATed devices. - 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. - The solution should be able to record calls. - The solution should be able to use SIP trunk as the way out to PSTN. - 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, 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. Cheers! Moacir
On Friday 21 December 2012 19:12:00 Moacir Ferreira wrote:
There is no reason to have multiple accounts for multiple device for 1 user. Just have them register with the same credentials.
1 account will ring multiple endpoints
Again just use 1 account.
Behavior is in the default config (atleast the debian packages): #!define WITH_NAT
Default behavior
Leave that to rtpproxy by using start_recording() from rtpproxy module.
That is in the default config
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.
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 :)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Jesús Rodríguez -
Juha Heinanen -
Moacir Ferreira -
Olle E. Johansson