How to Implement QoS for VoIP/RTP

[Adrien_Aaron]

I'm running R77.30 and Gaia on a cluster of two 4800 series gateways.

My organization recently deployed Cisco IP Communicator softphones to some remote VPN users. However, the other parties to calls often report that the voice of our VPN users is cutting in and out for them. This is caused by delay in our VPN users' RTP voice packets reaching the other party.

To minimize this delay, I'd like to deploy QoS. I've read most of the QoS Admin Guide for R77, so I understand the basic functionality of Check Point QoS, and that I should be using either DiffServ Expedited Forwarding or Low Latency Queuing with priority 1. But I'm not sure how to define RTP as a service when creating a rule in the QoS rulebase. There is no predefined RTP service, so that's not an option. My first thought is to use the actual port range, which is UDP 16384 through 32767. However, my concern is that non-RTP traffic will be matched by this rule and consume bandwidth meant for actual RTP traffic.

I opened a ticket with Check Point support, but this was the response offered,

"

Also I did some research on my end and to my knowledge there is no way to define the RTP service so that only RTP traffic gets matched by the rule. You can create a custom site for ports 16384 through 32767 but you cannot ensure that only RTP traffic matches the rule.

"

Is this true? Since SmartView Tracker can break down VoIP calls and even estimate codecs being used, I would think it has to have a way to effectively implement QoS for VoIP, since VoIP/video are two of the biggest needs for it in the first place.

Does anyone have experience successfully configuring QoS for RTP traffic? Any advice is greatly appreciated.

[PhoneBoy]

TAC is definitely correct here.

Keep in mind that the necessary traffic must be matched by a Firewall and Application Control rule first before QoS applies.

Provided you are using Application Control and properly restricting traffic, there can be a high assurance the traffic that matches is, in fact, RTP related.

There is no way in the QoS policy to say "only apply to RTP" traffic.

[Hugo_vd_Kooij]

QoS in Check Point will not solve latency issues like this.

The whole issue is that if your Check Point firewall inspects traffic at this level you hit other blades and that means those blades will result in latency in the firewall. And that latency is far larger then anything QoS can solve for you.

My advise would to test a policy where you allow all VOIP traffic without getting it into other blades.

This means you may have to change you policy in a (dramatic) way as you must use other services definitions and make sure you use the in you policy before any other service definition in you policy.

In similar cases I was able to get much better results with bypassing blades but it also means you are blind to the content of the traffic. So it is a trade-off you need to make. 

Getting low latency on a Check point firewall means you have to oversize your firewall hardware or make other trade-offs. Remember You can only get 2 out these 3 option: Secure, Cheap, Fast.

In R80(.10) you can build more fitting policies and you can make a better trade-off.  Just not sure if it would be wise to use it on aging 4800's.

[Adrien_Aaron]

Thanks to you both for your thoughtful answers.

Dameon, thanks for your clarification on the point made by Check Point TAC. I'll look into using Application Control to better control services as a first layer, so that traffic which gets through that and is in the aforementioned UDP range is most likely to be RTP.

Hugo, that's an interesting perspective, though I'm admittedly skeptical that QoS would add more latency than it reduces. Why would Check Point design a QoS product which doesn't actually improve the quality of delay-sensitive applications like voice and video? But I do see what you're saying in more general terms, which is that the additional processing by the gateway will add some amount of delay to the RTP packets.

My thinking is that, even if some delay is added, it might not be a problem as long as the amount of delay is within the bounds of the application (less than 150 ms for voice) and the delay is fairly consistent. Jitter, or variation in delay, is also a big problem for VoIP, so if the QoS adds latency but keeps it consistent and less than 150ms, that will probably result in improved voice quality.

Thanks again for your thoughts, and I'll post an update after trying some things and evaluating the results.

[Kenny_De_Man]

Any update on this topic?
We are currently facing the same issue on our 15600, with our VPN gateways running as a VS, on 77.30...

Looking into implementing QoS as well, however as I read above this would not be the proper solution...

[Hugo_vd_Kooij]

Kenny, Nothing new to report here.

There are some trade-offs you need to considere and I think we mentioned the most important ones.

Unfortunatly there is now way to know for sure without doing some extensive tests.

Having said that. Did you look at all at other latency causing issues? With a 15600 appliance you might want to check out some other features that might be useful. Dynamic dispatching is the most prominent issue I would look into.

[Adrien_Aaron]

In my case, I went forward with defining RTP as a new service, UDP ports 16384 through 32767. I then enabled QoS for inbound traffic on our WAN interface, with a QoS policy that guarantees each matching connection 85 Kbps. I set the QoS policy rule tracking action to log so that I can see what traffic is actually getting matched by the rule in SmartView Tracker (you can also set the tracking action to account to see some actual numbers to the latency). VoIP traffic from remote softphone users is correctly being matched by the rule (you can check in SmartView Tracker by filtering the Product column for QoS).

As I mentioned in my first post, I was concerned about non-VoIP traffic being matched by the RTP service I created. It turns out that there is additional traffic being matched, but it's only from the Check Point VPN client's "tunnel_test" service, which uses UDP 18234 as a sort of keepalive. So for the most part, having such a broad range of UDP traffic being matched has not been an issue.

As far as results, our remote VPN users with softphones have indeed reported improved phone calls. I think there may be occasional issues with their voices still cutting out a little bit, but it occurs a lot less than before implementing QoS.

I did not go through the process Hugo described of making sure the traffic bypasses other blades, but perhaps if I did, that would improve the results even more.