RTCP packet routing

[aboba]

[aboba]

From Jiannan Zheng:

Section 8.3 describes matching rules for routing of RTP packets to RtpReceiver objects. There is no equivalent text for RTCP packets. Since RTCP packets do not include the Packet Type of the RTP packets they relate to, nor do they include a muxId, the only way they can be routed is via the SSRC (e.g. the SSRC of the source that a Receiver Report relates to).

[aboba]

Some background:

RFC 3711 Section 3.4: 

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
     |V=2|P|    RC   |   PT=SR or RR   |             length          | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                         SSRC of sender                        | |
   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
   | ~                          sender info                          ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | ~                         report block 1                        ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | ~                         report block 2                        ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | ~                              ...                              ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | |V=2|P|    SC   |  PT=SDES=202  |             length            | |
   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
   | |                          SSRC/CSRC_1                          | |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | ~                           SDES items                          ~ |
   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
   | ~                              ...                              ~ |
   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
   | |E|                         SRTCP index                         | |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
   | ~                     SRTCP MKI (OPTIONAL)                      ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | :                     authentication tag                        : |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                                   |
   +-- Encrypted Portion                    Authenticated Portion -----+


   Figure 2.  An example of the format of a Secure RTCP packet,
   consisting of an underlying RTCP compound packet with a Sender Report
   and SDES packet.

[aboba]

Potential solution:
In the above example, we have a Sender Report which includes the SSRC of Sender. On the receiver, if there is an entry for ssrc_table[sender.ssrc], then the report can be delivered to that receiver. If there is no table entry, then the RTCP SR can be queued for some time period (e.g. 10 seconds) by which time an ssrc_table entry may have been created and the SR can therefore be delivered. Otherwise, the SR can be dropped. A similar issue can occur with an RTCP BYE, which contains the SSRC/CSRC of the source that is becoming inactive.

It does not appear that this issue can occur with Receiver Reports which include the SSRC of the source they are reporting on, and so these can always be delivered to the appropriate RtpSender object based on the SSRC configured by the application or chosen by the browser. Similarly, RFC 4585 Section 6.1 defines the RTCP packet format for feedback messages, which contains the SSRC of the packet sender as well as the SSRC of the media source, allowing it to be delivered to the appropriate RtpSender object.

[aboba]

Here is a proposed resolution:

Add a sub-heading "Section 8.3.1 RTP matching rules" prior to the current text in Section 8.3 on Matching rules.

Add Section 8.3.2:

8.3.2 RTCP matching rules

The RTP matching rules also influence how RTCP Sender Reports (SRs), SDES and BYE packets are delivered to RTCRtpReceiver objects. When an RTCP SR, SDES or BYE packet is received, packet.ssrc is set the "SSRC of sender" field defined in [RFC3550] Section 6.4.1 (Sender Report), or "SSRC/CSRC" field defined in [RFC3550] Section 6.5 (SDES) or [RFC3550] Section 6.6 (BYE). If receiver == ssrc_table[packet.ssrc] is set, the RTCP SR, SDES or BYE packet is delivered to receiver. If it is unset, the RTCP packet is queued for 30 seconds, and ssrc_table[packet.ssrc] is checked again, in case reception of an RTP packet resulted in an addition to ssrc_table[]. If it is still unset, the RTCP SR, SDES or BYE packet is discarded.

When RTCP RR or Feedback Messages are received, the "SSRC of source" field defined in [RFC3550] Section 6.4.2 (Receiver Report) or the "SSRC of media source" field defined in [RFC4585] Section 6.1 (Feedback Messages), is checked against the values of parameters.codecs[j].parameters.ssrc provided in calls to sender.send(parameters) for j=0 to the number of codecs. If a match is found, the RTCP packet is delivered to sender.

Also, the following updated text is proposed in Section 9.5.1 Dictionary RTCRtcpParameters Members:

ssrc of type unsigned long
The SSRC to be used in the "SSRC of packet sender" field defined in [RFC3550] Section 6.4.2 (Receiver Report), as well as in [RFC4585] Section 6.1 (Feedback Messages). If unset, ssrc is chosen by the browser, and the chosen value is not reflected in RTCRtcpParameters.ssrc. If the browser chooses the ssrc it may change it in event of a collision, as described in [RFC3550].

[aboba]

Update to the Section 8.3.2 text:

8.3.2 RTCP matching rules

The RTP matching rules also influence how RTCP Sender Reports (SRs), SDES and BYE packets are delivered to RTCRtpReceiver objects. When these packets are received, sender.ssrc is set to the "SSRC of sender" field defined in [RFC3550] Section 6.4.1 (Sender Report), the "SSRC/CSRC" field defined in [RFC3550] Section 6.5 (SDES) or the "SSRC/CSRC" field defined in [RFC3550] Section 6.6 (BYE). If rtcp_receiver == ssrc_table[sender.ssrc] is set, the RTCP SR, SDES or BYE packet is delivered to rtcp_receiver. If it is unset, the RTCP packet is queued for 30 seconds, and ssrc_table[sender.ssrc] is checked again, in case reception of an RTP packet resulted in an addition to ssrc_table[]. If when the timeout expires ssrc_table[sender.ssrc] is still unset, the RTCP SR, SDES or BYE packet is discarded.

When RTCP RR or Feedback Messages are received, the "SSRC of source" field defined in [RFC3550] Section 6.4.2 (Receiver Report) or the "SSRC of media source" field defined in [RFC4585] Section 6.1 (Feedback Messages), is checked against the values of parameters.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 RTCP packet is delivered to sender.

[aboba]

It has been pointed out that RTCP SR, SDES and BYE packets may contain segments relating to different RtpReceivers, and therefore that the segments need to be routed separately. Here is a rewrite 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 Message packets 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 block.ssrc to route information from each report block to the appropriate RTCRtpSender object, according to the sender routing algorithm described 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 block.ssrc to route information
from each report block to the appropriate RTCRtpSender object, according to the sender routing algorithm described 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 block.ssrc to
route information from each chunk to the appropriate RTCRtpReceiver object, according to the receiver routing algorithm below.

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.

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 block.ssrc to route information from the feedback message to the appropriate RTCRtpSender object, according to the sender routing algorithm below.

Receiver 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.

Sender 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.

[aboba]

Slightly updated version posted to the list here:
http://lists.w3.org/Archives/Public/public-ortc/2015Feb/0052.html

[robin-raymond]

This is related to issue #85

[robin-raymond]

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.

[aboba]

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). Note that 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).

[aboba]

Here is a revised proposal:

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 a notification is sent 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.

RTCP packets should be queued for 30 seconds and all RTCRtpSender and RTCRtpReceiver objects on the related RTCDTlsTransport have access to those packets until the packet is removed from the queue, should the RTCRtpSender or RTCRtpReceiver objects need to examine them.

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), [RFC4585] Section 6.1 (Feedback Messages), and [RFC3611] Section 2 (Extended Reports).