RTCP中SR和RR的简介与区别

RTCP(实时传输控制协议)

简介

RTCP是 RTP 的控制协议,它用于监视网络的服务质量,对会话进行带外管理,像流量控制,拥塞控制等。

rfc3550

RTCP中定义了一下五种类型的报文,其中,SR和RR是其中主要的报文类型,用于发送和接受数据源的统计信息

SR: Sender Report RTCP Packet

RR: Receiver Report RTCP Packet

这里只对SR和RR进行详细介绍。

包的内容结合代码的数据结构来看对其理解会更加清晰
因为每次发送的只是一种类型的报文,这边用了联合体来存放这些数据

RTCP头结构

// 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;

SR和RR的区别

从报文内容上看SR比RR多出来了sender info这部分数据段,这部分包含了发送报告方作为发送者相关的信息。

网络上关于报文的定义有很多,关于报文中的细节每个字段说明什么都很清楚,此处不再赘述。但是大多都没有很清楚的说明SR和RR区别
SR表面译为作为发送者报告,RR表面译为接收者报告
实际上按字面上理解容易造成误解,以为SR就是发送端的报告,而RR就是接收端的报告。其实不是这样的。

SR并不是发送者发送多少包告诉对方,而是发送者这端接收了多少包,接收过程中丢了多少包。将这些信息传送给对端。
所以SR包含两个信息,将发送者自己发送的信息告诉对端,同时将自己接收的信息也告诉对端。而RR是当报文发送方只作为接收者,而不发送媒体数据时,发给对端自己作为接收方接收到的数据的统计信息

这一点对理解他们的区别很重要,务必弄清楚。

这是从另一篇文章中提到的相应的内容,可以帮助理解
RTP 报文的接收者可以利用两种类型的 RTCP 报告报文(SR 或 RR)来提供有关数据接收质量的统计信息,具体选用 SR 报文还是 RR 报文要看该接收者是否同时是一个 RTP 报文的发送者,明确地讲,如果一个会话参加者自最后一次 发送 RTCP报文后,发送了新的 RTP 数据报文,那么该参加者需要传送 SR 报文, 否则传送 RR 报文。SR 报文和RR 报文的主要区别在于前者包含了20字节有关发送者的信息

当然你可以问自己一个问题,为什么有SR了还需要RR这个类型呢?如果这个问题能回答上来,你对这个概念就算理解了。
答案很简单,本质区别在于发送RTCP报文的这个家伙只是媒体数据的接收者还是说它既是接收者又是发送者。

实践


SR的抓包

RR的抓包

可以看到SR和RR的区别(sender info)

从以下抓包可以看出,通话方A(192.168.12.139)和B(192.168.12.245)在正常建立通话时,A发出的是SR类型报文,当A按下hold之后,不再发送媒体数据,发出的是RR类型的报文。

丢包率的获取

SR中的RR(Reception report block)里面保存了其接收到的包的个数和丢了多少包,RTCP已经帮我们计算好了相应的数据。
参考Reception report block中的相应定义:
丢失百分比(fraction lost):8个比特,它表示自上一个SR或RR报文发送 后,在数据接收过程中丢失的RTP报文数同所应收到的RTP报文总数的百分比。

包丢失累计数(cumulative number of packet lost):24 个比特,它记录了到该 RTCP 报文发送时,在接收过程中所丢失的 RTP 数据报文的总数。

实践
通过如下抓包可以看出,因为是单路通话,所以做为接收方只有一个Reception report block(SSRC_1),这一路流中,Fraction lost为84/256,表明这个SR与上个SR(或RR)之间其丢失百分比为256个包中丢了84个包,故其丢包率为(84/256)x100 = 32.81,故丢包率为32.81%

而cumulative number of packets lost表明该路流接收过程中总共丢了多少个包,从下面抓包看,截止到该SR为止总共丢了609个包(这个值会一直累加,到后面设置累加到5560)。

猜你喜欢

转载自blog.csdn.net/csdn_zmf/article/details/105575968