RE: Issue 180: RTCP packet routing

I would provide an example by which the needed RTCP packet cannot be routed by the current scheme.

Assume we are in a conference with a mixer and there is a conference announcement bot which runs on ORTC. Because it is a bot, it is send only and no receive. Also the announcement is on-demand and the bot keeps silent at the beginning.

Now the conference begins and we have:
1, None of the RTCP packet has any receiver report coming from the conference mixer, because this bot hasn’t sent anything;
2, There isn’t any RTP packets coming from the mixer because the bot is send only, so no latching can be established;
3, Now mixer sends in an RTCP packet with SR followed by a contributor SDES;

By the current RTCP routing scheme as is, this packet is not routable. By protocol, the sender is required to compare the SSRC in the contributor SDES with self SSRC to do SSRC collision detection, so we need this packets to be routed to the sender.

Of course it is an example and most likely such bot will be audio only (hence there is no routing problem at all). But in real AV scenarios, it is hard to mandate which direction is negotiated and when the RTP is really flowing, we can end up in similar situation.



From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Wednesday, March 11, 2015 12:07 PM
To: public-ortc@w3.org; Bernard Aboba
Subject: Re: Issue 180: RTCP packet routing



Related to a "hint" for the RTCRtcpParamaters.ssrc for RTCRtpSender in this posting:
https://lists.w3.org/Archives/Public/public-ortc/2015Feb/0050.html


The rules for routing packets for RTCP have been illustrated in Bernard's posting:
https://lists.w3.org/Archives/Public/public-ortc/2015Feb/0052.html


None of the packets need the RTCRtpSender's RTCRtcpParamaters.ssrc set in order to route to the correct sender or receiver. Thus I think we should specifically say in the draft that the RTCRtcpParamaters.ssrc for the RTCRtpSender has no meaning (at least at this time). If we discover a RTCP packet that cannot be routed without this being set on the sender we should reconsider.

-Robin


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.