RE: Issue 180: RTCP packet routing

Right. The packet is decrypted against the dlls transport at the start.

Then My understanding is that every RTCP packet must be scanned for ALL SSRCs that it contains and the RTCP packet must be routed to all sender/receivers on that dlls transport that mention that SSRC either explicitly (or implicitly, e.g. from latching rules) in the encoding parameters OR the rtcp.ssrc. Further, due to race conditions that can occur prior to latching a good policy would be to keep all RTCP packets queued for 30 seconds and delivered to any later implicitly added senders/receivers where that SSRCs gets mentioned.

-Robin


On March 13, 2015 at 8:59:14 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote:

I think the same problem could occur in the audio only case.  While a simple O/A exchange specifying payload types would be sufficient to route audio RTP packets,  RTCP packets do not include a PT field.  So if no RTP packets had been received yet,  there would be no entries in the ssrc_table[] and therefore if an RTCP SR arrived, it could not be routed to an RtpReceiver based on marching the “SSRC of sender” field against ssrc_table[].  .  For similar reasons, information in RTCP SDES or BYE packets also could not be routed to an RtpReceiver.  The solution suggested in Section 8.3.2 is to queue the SR, SDES or BYE packets and wait up to 30 seconds for an RTP packet to arrive and latch an entry into the ssrc_table[] so that they can be routed.

 

From: Jiannan Zheng
Sent: Wednesday, March 11, 2015 1:20 PM
To: Robin Raymond; public-ortc@w3.org; Bernard Aboba
Subject: 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) 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.