OpenVPN SIP traffic for external phones.
-
I'm using Yealink SIP-T21P E2
-
I messed around with the various traffic shaper options to provide QOS for my SIP phones but in the end the best one was simply putting CODELQ on the WAN and LAN interfaces.
CODELQ correctly configured removed the so called "buffer bloat" which in my case was causing a fair bit of random jitter on the SIP phones.
-
Thank you for your input pahowart.
Were you phones connected via OpenVPN or directly with SIP?
-
Unless you've changed from the default, OpenVPN uses UDP port 1194.
They traffic shaper needs to be configured to recognize this. It will be blind to actual SIP/RTP packets inside the OpenVPN since that is between the phones and the PBX.
You can use the shaper wizard to create a VoIP queue, and then use the floating rules to match source/dest + port and put it into the VoIP queue. -
Hi awebster
Have you done this in a real world scenario?
Could you please detail how would this work?
Thank you!
-
What I've done in this case is create an interface and assign the openvpn interface to it. This way you're able to create rules on firewall floating tab which will match traffic inside the tunnel.
-
The easiest thing to do is just prioritize the OpenVPN tunnel itself. As has been said you will already have a rule for UDP/1194 (the default) on WAN so you can just set the queues there.
Keep in mind that you can queue what you send out WAN (uploads). Identifying how you queue out LAN (downloads) is more difficult. Especially with multiple LAN interfaces.
There are probably some magic numbers to get better latency but I haven't had much luck finding them.
Setting queues on an OpenVPN assigned interface to try to queue traffic inside the tunnel has resulted in a couple 100%-CPU-with-no-significant-traffic situations for me. Didn't really investigate very hard. I stopped the practice and just queue the tunnel traffic instead. YMMV.
-
Although this tunnel is for SIP only, I've found myself that you can never queue inbound openvpn traffic, besides its not possible to queue another type of traffic with @Derelict's solution. thats why you need an openvpn interface.
I hasn't experienced 100% cpu problem with my setups, something may be wrong with yours. -
All I know is the problem started when I added queues to rules on my assigned interface and it stopped when I took them out.
Just throwing it out there.
-
@vianneyjs could you share the firewall rules? I am trying to achieve the same with Snom phones that support OpenVPN, however phones do not register FreePBX running on the LAN.
-
You probably want to start a new thread.