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

Dan Romascanu <dromasca@gmail.com> Sat, 21 January 2017 04:54 UTC

Return-Path: <dromasca@gmail.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8715312987C for <xrblock@ietfa.amsl.com>; Fri, 20 Jan 2017 20:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-3Y-GbILUG5 for <xrblock@ietfa.amsl.com>; Fri, 20 Jan 2017 20:54:44 -0800 (PST)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FF812987B for <xrblock@ietf.org>; Fri, 20 Jan 2017 20:54:43 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id u25so31191050qki.2 for <xrblock@ietf.org>; Fri, 20 Jan 2017 20:54:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3/tUk1+2nbF9FAm1srpdJicWow+Y4+AqHWWANmP4yDY=; b=stiySmsg3BTwjUR9gMRjCHAcSuf35xOwqqGloc9nWyqoIun+RC1xGvHE3tWfT1s0p/ euhILY/w/YM3h+H/q/LoGGCId13+1gpedq9NX4HGni0SSOxlNgduf1NdtdVDA3fIwk/+ XYHan2lpbFObLrK9X8ZzsM3EmqDLcND9OCvfRrBnQmkQ0UzHbhYpVgo9y/BDBHkKF2T4 nYarX+G53fisvDK0F6mFYKiAB7SO3+86Tk5XvLIt5sztlGSKvOEoyOASflMcLRnGeAs6 er2EjlefIXSXyR0aJkmJFzRpksnV472FGr6xDQm//ZDqrp31V3HFAd44qG2V0tsV+Igx npbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3/tUk1+2nbF9FAm1srpdJicWow+Y4+AqHWWANmP4yDY=; b=KPoCfiX8xlss0Qrk5AAJ+fcwdHDnupg+N89WelSwUDRUQ9vXZd+m6YOODPrjbgZY8X mwTjhlYbKgG2xvcym05vmZqRj0eC6IIjX59y11ZRRFTzZggqGtw/VOuxpcs468pr0evC anKGRg4o79Mj8phZ8AHaBdcazobDmFQtBH2ARdTXgP2yl7JeyNCk/My1m3djhHoS0owP vNIeOa6OaWhSyrqihJ2MW9fY2nPbmfteiwgm7VE22GA7U9IrFPF98KOrMUkcbtWPK3LP dK7vf/trVx/oDZMCKowqpLvdDCEc717S4kmuD0ceAsV1+YxToBO/zrOr5JkPBdkN/914 8wyw==
X-Gm-Message-State: AIkVDXLv67PBhGl7tcQtpxCz2fqKhnKevi4rQGAsprJfoLKRayQHL+Vxy5b+3XnRkL/ZgeB0U7QW5tNBZPD8rw==
X-Received: by 10.55.6.150 with SMTP id 144mr15049516qkg.46.1484974482793; Fri, 20 Jan 2017 20:54:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.40.11 with HTTP; Fri, 20 Jan 2017 20:54:42 -0800 (PST)
In-Reply-To: <CAOW+2dvONSzPoK_scpKmzTPd0cF0kgS3Ckqt3W+BoiCL0ruVDQ@mail.gmail.com>
References: <CAOW+2dvONSzPoK_scpKmzTPd0cF0kgS3Ckqt3W+BoiCL0ruVDQ@mail.gmail.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Fri, 20 Jan 2017 20:54:42 -0800
Message-ID: <CAFgnS4UrwVXjH3iidVSgxd6UmhuwZ7M5Cxveuby83fxbEmuVSQ@mail.gmail.com>
To: xrblock@ietf.org
Content-Type: multipart/alternative; boundary="001a114d819e8c2b8f05469390bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/AlVSYXLXjJbF7y_KMfA73AVbKGk>
Subject: [xrblock] Fwd: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Jan 2017 04:54:45 -0000

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

Regards,

Dan

---------- Forwarded message ----------
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, Jan 20, 2017 at 4:21 PM
Subject: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets
To: "rtcweb@ietf.org" <rtcweb@ietf.org>


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
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb