Hi Everyone
As I am just dipping my foot in the VOIP waters so please bear with me. Although it may be more appropriate for Freeswitch group I am sure there are plenty of knowledgeable folks here.
I'm playing with freeswitch in my lab environment and really like what Kamailio has got to offer. That being said, there are few concepts I need help understanding.
Consider this ( for hosted services I suppose )
[image: Screenshot 2020-09-16 at 22.21.22.png]
1 Does this topology seem right ? 2 If Kamailio is used as registar and load balancer, does that mean all domains, extensions must be present on all the FS boxes ? 3 How will auto provisioning work in this case ?
Now, in the below scenario, clients have got FS box deployed on prem
[image: Screenshot 2020-09-16 at 22.28.09.png] 4 Is there any reason to keep the FS farm ? or Kamailio poxying calls to VOIP providers is enough ? 5 What roles Kamailio could be used for in this case ? 6 Is deploying on prem PBX for a customer a popular solution ?
7 Anyone deployed above on Docker/ Kubernetes ? How's the performance and the bad bits if any ?
I do realize this is pretty basic stuff for everyone in here, however, I would appreciate any helpful comments and if there is some good literature/ links you can recommend, I am all ears.
Regards Adam
Adam,
See inline:
On 2020-09-16 18:35, Adam Rutkowski wrote:
1 Does this topology seem right ?
"Right" isn't very addressable. It is a possible topology.
2 If Kamailio is used as registar and load balancer, does that mean all domains, extensions must be present on all the FS boxes ?
No; the endpoints can be reached through Kamailio over a trunk/bridge, e.g.
<action application="bridge" data="sofia/$PROFILE/$NUMBER@kamailio"/>
3 How will auto provisioning work in this case ?
I don't know much about Freeswitch autoprovisioning, but as I understand it, it works over HTTP and the URL is pushed over DHCP option 66 (i.e. the TFTP server option). Centralising the registrar won't change that.
4 Is there any reason to keep the FS farm ? or Kamailio poxying calls to VOIP providers is enough ?
Kamailio proxying the calls to VoIP providers is enough.
... on a technical level, anyway. Practically, this question hits upon a complex controversy that draws a broad array of disciplinary knowledge in VoIP. Whether a proxy is suitable as a carrier interface depends on, among other things:
1. Interoperability - whether the UAs on both sides can talk to each other through the very "thin" interoperability layer of a proxy, and also whether the carrier and customer gateways properly handle proxies (as the core SIP standard, RFC 3261, requires). Mishandling of Record-Route and things like that is fairly common;
2. Network topology hiding needs - proxies don't hide topology, and the addressing on both sides is readily exposed in SIP headers (though Kamailio does have 'topoh' and 'topos' modules as possible solutions to this problem);
3. Policy.
These are the waters in which the Session Border Controller (SBC) industry swims. At the risk of self-dealing, here's one of my articles on the subject:
http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/
And an admittedly opinionated conference talk:
https://www.youtube.com/watch?v=j-0C6eHfocI
5 What roles Kamailio could be used for in this case ?
That's a bit vague.
6 Is deploying on prem PBX for a customer a popular solution ?
Not at all (anymore), with the possible exception of large organisations and enterprises.
7 Anyone deployed above on Docker/ Kubernetes ? How's the performance and the bad bits if any ?
Kamailio will run in Docker containers. "Docker/Kubernetes" is hard to parse; Docker and Kubernetes aren't remotely the same thing, do not belong in the same taxonomic category, aren't interchangeable bits of vocabulary, etc.
Otherwise, it's a really complicated and unwieldy question to address due to its breadth. Kubernetes is a complete universe unto itself and then some. As always, architectural choices of various kinds confer many costs, benefits and trade-offs. A little Googling will drum up some talks on Kamailio and Kubernetes, and the various shims and adaptation layers required to do Kamailio things the Kubernetes way.
But ultimately, it comes down to more fundamental issues around the merits of containerisation and various models of container deployment.
-- Alex