In version 5.1 we have introduced something that cannot be called a feature, a setting that disables RTCP-XR on trunks. This is sad, but we have to deal with reality.

What is RTCP-XR? RTCP stands for Real Time Control Protocol. It pairs with the RTP protocol, which is used for sending the audio and video real time media. While RTP deals with the media itself, RTCP deals with the stuff around it, thus the word "control." Control information may contain a name for the media, notifications for when the media gets disconnected, and also information about its performance.

Especially important are reports about how long it takes to send the media from the sender to the recipient. Other interesting information is how much jitter the media had, meaning how much the packet arrival time varied compared to the ideal arrival time. Over time, RTCP has evolved into an important tool for troubleshooting media transport problems.

That’s where RTCP-XR came in. The XR stands for "extended report." Because what RTCP could deliver was limited, the IETF working groups came up with something more elaborate. RTCP-XR can deliver a very detailed report on which packets actually made it and even what their receipt timestamps are. RTCP-XR can be seen as a recording solution for the packet delivery, thus documenting service level agreements. In times of big data, this sounds like an exciting way to ensure the services in the cloud perform well.

But RTCP-XR is also a lot about compressing the information. That’s where statistics comes in. On the lower layers, RTCP-XR deals with arrival statistics; it bursts when packets are completely missing and the codecs that have been used. The ultimate compression is giving the call as a whole a score. It's hard to describe how a person perceives audio quality, but RTCP-XR gives it a try and comes up with a mean opinion score (MOS). This is a number for how a caller would rate the call on a scale between 1 and 5 (you might have noticed the reports on the snom ONE web interface).

Because RTCP-XR is obviously not backward compatible, it must be negotiated between the sender and the receiver: the IETF document proposes adding a line to the SDP that's used to set the session up. There, both parties can negotiate if and what RTCP-XR information should be collected.

So far so good.

In the real world, there are only few devices that support RTCP-XR. snom introduced it a couple of years ago, and Polycom was amongst the first to offer it. Most devices don’t offer it, silently ignoring the line in the SDP as they should.

The problem is many service providers are using equipment that gets suspicious when they receive SDP content they don’t understand. And when they don’t understand something, they reject it. That’s when snom ONE customers start to complain that snom ONE doesn't work with service provider XYZ, while their free softphone does.

I am actually not aware of a single service provider that supports RTCP-XR; it seems customers compress the service provider quality essentially to the price, and not to its quality or reporting it.

The only way out here was to introduce a setting on the trunk that suppresses the advertisement of the extended reports and set it to suppress by default. Thanks to the drop-down menu we recently introduced, we can add it selectively back if certain service providers start supporting it.