[SR-Users] Kamilio new user - help get going

Mon Jul 17 18:53:53 CEST 2017

Hi Kenneth,
As has been said before there are many ways to do this.  We do something similar for 100+ customers with a freepbx instance each.  It has taken us a lot of experimentation and trial and error to get this working reliably… and I’ve done the Kamailio Advanced training course too.

A simplified version of our architecture would have:
1 Kamailio + RTPEngine acting as a gateway to PSTN, with1 public IP
1 Kamailio +RTPEngine acting as a proxy for all customer devices, with 1 public IP
1 nginx proxying the web connections to the customer freepbx GUI, with 1 public IP
1 shared database for all the sip devices and credentials, using multi-domain to map the customer registration uri (see below)
n container running freepbx, one for each of your customers, no public IP's

You can then configure your SIP devices to use the registrar proxy as their OutboundProxy. e.g. sip.knudsen-nordic.com <http://sip.knudsen-nordic.com/>.
You can then give each customer unique subdomain in the registration uri e.g. customer1.sip.knudsen-nordic.com <http://sip.knudsen-nordic.com/>.  These subdomains do not have to be in any public DNS record, but you do have to edit your kamailio.cfg to parse the uri and then route the packets to the relevant PBX.

When you have that working you might then want to introduce some resilience…

By the time you’ve done that lot you will either be a Kamailio consultant, or have hired a Kamailio consultant!

Hopefully this gives you some more insight into an approach that does work, and also the complexity of what you are trying to do.

Good luck.

-- 
Paul Smith
Technical Director, Voxbit Ltd
PaulSmith at VoxBit.net <mailto:PaulSmith at voxbit.net>

> On 17 Jul 2017, at 17:10, Kenneth Knudsen <kenneth at knudsen-nordic.com> wrote:
> 
> Hi Joel
>  
> Your scenario was spot on the one I was thinking about.
>  
> If we can have Kamilio handle all the traffic that would be the best approach I think. But do I need a public IP for each PBX server to handle the RTP traffic?
>  
> We would definitely not expose the PBX server to the internet, for the same reason you write below.
>  
> I think one way to separate A, B and C from each other if I used different port numbers for every customer?  Sip 5065 for A, 5066 for B and 5067 for C?
>  
> As far as I have read in the cook book it seems that Kamilio can share DB with the PBX server(s) and that way handle registrations for any given PBX server?
>  
> It gets a little more cloudy for me when we get to the handling of traffic and connection to the PBX server…
>  
> If I only had residential customers with 1 line it would be easier as they could all go to the same PBX or a cluster of them. But I need to have individual settings for my different business customers so they can have their own rules, ring groups and such.
>  
>  
> Kind regards,
>  
>  
> From: sr-users [mailto:sr-users-bounces at lists.kamailio.org] On Behalf Of Joel Serrano
> Sent: Friday, July 14, 2017 2:55 PM
> To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Kamilio new user - help get going
>  
> Hi Kenneth, 
>  
> What you are talking about is a pretty common installation. As a starting point, you will need a way to differentiate your clients so you can send them to the correct PBX.
>  
> For example:
>  
> You have customers A, B, C and PBX servers 1, 2, 3 respectively.  (A1, 2B, 3C). Your domain name is sip.knudsen-nordic.com <http://sip.knudsen-nordic.com/>.
>  
> Say A wants to register to their PBX, how would you make sure that Kamailio forwards that request to PBX1 instead of PBX2? Then C wants to register and Kamailio has to send the request to PBX3 this time, etc. There are countless ways to do this, and any can be correct or wrong. This is why the big picture matters a lot, Kamailio can handle and manage all registrations by himself, or it can relay them for each PBX to manage their own registrations, etc.... Would the PBXs have public IPs (with traffic restricted by a firewall or similar) or would they have private IPs and you have to deal with NAT, etc.? There are lots of variables here.
>  
> Regarding having the PBX exposed directly to internet, I would strongly suggest to avoid that, fraud attempts in the SIP worldWILL HAPPEN literally minutes after you expose the PBX, and, it is quite common for config mistakes to cause huge fraud carrier bills.
>  
>  
>  
>  
>  
>  
> On Fri, Jul 14, 2017 at 11:02 AM, Kenneth Knudsen <kenneth at knudsen-nordic.com <mailto:kenneth at knudsen-nordic.com>> wrote:
> Hi Joel,
>  
> Thx for your reply.. I see your point, and you are already throwing me off with the dispatcher group…
>  
> Let me try and explain what I would like to do (if possible):
>  
> I want one single public IP assigned to a domain name(for now), to be the contact point for all VoIP phones, with all our different customers, from there the SIP Proxy (Kamilio) would be the master and make sure the customers phones are connected with their FreePBX (one FreePBX for every customer) behind the SIP Proxy.
>  
> I want to hide the topology behind the SIP Server for security reasons.
>  
> I don’t know what the best approach is to the above goals, as we get more customers we would most likely get a SIP Proxy cluster for uptime and redundancy purposes. But first we need to show we can get it going before we can bring on any customers. The FreePBX as a standalone service I have figured out, and no problem connecting phones over the internet and such.
>  
> Is the best approach to expose the SIP Server directly to the internet (avoiding fw issues and nat confusion) or am I going down the wrong road here?
>  
>  
> Kind regards,
>  
> From: sr-users [mailto:sr-users-bounces at lists.kamailio.org <mailto:sr-users-bounces at lists.kamailio.org>] On Behalf Of Joel Serrano
> Sent: Friday, July 14, 2017 9:14 AM
> To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>>
> Subject: Re: [SR-Users] Kamilio new user - help get going
>  
> My 2cents:
>  
> - Agree, Kamailio training makes your life easier. Specially because even if you know SIP (if you don't that complicates everything), you need to understand how Kamailio works internally, what are dialogs, transactions, branches, etc, the different route blocks, blablabla, what goes where... To be honest, once you understand that, you can do literally whatever you want. If you don't know something, you can ask and someone will give you some help, and when you read it, you will actually understand what whoever is trying to say. Why I'm saying this? Because I could answer your questions to the point, and still you would get a system running but you would have no idea of why or how it works, so what happens when you run into an issue?
>  
> - To the point, you probably need different sets of domains and dispatcher groups, and then depending on where the call is going to, route to a specific dispatcher group? This is just an initial suggestion, as you haven't given many details, there are just so many ways of doing things that we would need a little more information on how EXACTLY do you need things to work...
>  
>  
>  
>  
>  
> On Fri, Jul 14, 2017 at 4:59 AM, David Villasmil <david.villasmil.work at gmail.com <mailto:david.villasmil.work at gmail.com>> wrote:
> I also took this training, it's worth it.
>  
> On Fri, Jul 14, 2017 at 11:00 AM Daniel Tryba <d.tryba at pocos.nl <mailto:d.tryba at pocos.nl>> wrote:
> On Thu, Jul 13, 2017 at 09:46:03PM +0000, Kenneth Knudsen wrote:
> > Thanks, but then I’m missing the next step, how do we configure the
> > connection between Kamilio and the FreePBX servers ?
> >
> > How do we configure the routes, public ip, internal FreePBX servers.
> >
> > This make no sense to me at all:
> 
> Look at you question business wise: how many hours are you willing to
> spend on getting this setup (on a trail by error kind of way) and the
> costs of those hours. Is hiring a consultant for 20 hours to get a ready
> made solution really more expensive?  Maybe you could get the consultant
> to spend a day with you to get the grips on kamailio instead of having
> them build the solution?
> 
> You may get all your questions answered here if people feel inclined to
> answer them in their spare time. You might get better answer if you ask
> smaller more to the point questions.
> 
> BTW I had the same kind of problems getting my head around understanding
> kamailio. I saw the potential but wasn't really understanding it. My
> solution was to take the Kamailio Advanced Training https://www.asipto.com/sw/trainings/ <https://www.asipto.com/sw/trainings/>
> 
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>  
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>  
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170717/fd0433bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voxbit-sig-icon-50x50.png
Type: image/png
Size: 1164 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170717/fd0433bb/attachment.png>