So, we are going to be using a new company for our voip services and I was wondering how good is VyOS/Vyatta with voip, and what do I need to do to make sure the quality is as good as it can be?
I believe the company that is being discussed is five9 – not sure – and I need to make sure everything works smooth, because the current voip provider (telonium) seems to have issues with quality, even when running on dedicated fiber 20/20. Yet they swear it is bandwidth or configuration issues. The customer service people complain that they keep getting calls coming through, while they are on other calls – some issue with the queue. But when they call Telonium, they are told that this is due to bandwidth issues. Another issue they complain about is the fact that sometimes they can hear the customer, but the customer cannot hear them. I know this is usually a quality issue, and is likely related to bandwidth. However, we have since moved these lines to a dedicated 20/20 fiber and separated them from the rest of the network, so these problems should not exist.
I have never ran these lines through the VyOS router, because I only installed the VyOS router a week ago. Presently, I am running the fiber through an Apple Time Machine (or AirPort?), but the phones are the only thing connected to it, yet the issue with the queue persists. I don’t see any reason why configuration would affect the phones in this case, since there is no other traffic going through it but the phones. I don’t think I need to prioritize voip when voip is the only traffic, right?
Anyway, my main concern now is the configuration of my VyOS router, because I will have to run everything through VyOS now that they plan on using five9, a cloud based service. Is there anything in particular I need to look at? Like a reference guide? Is there an option to simply optimize all voip traffic (as a service type), rather than having to prioritize specific ports?
Yes, I believe that the problem with the audio was probably caused by bandwidth issues, because we have several consoles and other devices using up the bandwidth. However, at one point I had the phones plugged in to another coax connection with 50/15 connection, and they still had the same issue. I am not sure if they are still having issues with voice, but they still have problems with queues failing to hold calls, instead of forwarding them to someone who is already on a call. What I would like to do is be prepared with the VyOS router, so I don’t have to face the same issue again. I plan on routing specific data through my 2nd connection, but I want to know is the easiest way to prioritize voip traffic in VyOS. I am not familiar with DSCP marking, so I will have to research that.
So I found a paper on Cisco’s site explaining different ways of providing QoS for VoIP voice and it has some good information on DSCP. I also found a guide someone made using DSCP in Vyatta. I will give it a try. Thanks for the info!
In my company we using VyOS router witch VoIP (asterisk, hylafax, smstools,etc), and we connect difrent localization via ipsec tunnel (fibre link). Quality is ok, I add only system conntrack witch sip configuration to any router with voip transmission.
[quote]show system conntrack
expect-table-size 2048
hash-size 32768
modules {
sip {
enable-indirect-media
enable-indirect-signalling
port 5060
}
}
table-size 262144
[/quote]
Not always. Usually when NAT & helper modules are involved, you have issues with translating (or not) the embedded IP addresses in SIP & SDP payloads. It often depends on the remote sides VoIP infrastructure (expensive session border controllers/sip servers can usually handle NAT issues). If SIP re-invites are in use, they can be dropped by an edge router if they are not matched as related traffic. After a few re-invite retries, the call can drop too. VoIP and NAT is pretty nasty, and I highly recommend you carry VoIP over private IP links without NAT, or ensure your edge voice gateway server is on public IP.
With respect to VyOS and voice quality, the trick is to reserve enough bandwidth for however many voice channels you are likely to have simultaneously, plus some bandwidth for signalling. Then you have priority queues for VoIP related traffic to minimise jitter and latency. You may also have the issue of not being able to control ingress traffic (ISP → your edge). This can be alleviated with ingress traffic-shaping on your WAN interface, but is still something you can’t always control (i.e. if somebody decides to send X Mbit/s of IP packets to your edge, your shaping will be ineffective)
It is recommended to have a dedicated data path rather than play with QoS though, as it’s tricky to get right and there are cons like the above.
cgb,
Are you talking about VPN tunnels to the provider? I have acquired a set of public IPs for use with my router, as this would really make it easy to run other services (e.g., VPN, Cloud Services, Mail). I am aware that some providers normally use VPN tunnels to connect their equipment to their servers, but I don’t know if five9 (the company that will take over the phones) has this setup, or something else. I guess it is time to ask. VyOS be able to establish a link of this sort? Or would I need some other solution?
Also, wouldn’t I still need some type of QoS to control all the other data? I mean, I would still need to prioritize DSCP and minimize bandwidth usage from other systems, right? The phones that we are going to be using are going to run over the PC connection, so they will need to be separated from other TCP traffic.
You can directly control the order of the outgoing packets from the Vyos device, but you have only limited indirect control of the order of the packets arriving from your voip provider over the internet into the Vyos device. Your internet access provider should enable/support QOS, so that packets marked by your voip provider don’t suffer excessive jitter/latency.
On the outbound side, you have full control. I use something like:
set traffic-policy shaper 510sg-t1 bandwidth '1500kbit'
set traffic-policy shaper 510sg-t1 class 2 bandwidth '30%'
set traffic-policy shaper 510sg-t1 class 2 burst '2kb'
set traffic-policy shaper 510sg-t1 class 2 ceiling '100%'
set traffic-policy shaper 510sg-t1 class 2 description 'syn ack bufferbloat'
set traffic-policy shaper 510sg-t1 class 2 match tiny4 ip 'small'
set traffic-policy shaper 510sg-t1 class 2 match tiny6 ipv6 'small'
set traffic-policy shaper 510sg-t1 class 2 queue-type 'fq-codel'
set traffic-policy shaper 510sg-t1 class 2 target '15'
set traffic-policy shaper 510sg-t1 class 10 bandwidth '15%'
set traffic-policy shaper 510sg-t1 class 10 burst '2kb'
set traffic-policy shaper 510sg-t1 class 10 ceiling '100%'
set traffic-policy shaper 510sg-t1 class 10 description 'voip rtp traffic'
set traffic-policy shaper 510sg-t1 class 10 match voip-rtp ip dscp '46'
set traffic-policy shaper 510sg-t1 class 10 queue-type 'fq-codel'
set traffic-policy shaper 510sg-t1 class 10 target '15'
set traffic-policy shaper 510sg-t1 class 20 bandwidth '5%'
set traffic-policy shaper 510sg-t1 class 20 burst '2kb'
set traffic-policy shaper 510sg-t1 class 20 ceiling '100%'
set traffic-policy shaper 510sg-t1 class 20 description 'voip sip traffic'
set traffic-policy shaper 510sg-t1 class 20 match voip-sip ip dscp '26'
set traffic-policy shaper 510sg-t1 class 20 queue-type 'fq-codel'
set traffic-policy shaper 510sg-t1 class 20 target '15'
set traffic-policy shaper 510sg-t1 default bandwidth '50%'
set traffic-policy shaper 510sg-t1 default burst '2kb'
set traffic-policy shaper 510sg-t1 default ceiling '100%'
set traffic-policy shaper 510sg-t1 default queue-type 'fq-codel'
set traffic-policy shaper 510sg-t1 default target '15'
with phones that mark their packets with dscp, and with the patches at 510 Software Group (which enable fq-codel queueing). Basically, you want to give priority to small packets (syn, syn-ack, etc), and voip packets.
Not VPN tunnels. I was referring to a design where you have two WAN links - general Internet and a second WAN link for VoIP, often a private IP service with your voice provider to guarantee bandwidth & remove the possibility competing flows.
Yes, on a shared link that carries voice and Internet traffic, you’ll need to guarantee bandwidth for voice channels and prioritise VoIP protocols (signalling & voice) and small packets for outbound transmission. You have less control over inbound flows as all you can do is delay or drop already received packets.
If your Internet and Voip providers are different, and you share a WAN link for both types of data, all bets are off on the treatmeant of those DSCP marked packets in your Internet providers network and onwards.
I do have a dedicated fiber connection for it. But the problem is that they look for their own solutions without asking me, and now they are looking at some cloud based solution, that will make use of USB SIP phones that will plug to theri PCs. This means that I will need to find a way to separate traffic, and somehow redirect it to the dedicated fiber. I have been looking for a solution that would do this, as microlinux was looking for last year.
I don’t want to redirect the whole vlan / subnet, because they use their PCs for browsing the internet - checking email, work orders, etc. So they do make use of the data bandwidth.
It should definitely be achievable that you policy route appropriate traffic out a different gateway based on some critieria (UDP port range X-Y, dest ip a.b.c.d). In a test environment, get something basic working (policy route traffic to 8.8.8.8 for example) and then adapt to match your desired traffic.
Wow! That is actually what I was looking for. I found a Brocade example and that seems to be the exact solution I was looking for. Thanks!
Source Routing Example
So I have been testing the policy route and it seems to not work when I do my tests in vbox – traceroute and iptraf reports show it fails. I am not sure if this is a result of some issue with vbox, or if it is VyOS. NAT, on the other hand, works well when I look at iptraf – I can see how data is directed to eth0 or eth1, based on the destination IP address. Traceroute does not show any difference when displaying the hops. It does not matter what destination I am tracing, it shows the same hop (eth1’s gateway), so I don’t know what is the deal with that. The fact that I see activity on appropriate interface through iptraf is a good sign, though. Of course, I would like to do some more testing with a more reliable setup, so I will install my XenServer and test from there.
At first, this worked, and now it is not working. As I monitored the traffic in iptraf, I could see the two interfaces active, eth2 and 1, or eth2 and 0, depending on which IP I was pinging. Now it does not work, it all goes through eth0.
traceroute to 75.75.75.75 (75.75.75.75), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.154 ms 0.089 ms 0.060 ms
2 10.0.3.2 (10.0.3.2) 0.109 ms 0.580 ms 0.551 ms
3 * * *
4 * * *
5 * * *
PING 75.75.75.75 (75.75.75.75) 56(84) bytes of data.
64 bytes from 75.75.75.75: icmp_req=1 ttl=57 time=14.2 ms
64 bytes from 75.75.75.75: icmp_req=2 ttl=57 time=12.7 ms
As you can see, the above looks just like the one below.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.135 ms 0.086 ms 0.103 ms
2 10.0.3.2 (10.0.3.2) 0.158 ms 0.107 ms 0.203 ms
3 * * *
4 * * *
5 * * *
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=55 time=17.7 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=55 time=23.3 ms
