vicidial.org

Is it possible to move vicibox to opensuse to a lxd container in the forseeable future?

LXD containers have near bare-metal performance with ease of management for admins.

We have clients that have used OpenVZ containers, and while they are better than virtual machines, there are still downsides, including resource allocation issues if you are trying to run more than one VICIdial server on the same hardware machine. You can try it, but we still don't recommend using them.

vkad wrote:Is it possible to move vicibox to opensuse to a lxd container in the forseeable future?

LXD containers have near bare-metal performance with ease of management for admins.

Vicidial will happily run in any environment capable of running the OS. But bottleneck crashes will occur in any virtualized environment which will greatly reduce capacity so you will never reliably be able to run more than one vicidial in one hardware machine.

If unsure, test it! Just be prepared for reduced capacity (in the extreme depending on the technology involved). We use virtual for up to two agents and for sandboxing all the time. The server doesn't know it's virtual, but when it begins to miss CPU ticks ... stability fails. So this depends a lot on your usage. If you have less than 10 agents and want to move a single Vicidial to a virtualized container for management reasons, you may succeed.

IMHO: You are better off working out your management issues on a hardware-based Vicidial server. Those wheels exist, you don't need to reinvent them. Any form of management you need likely already exists (although most aren't hard to build, often in less time than installing an existing one!). And no danger of crippling your Vicidial system. Just my opinion.

You will have shared kernel problems with meetme probably.

The sole purpose would have been to run 1 vicidial per hardware. Keep the DB dedicated. Just spread out a lot of diallers on digitalocean/vultr/openvz on $10 nodes with 1-2 agents each with a total of 20 agents on 10 nodes dialling 1:10.

vkad wrote:... 1 vicidial per hardware. Keep the DB dedicated.... $10 nodes with 1-2 agents each ...

And you're sure each node is a piece of dedicated hardware? I'm on board for a test (especially if you're doing it), but I strongly suspect you'll find that those are sharing enough to break the dialer OR cost the same or more than just renting one server for each 25 agents. $10/mo for 1 agent = $250/mo for 25 agents and a LOT more setup involved.

So many servers clustered together will likely cause a bit of backlash with transfers between servers for available agents. The complexity of a 20-dialer cluster is not something to ignore.

But if you have one agent per dedicated hardware and want to build it up to 4-5 agents for testing, you may get away with it. Report back.

I share most of William's doubts on that setup, although 20 dialers on a cluster is no problem with the right database. Our largest single cluster right now has 26 dialers, and it works just fine.

I have run this with 8 agents per server dialiang 1:10 on a 4 core 8GB $40 node and it is working fine on vultr.
Total agents 30 (however we did experience slow dialing. dont know if its the leads, the carrier or the VMs). All diallers on only public ip's with latency of 10-20ms.

The calls quality was good and load average most of the times was below 3.

BTW, this was on KVM.

The db was dedicated on i7-3770 with 16gb ddr3.
Did about 150k calls.


The thing that confuses me is how balance dialing is working between the servers on different public ips (I have only allowed firewall to access to db <-> diallers)
The diallers don't have unrestricted access to other dialers in this particular setup. Port 5060 is closed in firewall. Agents are on webrtc. Only port 8089 is open.
How are diallers loadbalancing on each other with public ips?

dialers send calls to each other over UDP port 4569, the IAX port.

And they cross-register to each other, which likely opens the ports ... unless your "closed ports" assertion was merely wrong (happens to all techs over time ... we have a firewall-watch system that alerts us when a tech leaves a system open by accident!).

You should (if possible) have the servers use a private network for inter-communication. That private network would then NOT have any firewall requirements at all. Faster decisions.

I always run port scans after verifying the firewall is running. And the firewall is running.

The port 4569 is not open to public so how are dialers able to "cross-register" on public IPs?. Is it opened only for the public IP addresses of the other dialers in the cluster?

Should dialers be able to connect on 4569 to other dialers on a public IP even on closed Firewall?

Thanks

Firewalls are closed only in one direction. But if both servers assert their need to see each other ... on the same port ...

Note that your firewall is closed, but when you register a SIP trunk you'll get those inbound calls.

williamconley wrote:You should (if possible) have the servers use a private network for inter-communication. That private network would then NOT have any firewall requirements at all. Faster decisions.

Definitely agree with the private network requirement, but this campaign is for a charity and they are cash strapped. Asking them to shell out $$$s for a private network or colocation will be hard.
I am giving my services for free, and the voip company has pledged a 10% discount. Almost all agents being volunteers from all over the England as far as I know.

It would be great if I could get it keep working on digital ocean or vultr with just public IPs. The db server (re purposed i7 3770) is hosted in their office.

williamconley wrote:Firewalls are closed only in one direction. But if both servers assert their need to see each other ... on the same port ...

Note that your firewall is closed, but when you register a SIP trunk you'll get those inbound calls.

I understand the registration process, I just couldn't make sense of how two servers with closed ports let traffic through to each other in the first place, but it makes a lot more sense now.

How is the IAX registration protected? Is there any password somewhere shared amongst the dialers? How are they authenticating?

mflorell wrote:dialers send calls to each other over UDP port 4569, the IAX port.

Is the transmission secure by default?

No, IAX is not secure at all.

mflorell wrote:No, IAX is not secure at all.

What I mean to say is whether there is danger of "stranger" servers being able to initiate calls from these public dialer servers in our cluster even if IAX and SIP ports are closed off in the firewall (but ofcourse the servers in the cluster are cross-registering to eachother over public IPs)

Thanks

No, as long as you have sufficient passwords for the accounts, and you have "allowguest=no" in your sip.conf, it shouldn't allow stranger-server calls to be placed.

Ok, great. Once again, how does the server initiate the contact in the first place if the ports are closed?