The problem with QoS?

I remember a couple of years I had an angry customer trying to tell me that everything is okay with his internet connection. He could send and receive emails, and also he could access web sites without major problems. It was just the voice that just did not work properly! I was trying to explain to him that there is a difference between communication that may take a few seconds and communication that should happen within a few milliseconds. He wasn’t very technical and I think I must have lost him with the word milliseconds.

Anyway, today we are not really further with the QoS topic. Bandwidth might be higher, but the fundamental problem is still there. An endpoint like the PBX just cannot enforce it. If someone starts downloading MP3 files or videos and your home network does not have the luxury of a fiber connection, you will probably still face the same problems today. There has been a lot of work in this area, trying to come up with traffic shapers, VPN tunnels and so on. At the end of the day you can say: if you don’t control the router on the other end (provider), you can only increase the probability of QoS, but there is still no guarantee.

So you can’t enforce it, but at least you can measure and log it. That’s the point where RTCP comes into play. This protocol sits next to RTP and provides some additional information about what’s going on with the media. There is even a standard called RTCP-XR, which sends additional information (extended reports). The m9 supports that, and if the other side is able to read it, it can generate nice reports out of it. For example, the snom ONE PBX generates a report for each extension and for each trunk (well, if the other side supports it) that shows you how the quality “mean opinion score” was over the last 24 hours. I attach a picture of a real busy day (okay, it came from a stress test).

What you can see there is that most of the calls were in the 4.1 area, which is usually a good G.711 call (because it is narrow band, G.711 does not make it higher). Some calls obviously had some quality problems, probably some packets dropped or the delay got too long. Some calls even have a score of just 1, which is pretty bad (but at least you could hear something, must be close to smoke signs).

In order to push everyone a little bit, the m9 sends the necessary information in the SDP for all calls and for all PBX types, at least those where we know it does not screw anything else up. This is a kind of “advertisement” for RTCP-XR. I hope that some folks see it in the logs and put it on the to-do list for their PBX!