During the last week, I’ve been diving down into the RTCP protocol and Asterisk’s implementation of it. What is RTCP? In short, it’s the way to understand what’s going on with your SIP calls on the network.

VoIP relies on the IP network for media transmission

Voice over IP protcols, like SIP, needs to send the media in digital form across the network. The core IP protocols allow for packets to get lost, actually there’s nothing stopping a busy router from just deleting packets it doesn’t have time to deal with. On top of the IP protocol there are two main transport protocols, TCP and UDP. TCP tries to have control of message delivery, so if a router drops a packet, TCP will resend it until it gets confirmation from the other end that the message is received. UDP is like our royal mail service, you have no idea of what happened to the message. If you’re lucky, it will reach the destination.

Interactive realtime conversations are different from downloads

Protocols like HTTP and SMTP for web and email can use TCP and rely on retransmissions, since there is no realtime hurry. A few retransmissions won’t bother you much, but missing data in an e-mail message or web page might be very irritating. For media, especially interactive media, the situation is very different. Retransmissions will not help, since we propably already played the message in your speakers. We can’t reinsert part of a second worth of audio in the media stream after you’ve already enjoyed listening to it. For interactive media, like a phone call, we’re also in a hurry. We can’t wait for missing packets to arrive, since if we delay media too much, the call will break down. You will hear this and if it gets too hard, switch to James Bond walkie-talkie mode. “over”, “over, roger that”, “over and out”…Media for most of the standard VoIP protocols use RTP, the real time protocol. RTP is a way to send media over an IP network. Each message has a time stamp that tells the receiver where the payload fits into the media stream. If a packet is lost, the receiver will discover a glitch in the time stamps. Some receivers insert some noice to prevent you from discovering the issue. Of course, if there are too many packets lost you will notice. 20 milli-seconds here and there will propably go un-noticed in most cases.

Introducing RTCP – the bi-directional reporting system

RTP has a companion protocol called RTCP, the Real Time Control Protocol. This protocol is an out-of-band communication channel between the sender and the receiver. In a phone call, both ends are of course both receiving and sending.  RTCP is used to send reports to the other end, saying “I have sent xxx packets since we started and received yyy packets”. Both ends can then compare data and calculate the packet loss. The reports also include time stamps, so that the round trip time, the time for a packet to travel between the devices, can be measured. There are many pieces of data, and also a standard for extended reports that will deliver a bit more data.If a device, like an Asterisk server, collects this data, we can measure not only the quality of a particular phone call. We can gather data and get hints about issues with SIP trunks to a particular provider, about users on weak WiFi networks in hotels and a lot of other situations. We could potentially deliver this data in real time and alert users when the link is really bad, midcall.There are also advanced codecs that are adaptive to the situation and could use this data in real time. If the network shows signs of problems, the codec can try to change the flow of data – size of packets sent, rate of packets or other properties, like error correction and packet loss concealment.

Project Pinefrog – improvements to Asterisk’s RTCP support

Asterisk today has a very simple implementation of RTCP reports that isn’t very useful, but still a very good starting point. I’ve been working to make it a bit more useful by sending reports over manager, storing quality data in a database and also trying to improve the NAT support for RTCP. I’ve been testing a large number of phones to see how they have implemented RTCP and how Asterisk handles the received data. Hopefully, the turnout will be a large improvement and help us all in getting better and managed quality for our Internet telephony.This work is sponsored by a few companies in the Asterisk community who answered my earlier call for sponsorships.  I am always happy when things work out and Asterisk users step forward and contribute to the process of creating a better version of Asterisk. Being able to get quality data about the calls is a huge improvement for all of us that use the Internet as a transport for our telephone calls. As always your feedback is as welcome as the RTCP feedback on our SIP calls!