RE: Issue 180: RTCP packet routing

Some issues have been found in the proposed resolution:
https://lists.w3.org/Archives/Public/public-ortc/2015Mar/0013.html


Here is a revised proposal, for insertion in Section 13.4 (Statistics API section).

13.4 RTCP matching rules

Since statistics are retrieved from objects within the ORTC API, and information within RTCP packets is used to maintain some of the statistics, the handling of RTCP packets is important to the operation of the statistics API.

RTCP packets arriving on an RTCDtlsTransport are decrypted and made available in cleartext to all RTCRtpSender and RTCRtpReceiver objects utilizing that transport. RTCRtpSender and RTCRtpReceiver objects then examine the RTCP packets to determine the information relevant to their operation and the statistics maintained by them.

For RTCRtpReceiver objects, the ssrc_table[] described in Section 8.3 can be consulted, as well as the value of parameters.rtcp.ssrc provided in calls to receiver.receiver(parameters). RTCP packets should be queued for 30 seconds and the ssrc_table[] is checked every time a new entry is added, in case reception of an RTP packet resulted in an addition to the table.

SSRC values used by RTCRtpSender objects to match values within RTCP packets include SSRCs chosen by the browser, as well as values of parameters.rtcp.ssrc and parameter.codecs[j].parameters.ssrc (for j = 0 to the number of codecs) provided in calls to sender.send(parameters).

Relevant SSRC fields within selected RTCP packets are summarized within [RFC3550] Section 6.4.1 (Sender Report), Section 6.4.2 (Receiver Report), Section 6.5 (SDES), Section 6.6 (BYE) and [RFC4585] Section 6.1 (Feedback Messages).

On February 24, 2015 at 3:06:35 PM, Bernard Aboba (bernard.aboba@microsoft.com<mailto:bernard.aboba@microsoft.com>) wrote:
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.