Re: Issue 180: RTCP packet routing

It has been pointed out that RTCP packets may contain chunks/blocks that relate to different objects, and therefore that information from a single RTCP packet may be routed to several objects.  
Here is a proposed rewrite of Section 8.3.2 in order to take this into account:

8.3.2 RTCP matching rules

RTCP matching rules determine how information from RTCP Sender Reports (SRs), Receiver Reports (RRs), SDES, BYE and Feedback Messages are delivered to RTCRtpReceiver and RTCRtpSender objects. 

The SR packet format, defined in [RFC3550] Section 6.4.1 provides an "SSRC of sender" field in the RTCP header, as well as "SSRC of source" fields within individual report blocks, with the number of report blocks denoted in the reception report count (RC) field. When an SR packet is received, block.ssrc is set to the "SSRC of source" field, and the receiver routing algorithm below is used to route information in the "sender info" block to the appropriate RTCRtpReceiver object. If one or more report blocks are present in the SR, the "SSRC of source" field within each report block is used as the value of block.ssrc to route information from each report block to the appropriate RTCRtpSender object, according to the sender routing algorithm described in Section 8.3.2.2 below. 

The RR packet format, defined in [RFC3550] Section 6.4.2 provides an "SSRC of packet sender" field, as well as "SSRC of source" fields within individual report blocks, with the number of report blocks denoted in the reception report count (RC) field. If one or more report blocks are present in the RR, the "SSRC of source" field within each report block is used as the value of block.ssrc to route information from each report block to the appropriate RTCRtpSender object, according to the sender routing algorithm described in Section 8.3.2.1 below. 

The SDES packet format, defined in [RFC3550] Section 6.5 provides an "SSRC/CSRC" field within each chunk with the number of chunks denoted in the source count (SC) field. When an SDES packet is received, the SSRC/CSRC fields within each chunk are used as the value of block.ssrc to route information from each chunk to the appropriate RTCRtpReceiver object, according to the receiver routing algorithm in Section 8.3.2.1. 

The BYE packet format, defined in [RFC3550] Section 6.6 allows for as many "SSRC/CSRC" fields as indicated in the SC field. When a BYE packet is received, the SSRC/CSRC fields are used as the block.ssrc to route information to the appropriate RTCRtpReceiver object, according to the receiver routing algorithm in Section 8.3.2.1. 

The RTCP Feedback Message packet format, defined in [RFC4585] Section 6.1, provides for an "SSRC of packet sender" field as well as an "SSRC of media source" field. When a Feedback Message is received, the "SSRC of media source" field is used as the value of block.ssrc to route information from the feedback message to the appropriate RTCRtpSender object, according to the sender routing algorithm in Section 8.3.2.2. 


8.3.2.1 Receiver routing algorithm

If rtcp_receiver == ssrc_table[block.ssrc] is set, the block is delivered to rtcp_receiver. If it is unset, the block is queued for 30 seconds, and ssrc_table[block.ssrc] is checked every time a new ssrc_table[] entry is added, in case reception of an RTP packet resulted in an addition to ssrc_table[]. If when the timer expires ssrc_table[block.ssrc] is still unset, the block is discarded. 


8.3.2.2 Sender routing algorithm

The value of block.ssrc is checked against the values of parameter.codecs[j].parameters.ssrc (for j = 0 to the number of codecs) provided in calls to sender.send(parameters). If a match is found, the information in the block is delivered to sender. If no match is found, the block is discarded.

Received on Tuesday, 24 February 2015 20:05:57 UTC