Subject: [xrblock] Fwd: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets

From: Dan Romascanu <[email-masked]>
Date: Fri, 20 Jan 2017 20:54:42 -0800

To the attention of the XRBLOCK participants - if interested, comment
please on the RTCWEB mail list.

Regards,

Dan

---------- Forwarded message ----------
From: Bernard Aboba <[email-masked]>
Date: Fri, Jan 20, 2017 at 4:21 PM
Subject: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets
To: "[email-masked]" <[email-masked]>

It has been pointed out to me that the text in JSEP Appendix B does not
include text relating to the routing of RTCP XR packets, described in RFC
3611.

Since RTCP XR packets include report blocks with different formats coming
up with appropriate text is challenging.

For example, the following text covers Loss RLE Report Blocks (Section
4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times
Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section 4.6)
and VoIP Metric Report Blocks (Section 4.7):

   If the packet is of type XR with a BT of 1 (Loss RLE Report Block), 2
(Duplicate RLE Report
   Block),  3 (Packet Receipt Times Report Block), 6 (Statistics Summary
Report Block),
  7 (VoIP Metric Report Block), for each report block in the packet whose
"SSRC of source"
   is found in the outgoing SSRC table, deliver a copy of the RTCP packet
to the
   "m=" line associated with that SSRC.

However, RFC 3611 also includes the Receiver Reference Report Block
(Section 4.4) whose format looks like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=4      |   reserved    |       block length = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should this be forwarded to the RtpSender whose outgoing SSRC table that
matches the
"SSRC" field in the RTCP XR packet?

There is also is the DLRR Report Block (Section 4.5) whose format looks
like this:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=5      |   reserved    |         block length          |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                 SSRC_1 (SSRC of first receiver)               | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 |                         last RR (LRR)                         |   1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   delay since last RR (DLRR)                  |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                 SSRC_2 (SSRC of second receiver)              | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 :                               ...                             :   2
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

For this one, I'm assuming that the SSRC of Nth receiver field is matched
against the
ssrc_table to determine the appropriate RtpReceivers to receive a copy of
the RTCP packet.

There are of course other RTCP XR RFCs.  I have not reviewed those yet.
But before doing that, I'd like to get some feedback on whether the general
approach outlined above is sane (or whether parsing individual RTCP XR
report blocks is a bad idea to begin with).

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb