Gargoyle Forum

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?

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?

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.

A lot of Layer 7 Protocols no longer work due to encrypted traffic.

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

No idea about other devices

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

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.