... The reason I ask this question is because I've read that queues only start working when you reach the max limit on the affected traffic. If my internet connection is never near its maximum capacity are queues even necessary?
You've pinpointed it. Queueing traffic only makes sense if there is competition about the bandwidth. But bear in mind that the competition may exist also in short-term and if there would be no queues at all, packets could be lost even when the bandwidth would be used for 1 %. Imagine that all your 15 IP phones send a RTP packet towards the VoIP provider's equipment at the very same instant of time - without queueing on the interface, only the first of these packets would make it through and the rest would be dropped. So some queue must exist at the egress interface. But multiple queues with priorities between them are not necessary if there is enough bandwidth.
I know the setup on my VoIP providers side is also a factor. Most likely they do not even have more than 1Gbps breakout
but let's assume that they are willing to work with me to set up QoS, what would they need to do?
Most VoIP providers do set DSCP on their outbound traffic, but unless your ISP == your VoIP provider, there is no guarantee that the ISP would respect the VoIP provider's DSCP marking (in some countries discrimination on internet traffic is even illegal).
Second question, I have been considering moving my VoIP server to a hosted environment. I'm planning on connecting my office router to the VoIP server using OpenVPN so that my SIP devices will connect directly to the VoIP server and eliminate the complications that come with NAT'ing VoIP traffic. Does the same apply to VPN connections as per my first question? If not, is their a simple way to protect or prioritise the VPN interface?
A VPN connection is a stream of packets just like any other one, but the encryption of the packets may limit the bandwidth (if the encryption is running in software, the CPU manages to encrypt only some volume of data flow, and hardware encryption also has its capacity limits). This should not be an issue for 15 RTP streams, though.
If you think about using OpenVPN at Mikrotik for VoIP, I wouldn't recommend that as Mikrotik's implementation of OpenVPN is only able to use TCP as transport, and that's bad for VoIP. Everything is fine until the first TCP packet gets lost; if it does, it is retransmitted, and the receiving side does not forward the packets following the lost one although it has already received them until the retransmission of the lost one arrives. So you get jitter values of 100s of milliseconds.
The only type of VPN supported by Mikrotik which is ciphered and uses non-reliable transport (i.e. not retransmitting lost packets on its own) is currently IPsec.
I ended up trying out a combination of the script for DSCP above and tweaking it a bit for download as well. I noticed that I can't set my Max Limit to 10G. It seems 1000M is the highest that can be set. That was the reason for me looking up this thread and got me to thinking about the importance of queues.
I've noticed something like that (max limit of 1000 M) somwehere on this forum.
In terms of our environment, we have about 30 sip devices in a call center and about 10 - 15 active calls at any given time (Tiny, I know XD). Our internet usage hovers around 50 to 100 Mbps during the day with occasional spikes to 200 or 300 Mbps. We haven't had any major complaints about voice quality but I've noticed some audio cut out on occasion. I know if I take this up with my VoIP provider the first thing they will ask is if I have proper QoS in place. I'm not at the stage where I want to investigate call quality yet so I'm just learning a bit more about the proper way to make sure my setup is correct.
This first question of the VoIP provider comes from the fact that many internal company networks have insufficient bandwidth, so even though the uplink is not that busy, the internal connections may drop or delay voice traffic without QoS in place. So sniff at the uplink interface and watch the jitter there. If there is more than 5 ms jitter or even lost packets in outgoing direction, your internal network is worth inspection. If there is more than 5 ms jitter or lost packets in incoming direction, the network path between your VoIP provider and your ISP may be an issue. In practical terms, jitter values below 100 ms rarely cause voice drop-outs as most VoIP equipment has de-jittering buffers which handle that, but such high values already cause some discomfort as 200 ms round-trip delay is at the edge of acceptability.