Introduction and differences between SR and RR in RTCP

RTCP (Real-time Transport Control Protocol)

Introduction

RTCP is the control protocol of RTP. It is used to monitor the quality of service of the network and perform out-of-band management of sessions, such as flow control, congestion control, etc.

rfc3550

RTCP defines five types of messages, among which SR and RR are the main message types and are used to send and receive statistical information from data sources.

SR: Sender Report RTCP Packet

RR: Receiver Report RTCP Packet

Only SR and RR are introduced in detail here.

The content of the package will be understood more clearly when combined with the data structure of the code.
Because only one type of message is sent each time, a union is used to store this data.

RTCP header structure

// One RTCP packet
typedef struct {
	RTCP_CM common;     // common header
	union {
		// sender report (SR)
		RTCP_SR sr;
		// reception report (RR)
		struct {
			unsigned int dwSsrc;// receiver generating this report
			RTCP_RR_T     rr[1];  // variable-length list
		} rr;

		// source description (SDES)
		struct rtcp_sdes {
			unsigned int dwSsrc;      // first SSRC/CSRC
			rtcp_sdes_item_t item[1]; // list of SDES items
		} sdes;

		// BYE
		struct {
			unsigned int dwSsrc[1]; // list of sources
			// can't express trailing text for reason
		} bye;
		//FB
		struct {
			unsigned int dwSsrc;
			RTCP_FB fb;
		}fb;
		//Application FeedBack
		struct {
			unsigned int dwSsrc_sender;
			unsigned int dwSsrc_mediasource;
		}appFb;
	}r;
}RTCP_HDR;

// RTCP common header word
typedef struct
{
    unsigned char    bVpc;           /// protocol version, padding flag, count
    unsigned char    bPacketType;    ///
    unsigned short    wLen;           /// pkt len in words, w/o this word
} RTCP_CM;

//SR
typedef struct
{
    unsigned int dwSsrc;           // sender generating this report
    unsigned int dwNtp_sec;        // NTP timestamp    seconds
    unsigned int dwNtp_frac;       //                      fraction
    unsigned int dwRtp_ts;     // RTP timestamp
    unsigned int dwPsent;          // packets sent
    unsigned int dwOsent;          // octets sent
    RTCP_RR_T rr[1];        // variable-length list
} RTCP_SR;

// Reception report block
typedef struct
{
    unsigned int       dwSsrc;             // data source being reported
    unsigned char        bFraction;          // fraction lost since last SR/RR
    unsigned char        bLost[3];           // cumul. no. pkts lost (signed!)
    unsigned int       dwLastSeq;          // extended last seq. no. received
    unsigned int       dwJitter;           // interarrival jitter
    unsigned int       dwLsr;              // last SR packet from this source
    unsigned int       dwDlsr;             // delay since last SR packet
} RTCP_RR_T;

//sdes
typedef struct
{
    rtcp_sdes_type_t bType;                     // type of item (rtcp_sdes_type_t)
    unsigned char bLength;                   // length of item (in octets)
    char data[2];                   // text, not null-terminated [2] for padding
} rtcp_sdes_item_t;

//FB
typedef struct {
	unsigned int	dwSsrc;                 // data source being reported
	RTCP_GENERIC_NACK_FB nack_fb[MAX_RTCP_GENERIC_NACK_FB_MSG];	
} RTCP_FB;
typedef struct {
	unsigned short wLostSeqNo;
	unsigned short wLostBitMask;
} RTCP_GENERIC_NACK_FB;

The difference between SR and RR

Judging from the message content, SR has more sender info data segment than RR. This part contains information related to the sending reporting party as the sender.

There are many definitions of packets on the Internet. The details of each field in the packet are very clear, so I won’t go into details here. However, most of them do not clearly explain the difference between SR and RR.
SR is superficially translated as the sender's report, and RR is superficially translated as the receiver's report.
In fact, it is easy to misunderstand if taken literally, thinking that SR is the report of the sender, and RR is the report of the receiver. Report. This is not the case.

SR does not tell the other party how many packets the sender sent, but how many packets the sender received and how many packets were lost during the reception process. Send this information to the peer.
Therefore, SR contains two pieces of information. It tells the other end the information sent by the sender, and also tells the other end the information it receives. RR is the statistical information of the data received by the peer as the receiver when the message sender only acts as the receiver and does not send media data.

This is important to understand their differences, so be sure to clarify them.

This is the corresponding content mentioned in another article, which can help understand that
the receiver of RTP messages can use two types of RTCP report messages (SR or RR) to provide statistical information about the quality of data reception, specifically The choice of SR message or RR message depends on whether the recipient is also the sender of an RTP message. Specifically, if a session participant has sent a new RTP data message since the last RTCP message was sent, , then the participant needs to transmit the SR message, otherwise it will transmit the RR message. The main difference between SR messages and RR messages is that the former contains 20 bytes of information about the sender

Of course you can ask yourself a question, why do you need the RR type when you have SR? If you can answer this question, you understand the concept.
The answer is simple. The essential difference is whether the guy sending the RTCP message is only the receiver of the media data or it is both the receiver and the sender.

practice

SR packet capture

RR packet capture

You can see the difference between SR and RR (sender info)

As can be seen from the following packet capture, when call parties A (192.168.12.139) and B (192.168.12.245) establish a call normally, A sends an SR type message. When A presses hold, no more media data is sent. , the message sent is an RR type.

Obtaining packet loss rate

The RR (Reception report block) in SR stores the number of packets received and how many packets were lost. RTCP has already calculated the corresponding data for us.
Refer to the corresponding definition in the Reception report block:
Fraction lost: 8 bits, which indicates that the number of RTP messages lost during the data reception process since the last SR or RR message was sent is the same as the number that should have been received. Percentage of the total number of RTP packets.

Cumulative number of packet lost (cumulative number of packet lost): 24 bits, which records the total number of RTP data packets lost during the reception process when the RTCP packet is sent.

In practice
, it can be seen from the following packet capture that because it is a single-channel call, there is only one Reception report block (SSRC_1) as the receiver. In this stream, Fraction lost is 84/256, indicating that this SR is different from the previous SR (or RR), the loss percentage is 84 packets out of 256 packets, so the packet loss rate is (84/256) x100 = 32.81, so the packet loss rate is 32.81%

The cumulative number of packets lost indicates the total number of packets lost during the flow reception process. From the packet capture below, a total of 609 packets have been lost up to the SR (this value will continue to accumulate, and will accumulate to 5560 when set later) ).