QoS for Skype

Report issues relating to bandwith monitoring, bandwidth quotas or QoS in this forum.

Moderator: Moderators

Post Reply
nworbnhoj
Posts: 916
Joined: Mon Jul 21, 2014 10:08 am
Location: Australia
Contact:

QoS for Skype

Post by nworbnhoj »

A while back I attempted to setup QoS for Skype using Application (Layer7) Protocol and assign the traffic to the default VoIP service class. As promised in the Gargoyle Documentation this did not work.
L7 Pattern Matching wrote:As a result I do not recommend this type of matching and may remove it entirely from Gargoyle in the future. The authors of the L7 matching code seem to agree having pretty much given up maintain or improving the code.
As an alternate I have created a QoS rule that assigns all UDP traffic to the VoIP service class. This works, but this is obviously not ideal.

Is there a better way to achieve this?
Can you help someone else get Gargoyle up and running?
TL-WDR3600 : Gargoyle 1.9.0 : NBN FixedWireless
TL-WR1043ND-V2 : Gargoyle 1.8.0 : 3G Huawei E160E

pbix
Developer
Posts: 1373
Joined: Fri Aug 21, 2009 5:09 pm

Re: QoS for Skype

Post by pbix »

What I do is use the IP address of the devices that I use Skype on plus UDP. This insures that traffic from other devices do not end up in my VOIP class. I find that this is pretty close to ideal. It is not common for other applications to use UDP on the WAN connection. Even Skype will change to TCP when it cannot establish a connection with UDP.

Are you saying that lots of other traffic is finding its way into your VoIP class? What is the source of this traffic?
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

nworbnhoj
Posts: 916
Joined: Mon Jul 21, 2014 10:08 am
Location: Australia
Contact:

Re: QoS for Skype

Post by nworbnhoj »

pbix wrote:What I do is use the IP address of the devices that I use Skype on plus UDP. This insures that traffic from other devices do not end up in my VOIP class.
Thanks yes - I had mulled over such a refinement but it seemed a bit hacky.
pbix wrote:Are you saying that lots of other traffic is finding its way into your VoIP class?
Nope - it just felt like I was using a sledgehammer - it bugs me and I was wondering if there was a better way. I guess not.

Thanks for the reply.
Can you help someone else get Gargoyle up and running?
TL-WDR3600 : Gargoyle 1.9.0 : NBN FixedWireless
TL-WR1043ND-V2 : Gargoyle 1.8.0 : 3G Huawei E160E

encro
Posts: 76
Joined: Fri Mar 13, 2015 10:52 am
Location: au.victoria

Re: QoS for Skype

Post by encro »

A lot of Layer 7 Protocols no longer work due to encrypted traffic.
Netgear WNDR3700v4 (N600) - Gargoyle 1.14.x
D-Link DIR-835 - Gargoyle 1.7.1 (Deceased)
Manual set up for PIA's OpenVPN in (Private Internet Access): https://www.gargoyle-router.com/phpbb/viewtopic.php?f=11&t=9129&p=45410#p45410

francisuk1989
Posts: 30
Joined: Thu Sep 24, 2015 4:46 am
Location: United Kingdom
Contact:

Re: QoS for Skype

Post by francisuk1989 »

There is one way for PCs/Laptops both Linux/Windows/Mac's but means all Video calls and Voice Calls :o

No idea about other devices :roll:

Skype > Options > Advanced > Connections

Use 45532 for incoming connections
Untick UPnP

This would use TCP/UDP port 45532 source from you PC/Laptop example 192.168.0.4:45532 -> 185.x.x.x:xxxx

Proof
Image
TP-Link TL-WDR3600 v1.5 (ar71xx)
EE Brightbox 1/Arcadyan AR7516 (BCM63xx)
MK RB750r2 - OpenWrt Snapshot ar71xx
D-Link DIR-615 D2 - OpenWrt (ramips/rt305x)
AWS Region Latency Checker # http://awsspeedtest.xvf.dk

m45t3r
Posts: 4
Joined: Thu Jan 08, 2015 6:44 pm

Re: QoS for Skype

Post by m45t3r »

Sorry to bump this thread, however I want to post my solution for QoS rules for Skype somewhere, for future reference (and to avoid something like this in the future https://xkcd.com/979/).

From another topic (viewtopic.php?p=17026#p17026), setting a rule using Protocol: UDP and Maximum Packet Length: 400 seems to work corrrectly, since the majority of Skype traffic goes to my VoIP rule. But some BitTorrent traffic using this rule goes in the VoIP rule too.

It is not the majority of them, actually for Download traffic seems to be a very small quantity (like 5kbps), that wouldn't matter. However in Upload this seems to be much more severe, comming at up-to 200kbps in my 10/1mbps ADSL2+ internet. And since the Upload speed is much more limited than Download for the majority of internet connections, this is problematic.

So I decided to do an experience, setting the same settings above and Minimum Packet Length: 200. And now only 5kbps of BitTorrent traffic goes to VoIP, a great improvement, while Skype is still correctly target at VoIP rule.

I think this works because the majority of BitTorrent in UDP protocol is composed of either a big packet with data or a small packet for control. So without the minimum Minimum Packet Length those packet for control were classified as VoIP too. And Skype UDP packets seems to be in size range from 200-400 bytes. I didn't run a Wireshark or something to confirm my hypothesis, however if someone wants to run it would be interesting.

TL;DR: for a general Skype QoS rule that works for every computer in your network and does not capture UDP BitTorrent packets, use the following settings in both QoS Upload and Download:

  • Maximum Packet Length: 400 bytes
    Minimum Packet Length: 200 bytes
    Transport Protocol: UDP


Edit: Forget what I said above, after some more tests with a real conference instead of Skype Call Test, it seems it simple it does not work. However, after firing up Wireshark and analyzing some packets, it seems really simple to solve this problem.

Going to Options->Advanced->Connection you can set up a port number for incoming connections. Creating a rule for UDP connection setting this port as a target seems to work. However, instead of setting Source Port in Download and Destination Port in Upload, you need to reverse it, putting Source Port in Download and Destination Port in Upload. Unchecking Use port 80 and 443 as alternatives for incoming connections should help to make sure that Skype will use the desired port.

This should be thanks to the fact that you're both a client and a server in Skype.

Post Reply