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

What is RTCP-XR? First of all, 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 name control. Control information may contain a name for the media, notifications when the media gets disconnected, but 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 was varying 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 that 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, 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 is 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 how a caller would rate the call in 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. For that, the IETF document proposes adding a line to the SDP that is 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 has introduced it a couple of years ago, and also Polycom was amongst the first to offer it. Most devices don’t offer it, and silently ignore the line in the SDP as they should.

The problem is that many service providers are using equipment that gets suspicious when they receive SDP content that 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 does not work with service provider XYZ, while their free softphone does.

I am actually not aware about a single service provider that supports RTCP-XR. It seems that customers compress the service provider quality essentially to the price, and not quality or at least 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 that we have introduced recently, we are able to add it selectively back if certain service providers should start supporting it.