I’ve been on a Wireshark binge these past few weeks. In November, I took you on a tour of a SIP conference in Dissecting a SIP Conference Call and in December you got to see the nitty-gritty of transfer in Dissecting SIP Transfer and media transmission in A Wireshark View of Real-Time Protocol (RTP). Clearly, I am not the only geek around these parts because all three articles received quite a few views and continue to trend fairly high.
I am going to press my luck a little further and write about RTP’s sister protocol, Real-Time Control Protocol (RTCP). As you already know, RTP is used to transmit media between peers. As data are being sent, RTCP packets are periodically generated by both the sender and the receiver. However, unlike RTP, they don’t contain media. Instead, RTCP packets are used to report statistics about the ongoing call.
Although I don’t know if this is required, I have always seen RTP sent on an even numbered port and RTCP on the adjacent odd numbered port. For example, if RTP is sent on port 5000, RTCP will be sent on port 5001.
This article is meant to be a high level explanation of RTCP. For those of you who require a deeper dive, I suggest you take a look at RFC 3550. It may put you to sleep, but it’s the ultimate authority on both RTP and RTCP.
If you were to do a Wireshark trace of a basic SIP telephone call, you will notice a few things. First, there are very few SIP messages involved in setting up a call. In fact, you can usually get by with only five messages.
Second, there are a ton of RTP messages generated by the sender and the receiver. These packets will be small and are sent using UDP.
Third, while you may see thousands of RTP messages for a fairly short call, you will only see a handful of RTCP packets. The ratio for RTCP to RTP is not static, but dependent on a number of factors including bandwidth and the number of participants in a conversation. I will refer you to the RFC for a detailed explanation of how the ratio is calculated, but it’s enough to know that they are sent infrequently compared to RTP.
There are five different reports used by RTCP:
- Sender Report (SR)
- Receiver Report (RR)
- Source Description (SDES)
- End of Participation (BYE)
- Application Specific (APP)
When I first read about the different reports, I expected to see them appear in separate packets. I quickly learned that a single RTCP packet can contain more than one report. In fact, you typically see a minimum of two in the same packet – SR and SDES.
I’ve never encountered RR or APP reports, but I am not surprised. RR reports are sent by passive participants (participants that do not send RTP packets) and APP reports are used by applications to extend RTCP with custom data. None of the clients I typically work with act in these manners.
The following is a packet commonly seen in a point-to-point audio call:
Note that this message contains both a Sender Report and a Source Description. If I open up the SR, we see the following:
The SR will tell you the sender’s packet and octet count. In this example, we see that 3673 RTP packets have been sent.
We also see a value for inter-arrival jitter. This can be used to determine the quality of service of this call. In this example, the jitter is 42. RTCP expresses jitter in timestamp units.
If I open up the Source Description, we see this:
Here, I look at CNAME to learn a few things about the sender. Granted, I don’t see much here, but it may be useful for the recipient.
The next commonly seen RTCP packet is the BYE report. Here is an example:
Note that this packet contains three reports – SR, SDES, and BYE. If I open up the Bye report we see the following:
A BYE packet is sent when a participant leaves an RTP session. In the case of a point-to-point call, both the caller and the called parties will send BYE reports.
Mischief Managed
Well, there you have it. I purposely glossed over the complexities of RTCP, but for the most part, you don’t need to know them. Knowing that they are generated and can be used to create QoS reports should be good enough for most people. Heck, it’s good enough for me and I do this for a living.
Tao, Zen, and Tomorrow 
Quite informative topic Andrew. Its a good info to start with; As you said, rest is RFC;
Hi Andrew,
Thanks for this informative article.
Can you please explain as to how we can correlate an RTCP report to the RTP.?
As you mentioned i can see very few RTCP packets as compared to hundreds or perhaps thousands of RTP packets. In this context how can I identify one way audio calls?
Many thanks!
The RTCP IP address will be the same as the RTP and the port will be one more from that of the RTP.
Hi,
Do you know where i could find rtcp wireshark cature file or example file to validate my parser ?
Best regards
Do you have the ability to trace SIP call? RTCP will be there.
Not easily except if I install a sip proxy and a soft phone but it takes time (-;
Is it possible to get a copy of the file that you use to write your tutorial ?
Hi, Andrew
May be you can answer a questioin, which is not clearly described in RFC1889: it tells that only the CNAME item in RTCP packets is mandatory. But there is one more SDES field=END, which is also neccessary (from my point of view).
Can you share your view on this SDES field?
Troubleshooting VoiP issues in the past I never really honed in on the RTCP portion of a call. That is, the focus for me has always been the RTP stream and the SIP portion associated with the call. I’m surprised to see some of the influence that RTCP can have but can it actually be responsible for the VoIP calls (RTP) fate (i.e. tear down). I had always thought it was SIP that was the sole protocol for “controlling” all the modes (i.e. initiation, tear down etc.) of the RTP stream. I had always thought RTCP’s role was just a companion to report feedback and not really get involved with the actual fate of a VoIP call? That is, that is the role of SIP (I thought)? Just getting the vibe with some of the RTCP reading that there can be some influence on the media stream outside of SIP.
Thanks
Keith B.
When you calculate RX losses on a SIP proxy, it’s the loss up to that point. Does the SIP proxy report this partial-path loss to the SIP source endpoint or does it report total loss reported from the final destination back to the source? Some of the evidence I’ve seen suggests it’s reporting partial-path loss, but I need some confirmation.
I am using SBC in the network and call is interworking (RTP-SRTP). Sender from RTP is sending RTP packets on odd port. Is it acceptable? SBC is receiving the packets and validating only index in the header, encrypting the packet and forwarding from SBC’s odd port to destination port. Is it allowed behaviour?
RFC 3605 recommends that RTP is on an even port and the associated RTCP is on the next higher odd port. It doesn’t say that it must be on an even port, so yes, it is allowed behavior.
Thank you Andrew for your quick response.
Hi Andrew,
My question is related to MSRP protocol. Let us say that if the MSRP call is going on and if the end user wants to send re-invite with different MSRP session id, does it allowed? or is it rejected by SIP processing with an error message?
I have no idea.