From nobody Mon Feb 1 09:41:12 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999871B3322 for ; Mon, 1 Feb 2016 09:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 NkzOBhIK348o for ; Mon, 1 Feb 2016 09:41:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7755A1B330D for ; Mon, 1 Feb 2016 09:41:10 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u11Hf9cH019618 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Feb 2016 11:41:09 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Stephan Wenger , "avtext@ietf.org" References: <20151130183802.21578.17213.idtracker@ietfa.amsl.com> <565C9C12.80004@nostrum.com> From: Adam Roach Message-ID: <56AF98B4.5090702@nostrum.com> Date: Mon, 1 Feb 2016 11:41:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-roach-avtext-rid-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:41:11 -0000 On 12/10/15 17:01, Stephan Wenger wrote: > 1) The last sentence of section 1, second paragraph, reads: “This need for unique identification extends to Dependent Streams (i.e., simulcast layers used by a layered codec).” > > I’m not sure about the example for Dependent Streams (simulcast layers of a layered codec). The problem here may be terminology, but the term “simulcast” is commonly understood as simultaneous transmission of stuff that is independent from each other. Giving it a new meaning here may be confusing. It may be better to remove the word “simulcast” and simply say “(i.e., layers used by a layered codec conveyed in their own stream)”. Agreed, and I've removed it. > > 2) I would move the first para of section 3 somewhere early into section 1, because otherwise the capitalized term “Dependent Stream” is undefined. I'm having a hard time figuring out how to do this in a way that doesn't flow in a very award fashion. The parenthetical phrase summarizing the meaning of "Dependent Stream" was my attempt to make the introduction comprehensible to people who are not yet familiar with the term, without diving all the way down to formal definitions so early in the document. > > > 3) should “Encoded Stream” and “Dependent Stream” in the abstract be capitalized? > I've capitalized them. /a From nobody Mon Feb 1 10:43:56 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896681B341C for ; Mon, 1 Feb 2016 10:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 g93vZTt6iqUp for ; Mon, 1 Feb 2016 10:43:54 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918021B341D for ; Mon, 1 Feb 2016 10:43:53 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u11IfJai007861 for ; Mon, 1 Feb 2016 13:43:48 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 20qrwb9wcf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 01 Feb 2016 13:43:48 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 1 Feb 2016 12:43:47 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Call for adoption of RID draft Thread-Index: AQHRXSB8D9xuRgdBRkCWLfxsf97I8g== Date: Mon, 1 Feb 2016 18:43:47 +0000 Message-ID: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <07DD4B94F5E86740BC493845D32BA6FC@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-01_07:2016-02-01,2016-02-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602010300 Archived-At: Subject: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 18:43:54 -0000 SGVsbG8sIEFWVEVYVCDigJQNCg0KQXMgZGlzY3Vzc2VkIGluIFlva29oYW1hLCBBZGFtIFJvYWNo IGV0IGFsIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb24gYSDigJxSSUTigJ0gU0RFUyBpdGVtIGFu ZCBoZWFkZXIgZXh0ZW5zaW9uIGZvciBpZGVudGlmeWluZyBlbmNvZGVkIGFuZCBkZXBlbmRlbnQg c3RyZWFtcy4NCg0KVGhpcyBpcyBhIGNhbGwgdG8gc2VlIHdoZXRoZXIgdGhlIEFWVEVYVCB3b3Jr aW5nIGdyb3VwIHdhbnRzIHRvIHRha2Ugb24gdGhpcyB3b3JrIGFzIGEgd29yayBpdGVtIChib3Ro IGFkZGluZyBhIG1pbGVzdG9uZSBmb3IgdGhlIHdvcmsgYW5kIGFkb3B0aW5nIHRoZSBleGlzdGlu ZyBkcmFmdCBhcyB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yIGEgd29ya2luZyBncm91cCBkb2N1bWVu dCkuDQoNClBsZWFzZSBjb21tZW50IG9uIHRoZSBBVlRFWFQgbWFpbGluZyBsaXN0IGluIHRoZSBu ZXh0IHR3byB3ZWVrcyAoYnkgRmVicnVhcnkgMTUsIDIwMTYpLg0KDQpUaGFuayB5b3UhDQoNCkpv bmF0aGFuDQoNCg== From nobody Mon Feb 1 13:56:29 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8D11B3786 for ; Mon, 1 Feb 2016 13:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 IxZAXgRmNXLd for ; Mon, 1 Feb 2016 13:56:27 -0800 (PST) Received: from smtp67.iad3a.emailsrvr.com (smtp67.iad3a.emailsrvr.com [173.203.187.67]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11AB1B3783 for ; Mon, 1 Feb 2016 13:56:27 -0800 (PST) Received: from smtp17.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C739418051E; Mon, 1 Feb 2016 16:56:26 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 775EE180521; Mon, 1 Feb 2016 16:56:26 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from foo.ca (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 01 Feb 2016 16:56:26 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> Date: Mon, 1 Feb 2016 14:56:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 21:56:29 -0000 Yes, I strongly support adopting this draft and adding the WG milestone. = It is need to break a lot of log jams, has been extensively discussed in = various incarnations. Cullen > On Feb 1, 2016, at 11:43 AM, Jonathan Lennox = wrote: >=20 > Hello, AVTEXT =E2=80=94 >=20 > As discussed in Yokohama, Adam Roach et al have submitted a draft on a = =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and dependent streams. >=20 > This is a call to see whether the AVTEXT working group wants to take = on this work as a work item (both adding a milestone for the work and = adopting the existing draft as the starting point for a working group = document). >=20 > Please comment on the AVTEXT mailing list in the next two weeks (by = February 15, 2016). >=20 > Thank you! >=20 > Jonathan >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Feb 1 19:41:16 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631C11ACD1D for ; Mon, 1 Feb 2016 19:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 vHmipCcYWiM1 for ; Mon, 1 Feb 2016 19:40:39 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9D3E21ACDC6 for ; Mon, 1 Feb 2016 19:38:20 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id g73so3502853ioe.3 for ; Mon, 01 Feb 2016 19:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n84Lf+CpQsMNn9dqaubgRThojBni+7csd125+dlNGYA=; b=l7VU0opUqJpK8m2oEEMjpyXyX6KnKd7NaCPzHnE1XcrvU7f7IbRhrOjRAvDUZM1vhB jggjXIpQgiTgeWhY3sGpfzwMVCUw1k1HwxdNLrkrQZ9n4pzOchb0c4EEGPodxPgBxxd9 Bll0QNVAQvPj8eewAXN3LtX53Y56Qj6ZxVpOxsiS4KTPaTaaF4QWzohc6bl63AGMl1VX aYY1qEDWr+v1Z5V+CZz3mwB/Rl7mJteFqcWwm9rJjKqP5k/rfdDxnOKPMwhN+uQJsbgE 2moWrqlMg3Y1OE+U4HLAtFizjhc9TWc4YTCCoDgkkr7jJz9O0bPhSOs/64sFuHn7yRO9 F6sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=n84Lf+CpQsMNn9dqaubgRThojBni+7csd125+dlNGYA=; b=QDO6dVKZ7wu3hbkYX4amSocu3cCoFER8QbI+V5hHCkTQSvmwLIlYIAXaMtL926HXOo zPCfeIW4P9aKGXIoo/96xK6hIdaIJ4TlXDDI3qMp4wNzBjpCdFlzXSkH0DaRDbg/Yy5q MOd+iC1GbocqWqdR1XKfJOYsVqTXJ1G+m46ZyRxDL8mM1Wp7X0Jinn3uGzuaQXBqXVCt BQBZX6h2snIxbAQSKsnIxIqKkr1QSVzc2/edySksPXlDUgLUIl8G+zfxOYdMTkSNP6Ak p9ZbEarGMCOqjmFzXZGhVEYy5I83jwVBIRsV79KQKP2m2rctDKudx8na2vrfTRB5j+n3 jmgQ== X-Gm-Message-State: AG10YOQzhz63PScHcujUMbqSGw93wDtmuzPXxBuSeItgvZI3o1NbEly1spnYlV/GJ3Kb3b9Q3LR7JA0ioymTiQ== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr9468553ioq.100.1454384299898; Mon, 01 Feb 2016 19:38:19 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 1 Feb 2016 19:38:19 -0800 (PST) Date: Tue, 2 Feb 2016 14:38:19 +1100 Message-ID: From: Martin Thomson To: avtext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [avtext] RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 03:40:41 -0000 Well, I hope that no one objects to adopting this. It would be a severe case of institutional confusion if this call Jonathan started were not merely a formality. I wonder what MMUSIC and RTCWEB would do if this were suddenly rejected :) I've read draft-roach-avtext-rid-01. It's pretty straightforward stuff. It makes me wonder why it's taken so long to reach the point where we realized that an identifier for this thing was needed. It looks pretty well ready to ship even. I encourage the chairs to follow the current call with a WGLC. From nobody Tue Feb 2 00:59:43 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7FB1AC444 for ; Tue, 2 Feb 2016 00:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 Gq-PK_B_Urou for ; Tue, 2 Feb 2016 00:59:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4CF1AC438 for ; Tue, 2 Feb 2016 00:59:39 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-e8-56b06ff8c618 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.E2.05690.9FF60B65; Tue, 2 Feb 2016 09:59:37 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.156]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Tue, 2 Feb 2016 09:59:35 +0100 From: Bo Burman To: Jonathan Lennox Thread-Topic: [avtext] Call for adoption of RID draft Thread-Index: AQHRXSB8D9xuRgdBRkCWLfxsf97I8p8Xq8WAgADJ6DA= Date: Tue, 2 Feb 2016 08:59:34 +0000 Message-ID: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdQ/dn/oYwg5MneS0+3rvBarF/8Xlm ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJXR/+QCe0EXf8WfWTUNjDf4uhg5OSQETCS+ LtrMBmGLSVy4tx7I5uIQEjjMKDFv20QoZzGjxJIjq8Cq2AQ0JObvuMsIYosA2ReffQCLMwuo SxzetwQsLgw0denuDywQNaYSaxbPZYKwrSQ+fVrCDGKzCKhI/D/WxtrFyMHBK+Ar8eiVPkhY SCBH4u2R2WDlnEDlC9sXgI1hFJCVuP/9HgvEKnGJW0/mM0EcLSCxZM95ZghbVOLl43+sELai xNXpy5lAxjMLaEqs36UP0aooMaX7ITuIzSsgKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYx ihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbOwS2/dXcwrn7teIhRgINRiYe34PH6MCHWxLLi ytxDjBIczEoivPvTN4QJ8aYkVlalFuXHF5XmpBYfYpTmYFES513jDFQtkJ5YkpqdmlqQWgST ZeLglGpg1AqJOHzwd+tnYUbuhCc75cuqbt2/8Wz+72rvw14sh7ae2DphA88F4aZ4zqtN+q15 QbHVp3eyPfV7OC27QPLO7r8CgoH57dNv1qT/5uTdfE3Y5NeqU/Xi07hbb6uszGjhmHmpq+jw /SUss9xlLXqW3+XslHpqbZC8xraQd9XTF8Zx1es0Qt89U2Ipzkg01GIuKk4EAEqKz0KYAgAA Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:59:41 -0000 KzENCi9CbyBCDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXZ0ZXh0 IFttYWlsdG86YXZ0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDdWxsZW4gSmVu bmluZ3MNCj4gU2VudDogZGVuIDEgZmVicnVhcmkgMjAxNiAyMjo1Ng0KPiBUbzogSm9uYXRoYW4g TGVubm94DQo+IENjOiBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthdnRleHRdIENh bGwgZm9yIGFkb3B0aW9uIG9mIFJJRCBkcmFmdA0KPiANCj4gDQo+IFllcywgSSBzdHJvbmdseSBz dXBwb3J0IGFkb3B0aW5nIHRoaXMgZHJhZnQgYW5kIGFkZGluZyB0aGUgV0cgbWlsZXN0b25lLiBJ dCBpcyBuZWVkIHRvIGJyZWFrIGEgbG90IG9mIGxvZyBqYW1zLCBoYXMgYmVlbg0KPiBleHRlbnNp dmVseSBkaXNjdXNzZWQgaW4gdmFyaW91cyBpbmNhcm5hdGlvbnMuDQo+IA0KPiBDdWxsZW4NCj4g DQo+IA0KPiA+IE9uIEZlYiAxLCAyMDE2LCBhdCAxMTo0MyBBTSwgSm9uYXRoYW4gTGVubm94IDxq b25hdGhhbkB2aWR5by5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGVsbG8sIEFWVEVYVCDigJQNCj4g Pg0KPiA+IEFzIGRpc2N1c3NlZCBpbiBZb2tvaGFtYSwgQWRhbSBSb2FjaCBldCBhbCBoYXZlIHN1 Ym1pdHRlZCBhIGRyYWZ0IG9uIGEg4oCcUklE4oCdIFNERVMgaXRlbSBhbmQgaGVhZGVyIGV4dGVu c2lvbiBmb3INCj4gaWRlbnRpZnlpbmcgZW5jb2RlZCBhbmQgZGVwZW5kZW50IHN0cmVhbXMuDQo+ ID4NCj4gPiBUaGlzIGlzIGEgY2FsbCB0byBzZWUgd2hldGhlciB0aGUgQVZURVhUIHdvcmtpbmcg Z3JvdXAgd2FudHMgdG8gdGFrZSBvbiB0aGlzIHdvcmsgYXMgYSB3b3JrIGl0ZW0gKGJvdGggYWRk aW5nIGENCj4gbWlsZXN0b25lIGZvciB0aGUgd29yayBhbmQgYWRvcHRpbmcgdGhlIGV4aXN0aW5n IGRyYWZ0IGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3IgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 KS4NCj4gPg0KPiA+IFBsZWFzZSBjb21tZW50IG9uIHRoZSBBVlRFWFQgbWFpbGluZyBsaXN0IGlu IHRoZSBuZXh0IHR3byB3ZWVrcyAoYnkgRmVicnVhcnkgMTUsIDIwMTYpLg0KPiA+DQo+ID4gVGhh bmsgeW91IQ0KPiA+DQo+ID4gSm9uYXRoYW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gYXZ0ZXh0IG1haWxpbmcgbGlzdA0KPiA+ IGF2dGV4dEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXZ0ZXh0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBhdnRleHQgbWFpbGluZyBsaXN0DQo+IGF2dGV4dEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dGV4dA0K From nobody Tue Feb 2 01:01:04 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20201A8A3F for ; Tue, 2 Feb 2016 01:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 fXaldzp1tFea for ; Tue, 2 Feb 2016 01:01:00 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503121A8915 for ; Tue, 2 Feb 2016 01:01:00 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-75-56b0704a00fd Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.DF.05041.A4070B65; Tue, 2 Feb 2016 10:00:58 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.248.2; Tue, 2 Feb 2016 10:00:58 +0100 To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> From: Magnus Westerlund Message-ID: <56B07048.7020702@ericsson.com> Date: Tue, 2 Feb 2016 10:00:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7nK5XwYYwg1871Sw+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGuzuAo6uSru3XzP2MA4jaOLkZNDQsBEoqn9EwuELSZx4d56 ti5GLg4hgcOMEn+nTYZyljFKnJ9zhQmkShio48WGaWwgtoiAqMT13efYQWwhARuJfT/mM4LY bAIWEjd/NILV8ApoS2x68Q6shkVAReJX7zpWEFtUIEbiYucRJogaQYmTM5+AXcEpYCvR1bsH LM4MNGfm/POMELa8RPPW2cwQu7QlGpo6WCcwCsxC0j4LScssJC0LGJlXMYoWpxYX56YbGeml FmUmFxfn5+nlpZZsYgSG4MEtv612MB587niIUYCDUYmH12D1+jAh1sSy4srcQ4wSHMxKIrz7 0zeECfGmJFZWpRblxxeV5qQWH2KU5mBREudd4wxULZCeWJKanZpakFoEk2Xi4JRqYCxINu64 dlHo9pRAhbUWN/PPr3I6t/jJrkr5O7YnJF7o9pdbKb9N5Q6pWx41xeFAhN+iiIKDq/9Ob8ib yfDCpMj7jpyh8PYjep+f+LIpN0Q9Tj80WatK8svFJwud74Z+OW75dwErj8Gp8mWXHlY/tQjR US2rWranJrf7Q/X1siCb0yK/nh1NEFRiKc5INNRiLipOBAAkysViPQIAAA== Archived-At: Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:01:03 -0000 Hi, Yes, I support adopting this. Magnus Westerlund Den 2016-02-01 kl. 19:43, skrev Jonathan Lennox: > Hello, AVTEXT — > > As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for identifying encoded and dependent streams. > > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016). > > Thank you! > > Jonathan > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 2 09:49:28 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE9E1B2DFA for ; Tue, 2 Feb 2016 09:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 CKxRt4nlePhS for ; Tue, 2 Feb 2016 09:49:24 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26F21B2DF9 for ; Tue, 2 Feb 2016 09:49:24 -0800 (PST) Received: from [82.132.238.118] (port=48986 helo=[172.20.10.3]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aQf4s-0001D2-6q; Tue, 02 Feb 2016 17:49:23 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> Date: Tue, 2 Feb 2016 17:49:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:49:26 -0000 > On 1 Feb 2016, at 18:43, Jonathan Lennox wrote: >=20 > Hello, AVTEXT =E2=80=94 >=20 > As discussed in Yokohama, Adam Roach et al have submitted a draft on a = =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and dependent streams. >=20 > This is a call to see whether the AVTEXT working group wants to take = on this work as a work item (both adding a milestone for the work and = adopting the existing draft as the starting point for a working group = document). >=20 > Please comment on the AVTEXT mailing list in the next two weeks (by = February 15, 2016). I don=E2=80=99t object to adopting this draft as a working group item. However, I do think the working group should carefully review the = semantics of the RID before this is published as an RFC. The complaint = in the Introduction that none of the previous attempts to address this = problem =E2=80=9Chave the proper ordinality to refer to an individual = stream; all such identifiers can appear in more than one stream at a = time=E2=80=9D doesn=E2=80=99t align with the later requirements that = main and redundancy RTP streams have the same RID.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Feb 2 10:32:16 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2970E1B2EDE for ; Tue, 2 Feb 2016 10:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Sl3HPMywgQZL for ; Tue, 2 Feb 2016 10:32:12 -0800 (PST) Received: from BLU004-OMC2S29.hotmail.com (blu004-omc2s29.hotmail.com [65.55.111.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C58A1B2ECD for ; Tue, 2 Feb 2016 10:32:12 -0800 (PST) Received: from BLU181-W67 ([65.55.111.73]) by BLU004-OMC2S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 2 Feb 2016 10:32:12 -0800 X-TMN: [ZiADT/NLpCmCSI75kPD+2uXZp+xZghE5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9d46f9b1-bd00-43b5-b0b5-74367fa0379c_" From: Bernard Aboba To: Colin Perkins , Jonathan Lennox Date: Tue, 2 Feb 2016 10:32:11 -0800 Importance: Normal In-Reply-To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2016 18:32:12.0051 (UTC) FILETIME=[081F2630:01D15DE8] Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:32:16 -0000 --_9d46f9b1-bd00-43b5-b0b5-74367fa0379c_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jonathan said:=20 > Hello=2C AVTEXT =97 > =20 > As discussed in Yokohama=2C Adam Roach et al have submitted a draft on a = =93RID=94 SDES item and header extension for identifying encoded and depend= ent streams. > =20 > This is a call to see whether the AVTEXT working group wants to take on = this work as a work item (both adding a milestone for the work and adopting= the existing draft as the starting point for a working group document). >=20 > >Please comment on the AVTEXT mailing list in the next two weeks (by Febr= uary 15=2C 2016). [BA] I am in favor of adopting this draft as a working group item.=20 Colin said:=20 >=20 > I do think the working group should carefully review the semantics of the= RID before this is published as an RFC.=20 [BA] It is generally considered good practice for Working Groups to careful= ly review documents before they publish them. I would expect no less from = this highly esteemed group :) >The complaint in the Introduction that none of the previous attempts to ad= dress this problem =93have the proper ordinality to refer to an individual = stream=3B all such identifiers can appear in more than one stream at a time= =94 doesn=92t align with the later requirements that main and redundancy RT= P streams have the same RID.=20 [BA] Yes=2C I noticed that as well. This statement isn't correct=2C because= SSRC multiplexing is widely implemented and interoperates at the RTP level= (there are SDP issues=2C but that's for the MMUSIC draft). Of course ther= e are benefits for the use of RIDs beyond what is provided by SSRC multiple= xing (e.g. an ability to decode incoming RTP packets prior to arrival of th= e Answer). =20 = --_9d46f9b1-bd00-43b5-b0b5-74367fa0379c_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Jonathan said: =3B
&= gt=3B Hello=2C AVTEXT =97
>=3B  =3B
>=3B As discussed in Yoko= hama=2C Adam Roach et al have submitted a draft on a =93RID=94 SDES item an= d header extension for identifying encoded and dependent streams.
>=3B=  =3B
>=3B  =3BThis is a call to see whether the AVTEXT workin= g group wants to take on this work as a work item (both adding a milestone = for the work and adopting the existing draft as the starting point for a wo= rking group document).
>=3B =3B
>=3B >=3BPlease comment on = the AVTEXT mailing list in the next two weeks (by February 15=2C 2016).

[BA] I am in favor of adopting this draft as a workin= g group item. =3B

Colin said: =3B
>= =3B
>=3B I do think the working group should carefully review the sem= antics of the RID before this is published as an RFC. =3B
[BA] It is generally considered good practice for Working Group= s to carefully review documents before they publish them.  =3BI would e= xpect no less from this highly esteemed group :)

&= gt=3BThe complaint in the Introduction that none of the previous attempts t= o address this problem =93have the proper ordinality to refer to an individ= ual stream=3B all such identifiers can appear in more than one stream at a = time=94 doesn=92t align with the later requirements that main and redundanc= y RTP streams have the same RID.

[BA] Yes=2C I noticed t= hat as well. This statement isn't correct=2C because SSRC multiplexing is w= idely implemented and interoperates at the RTP level (there are SDP issues= =2C but that's for the MMUSIC draft).  =3BOf course there are benefits = for the use of RIDs beyond what is provided by SSRC multiplexing (e.g. an a= bility to decode incoming RTP packets prior to arrival of the Answer). &nbs= p=3B

= --_9d46f9b1-bd00-43b5-b0b5-74367fa0379c_-- From nobody Tue Feb 2 10:36:44 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D051B2EFC for ; Tue, 2 Feb 2016 10:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 vj5qGJUVZc4g for ; Tue, 2 Feb 2016 10:36:40 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 6D2F61B2EFA for ; Tue, 2 Feb 2016 10:36:40 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id ba1so158208526obb.3 for ; Tue, 02 Feb 2016 10:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1Ui9y4RiQob421PnZgbQGZD4XtI5N0rowQ51anV1wIM=; b=ozD90hjjQOl3rFCQ8lx1OhRQc6hqD9h7nXzBa7PMPhNgC4u8n+1JtNA9ro/IEd+x/X WoiPeqQzHh8aCTFID0ENhJe0xD5OAu1LWmHVE/gfJhmawQpYP72ECgLQij7K2O1yrRf6 HcPBvaF4X7M3aH8mjsUlbvmrWnUSE9PBKqjVgB/S+j0BkQlOJMo4VyYbUWOnjFmwxXaG HAT0LcWnqHbPyROlJ+jLNwQCPgu97PNAp4Q72bXW5gnOzLTBjX/E1T3IHtbhx7n7F2pO 2zvsc3NOneELwznQT3nRA0F1YYeg22WhIKpd2ijQyY7MsnS9B2rfMJ1uqlkCUCDV8E+t XLRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1Ui9y4RiQob421PnZgbQGZD4XtI5N0rowQ51anV1wIM=; b=Enguz3pa/rH9Jinjn5L/zkhhZXVuL+ii+VIxprWM96EEB0Dtvmc5JY9atvFZPGp4xh dFkqVanWqTPFogs+c3vdj97enFS/0Ss2SG0YrlcihGvQagVeS/upymraMhiaQUNPFR27 Pk2eTxdalhg0Um+80HqpwUla6UcFSf7jRyp/B60ZGAqHkdtbV6gS2gnzIDasLE0GUhQM J50pEWxd2JJlrRGR3mHr+yN974X6ZLK/ldq9KTBjDPGd+slhH4DP175fpl81gU/pD45z rzw+QmZdVEgsDdiBxmfN5oZvOdgn6Qtt4RCjJ19JxaVAkOwWz8VU6TcO4aVc+3hPncHl 6woA== X-Gm-Message-State: AG10YORM8J56GzocV3t/ZUk2/IG8GJYlAnYiscgwiyWPZs/m9gDI09PukcLmIO4FHdNIYflhAyUnbqpFi3/Y1cAM X-Received: by 10.60.43.40 with SMTP id t8mr15602678oel.33.1454438198933; Tue, 02 Feb 2016 10:36:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Tue, 2 Feb 2016 10:35:59 -0800 (PST) In-Reply-To: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> From: Peter Thatcher Date: Tue, 2 Feb 2016 10:35:59 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11c35df6324321052acdc8dc Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:36:41 -0000 --001a11c35df6324321052acdc8dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adopting the draft. On Mon, Feb 1, 2016 at 10:43 AM, Jonathan Lennox wrote= : > Hello, AVTEXT =E2=80=94 > > As discussed in Yokohama, Adam Roach et al have submitted a draft on a > =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying enco= ded and dependent > streams. > > This is a call to see whether the AVTEXT working group wants to take on > this work as a work item (both adding a milestone for the work and adopti= ng > the existing draft as the starting point for a working group document). > > Please comment on the AVTEXT mailing list in the next two weeks (by > February 15, 2016). > > Thank you! > > Jonathan > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --001a11c35df6324321052acdc8dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adopting the draft.

On Mon, Feb 1, 2016 at 10:43 AM, Jona= than Lennox <jonathan@vidyo.com> wrote:
Hello, AVTEXT =E2=80=94

As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2= =80=9CRID=E2=80=9D SDES item and header extension for identifying encoded a= nd dependent streams.

This is a call to see whether the AVTEXT working group wants to take on thi= s work as a work item (both adding a milestone for the work and adopting th= e existing draft as the starting point for a working group document).

Please comment on the AVTEXT mailing list in the next two weeks (by Februar= y 15, 2016).

Thank you!

Jonathan

_______________________________________________
avtext mailing list
avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext

--001a11c35df6324321052acdc8dc-- From nobody Tue Feb 2 10:46:17 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081731B2F2D for ; Tue, 2 Feb 2016 10:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 kU7LRZxAvzpz for ; Tue, 2 Feb 2016 10:46:14 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 8B4901B2EE8 for ; Tue, 2 Feb 2016 10:46:08 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id is5so158281427obc.0 for ; Tue, 02 Feb 2016 10:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MY/lj8x8bTD9xAvMWjczBO7gXyu02Q9nhkCBRY4OzIk=; b=Uv29nei2TmJbcvb0BR7J26tbpsq0va/52dz+XR35/9G8iNJbDdFFfVdicK0CWYZLpQ wiVP/nA4O2zfmoUUmyzVi7z68EmPliPgRIgMBnHiP4oamrcvB/+7VOYeth4gBAiwdw6M 7q4eWbVBrUXGNc6yt2hmzTh5jIRXNlu4KRhH+lNGCMH+mwbJR9O78fK2WIy1R8o5BDJk GiMuaobp/Xjlv64SIlrYU3PEZdseWTGJtP0EaxoXpQFu05QdLSIROEdnCuMuvd2GQ6nV +zJVsXVpnCPjn1o/YEK6oV0cXf7Y+Zx1uxl7tRkVXdmfqYny/D8IkoHT8MhYmIZwJdG+ 5cdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MY/lj8x8bTD9xAvMWjczBO7gXyu02Q9nhkCBRY4OzIk=; b=ec8keUtlOkDAFn9t7cb28xDmO+qkGy7ip3ansTM36A/XZcRtamPqU6DXaQjJj58c6G AAqUorKbLoboAOJ7LvCwniIwN7nyyBSBiENGyH908FcwyGFQRs06+DsyMpEi4puBCc9I SKaf8DEZ7F8z50cGm1hUiEZVVdBByL+RaPTQDh0SfKpUr/Bm4sQF+kxSxdMuKhOavsi6 MAwCvz5u0VWMMTuBHmflfHzlnjcAhRz/3P5Zf+EqduvtzZLV9UVWNHT9oZr6CcqZoTQD mHciJdirOIa6TWlOpsNhDvrlFzpGyLhH8KLaOdAoiXJ/GW//FgDe0yW4bAiz8Ylkalil gMGw== X-Gm-Message-State: AG10YOQWCmbqIOCMHftIbkrqBw8zf2/soqZPtMl6oqNcLf8wEVcjDpDNcDg3MINZRWIQEjXXddD8GYBCTwiR+/iK X-Received: by 10.60.43.40 with SMTP id t8mr15657603oel.33.1454438766709; Tue, 02 Feb 2016 10:46:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Tue, 2 Feb 2016 10:45:27 -0800 (PST) In-Reply-To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> From: Peter Thatcher Date: Tue, 2 Feb 2016 10:45:27 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11c35df609d035052acdea75 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:46:16 -0000 --001a11c35df609d035052acdea75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins wrote: > > On 1 Feb 2016, at 18:43, Jonathan Lennox wrote: > > > > Hello, AVTEXT =E2=80=94 > > > > As discussed in Yokohama, Adam Roach et al have submitted a draft on a > =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying enco= ded and dependent > streams. > > > > This is a call to see whether the AVTEXT working group wants to take on > this work as a work item (both adding a milestone for the work and adopti= ng > the existing draft as the starting point for a working group document). > > > > Please comment on the AVTEXT mailing list in the next two weeks (by > February 15, 2016). > > I don=E2=80=99t object to adopting this draft as a working group item. > > However, I do think the working group should carefully review the > semantics of the RID before this is published as an RFC. The complaint in > the Introduction that none of the previous attempts to address this probl= em > =E2=80=9Chave the proper ordinality to refer to an individual stream; all= such > identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align > with the later requirements that main and redundancy RTP streams have the > same RID. > > =E2=80=8BPerhaps the introduction could be more precise by saying "have the= proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B =E2=80=8B =E2=80=8BThe redundancy RTP streams have the same RID as the sou= rce RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it). It doesn't matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream. > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --001a11c35df609d035052acdea75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.= org> wrote:
> On 1= Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
> Hello, AVTEXT =E2=80=94
>
> As discussed in Yokohama, Adam Roach et al have submitted a draft on a= =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying encod= ed and dependent streams.
>
> This is a call to see whether the AVTEXT working group wants to take o= n this work as a work item (both adding a milestone for the work and adopti= ng the existing draft as the starting point for a working group document).<= br> >
> Please comment on the AVTEXT mailing list in the next two weeks (by Fe= bruary 15, 2016).

I don=E2=80=99t object to adopting this draft as a working group ite= m.

However, I do think the working group should carefully review the semantics= of the RID before this is published as an RFC. The complaint in the Introd= uction that none of the previous attempts to address this problem =E2=80=9C= have the proper ordinality to refer to an individual stream; all such ident= ifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99= t align with the later requirements that main and redundancy RTP streams ha= ve the same RID.


=E2=80=8BPerhaps the introduction could be more precise by saying = "have the proper ordinality to refer to an individual source RTP strea= m; all such identifiers can appear in more than one source RTP stream"= =E2=80=8B

=E2=80=8BThere is one RID per source RTP stream. =E2=80=8B
=E2=80=8B =C2=A0=E2=80=8BThe redundancy RTP streams have the sam= e RID as the source RTP stream to indicate which source RTP stream they are= redundant with (or repair, or refer to, or whatever you want to call it). = =C2=A0 It doesn't matter how many redundancy RTP streams there are per = RID, as long as there is only one source RTP stream. =C2=A0



=C2=A0
--
Colin Perkins
htt= ps://csperkins.org/




_______________________________________________
avtext mailing list
avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext

--001a11c35df609d035052acdea75-- From nobody Tue Feb 2 10:47:44 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788591B2F30 for ; Tue, 2 Feb 2016 10:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 xSqoQZJ3NN5Q for ; Tue, 2 Feb 2016 10:47:41 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 CA0491B2EF9 for ; Tue, 2 Feb 2016 10:47:39 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id xk3so58637589obc.2 for ; Tue, 02 Feb 2016 10:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KArXem/piVnTtLfkdimdg0Ij3YJ7B0bMTOemOaaLr2U=; b=oBw8udUCOTHNzMvAmJkRq3ZNKQB27+AVxuaA1y0+GoAw6OteNn/5JYS3/hNjmclu+k c151yY4zFCpAOyf9Ajwq2wfmquEbEHUBNHhDEHDaL8DhfUdyCHYDAJxje9/yj93yjMbH pw6TsORQMN0yJYDaMEkBaGTaKxdz5Wv7q3iIZFiSTdKZQMmkvRoIC4ZRqeRiYFDo8lZ9 0Z3LoLQTe4YxsfVjwga/BktE63tcA/4lW4Ptf0VFl26mgUB55No56VBfSykxb3hNTj3X g+iNhBOnbpTK6KX/A73/bAPwshtq47WQyHLYtvxh2tyBnNdocIQFVyRUiqsTRgUTsABy I5DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KArXem/piVnTtLfkdimdg0Ij3YJ7B0bMTOemOaaLr2U=; b=Dn6CrxeUmrill6JkITC+SBsfo4MANvnnVW15ly7gQpSV5tUozjZhj3KzOJ6MSe+NyO MppnKGDjuoZ/CJKfko7sKm6EMXzAU+BGk9O40elfO9w4OyA15mCw5Vl0GQUP3AXINUUk g4UROvweWg2lq1Rf1WqAzuZBeWbRwz8HyAau0I+bReeifNPveH7sI/qs4r/swChHCfd1 D5v/XqEer0SmGkITFuOxwar//AzzNm6nEZESzqUYaxrH+b/r5G01Nh1mPJuqna5hEFpE m8X6orutaAtVF2ugw0VUB661+VY9CiIlVD0XLu7nxS68KJVpBwAIXoiLiyQhUYdHs4CM oWjQ== X-Gm-Message-State: AG10YORT2LQyWkZjJL97yHjBwPbUiZfsQXmkO+H9oRSC+KEOnWIL3tBJqWomjmK9XARq9HOhscvAGP0/TZBS/FKD X-Received: by 10.60.82.229 with SMTP id l5mr24662107oey.6.1454438858973; Tue, 02 Feb 2016 10:47:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Tue, 2 Feb 2016 10:46:59 -0800 (PST) In-Reply-To: References: From: Peter Thatcher Date: Tue, 2 Feb 2016 10:46:59 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b6725dc89c0d4052acdef3a Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:47:42 -0000 --047d7b6725dc89c0d4052acdef3a Content-Type: text/plain; charset=UTF-8 I agree that it's simple, ready to ship, something we should have done long ago, and should proceed quickly to WGLC. On Mon, Feb 1, 2016 at 7:38 PM, Martin Thomson wrote: > Well, I hope that no one objects to adopting this. It would be a > severe case of institutional confusion if this call Jonathan started > were not merely a formality. I wonder what MMUSIC and RTCWEB would do > if this were suddenly rejected :) > > I've read draft-roach-avtext-rid-01. It's pretty straightforward > stuff. It makes me wonder why it's taken so long to reach the point > where we realized that an identifier for this thing was needed. It > looks pretty well ready to ship even. I encourage the chairs to > follow the current call with a WGLC. > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --047d7b6725dc89c0d4052acdef3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that it's simple, ready to ship, something = we should have done long ago, and should proceed quickly to WGLC.=C2=A0

On Mon, F= eb 1, 2016 at 7:38 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
Well, I hope that no o= ne objects to adopting this.=C2=A0 It would be a
severe case of institutional confusion if this call Jonathan started
were not merely a formality.=C2=A0 I wonder what MMUSIC and RTCWEB would do=
if this were suddenly rejected :)

I've read draft-roach-avtext-rid-01.=C2=A0 It's pretty straightforw= ard
stuff.=C2=A0 It makes me wonder why it's taken so long to reach the poi= nt
where we realized that an identifier for this thing was needed.=C2=A0 It looks pretty well ready to ship even.=C2=A0 I encourage the chairs to
follow the current call with a WGLC.

_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext

--047d7b6725dc89c0d4052acdef3a-- From nobody Tue Feb 2 10:51:38 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52151B2F45 for ; Tue, 2 Feb 2016 10:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 3Zjlxfre__Lr for ; Tue, 2 Feb 2016 10:51:35 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9861B2D53 for ; Tue, 2 Feb 2016 10:51:35 -0800 (PST) Received: from [212.159.116.76] (port=53802 helo=[192.168.1.100]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aQg32-00089v-DU; Tue, 02 Feb 2016 18:51:32 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Tue, 2 Feb 2016 18:51:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> To: Peter Thatcher X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: [avtext] Source vs redundancy stream in RID (was: Re: Call for adoption of RID draft) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:51:36 -0000 > On 2 Feb 2016, at 18:45, Peter Thatcher wrote: >=20 >=20 >=20 > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins = wrote: > > On 1 Feb 2016, at 18:43, Jonathan Lennox wrote: > > > > Hello, AVTEXT =E2=80=94 > > > > As discussed in Yokohama, Adam Roach et al have submitted a draft on = a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and dependent streams. > > > > This is a call to see whether the AVTEXT working group wants to take = on this work as a work item (both adding a milestone for the work and = adopting the existing draft as the starting point for a working group = document). > > > > Please comment on the AVTEXT mailing list in the next two weeks (by = February 15, 2016). >=20 > I don=E2=80=99t object to adopting this draft as a working group item. >=20 > However, I do think the working group should carefully review the = semantics of the RID before this is published as an RFC. The complaint = in the Introduction that none of the previous attempts to address this = problem =E2=80=9Chave the proper ordinality to refer to an individual = stream; all such identifiers can appear in more than one stream at a = time=E2=80=9D doesn=E2=80=99t align with the later requirements that = main and redundancy RTP streams have the same RID. >=20 >=20 > =E2=80=8BPerhaps the introduction could be more precise by saying = "have the proper ordinality to refer to an individual source RTP stream; = all such identifiers can appear in more than one source RTP stream"=E2=80=8B= >=20 > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP = stream to indicate which source RTP stream they are redundant with (or = repair, or refer to, or whatever you want to call it). It doesn=E2=80=99= t matter how many redundancy RTP streams there are per RID, as long as = there is only one source RTP stream. =20 Perhaps, but on the principle that explicit is better than implicit, = another design might be for each stream, source or redundancy, to have a = unique RID, and for redundancy streams to include a list of RID values = that they provide redundancy for. That way, there is no scope for = confusion between source and redundancy streams.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Feb 2 11:41:47 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1BA1B2DE1 for ; Tue, 2 Feb 2016 11:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 Hgbjqj5dPdTj for ; Tue, 2 Feb 2016 11:41:44 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 3A5A31B2DD4 for ; Tue, 2 Feb 2016 11:41:44 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id wb13so128483261obb.1 for ; Tue, 02 Feb 2016 11:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tZ0wGZAnMxiUNGr2pQgQV/qTqDuojFi8QI8N2W16aTs=; b=isd2nZba93f/Asosfz5lajuTkTGecRosDEvJUyfj/ew3aHRXJD5OwXXMXY5fknkskW dfktI1dvA4tHrkLg91pEu9VkDA32Ga62xD+Q3tZimTbMFd+vn4Cog4D4nBhUBnve4WLz 0idJ7j1xIpEm+XS+V8c7i/YB7v1/BAdXLBAq5DsB5zjAbYAiA/BiDAKQ9V4rtstIW7n0 sWx/JuuKDQ/ddvAZTL3U/uLgurDUNdrttE3PVYMx+3+/Y/uhDPphYww0PKKYbVFQcSmS o9xL1I/P0Kcf/YvcOsqH5fFlbTiU+gg7RyWYxh/GO0PeJ23XavF7hnaMJ18VW0XKUZFP M1WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tZ0wGZAnMxiUNGr2pQgQV/qTqDuojFi8QI8N2W16aTs=; b=PJpqFRVC0VaisRw2btuKMQl+euc04rIVVE8f/jeEForYX8EZCRuIdtUKQycrOdRjIp +zbC2bqjV0ILsGAK3BY2ik4z1pQs2CVmT61upMiFBWeS8Gsor714teHFXawQ8zbJlgrE amePv4ZItM3LuIUo/5EtGMX4xOLz5R+2hhOYHYUfd4OeZh7YQqSr3S7AuOfh73fDPqpS OqOCcNAkwUoYAgsY8Ne2aDkkHFIHndI3+dRL0VCfwb1bA5rGVJyHYr8JEsjn0P+tm3bR 0hjEUBBF+jIqulYBSmol6+VxsDa0kkxnPnDmG7H2uc70rAr49YCj/XtgbKDxC1dTUsnL xq3g== X-Gm-Message-State: AG10YOQlKRheyP64XRQZiiRm0n98EPsFjaxsfjQRFzpu2BSIJZ2NJ0mj6vecrLdnC6jtDhwXSrhQGxdlBjugy1k2 X-Received: by 10.182.129.228 with SMTP id nz4mr19900458obb.14.1454442103354; Tue, 02 Feb 2016 11:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Tue, 2 Feb 2016 11:41:03 -0800 (PST) In-Reply-To: <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> From: Peter Thatcher Date: Tue, 2 Feb 2016 11:41:03 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=089e0149c716eb3b03052aceb04c Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID (was: Re: Call for adoption of RID draft) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:41:46 -0000 --089e0149c716eb3b03052aceb04c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote: > > > On 2 Feb 2016, at 18:45, Peter Thatcher wrote: > > > > > > > > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins wrote= : > > > On 1 Feb 2016, at 18:43, Jonathan Lennox wrote: > > > > > > Hello, AVTEXT =E2=80=94 > > > > > > As discussed in Yokohama, Adam Roach et al have submitted a draft on = a > =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying enco= ded and dependent > streams. > > > > > > This is a call to see whether the AVTEXT working group wants to take > on this work as a work item (both adding a milestone for the work and > adopting the existing draft as the starting point for a working group > document). > > > > > > Please comment on the AVTEXT mailing list in the next two weeks (by > February 15, 2016). > > > > I don=E2=80=99t object to adopting this draft as a working group item. > > > > However, I do think the working group should carefully review the > semantics of the RID before this is published as an RFC. The complaint in > the Introduction that none of the previous attempts to address this probl= em > =E2=80=9Chave the proper ordinality to refer to an individual stream; all= such > identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align > with the later requirements that main and redundancy RTP streams have the > same RID. > > > > > > =E2=80=8BPerhaps the introduction could be more precise by saying "have= the > proper ordinality to refer to an individual source RTP stream; all such > identifiers can appear in more than one source RTP stream"=E2=80=8B > > > > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP streams > have the same RID as the source RTP stream to indicate which source RTP > stream they are redundant with (or repair, or refer to, or whatever you > want to call it). It doesn=E2=80=99t matter how many redundancy RTP str= eams there > are per RID, as long as there is only one source RTP stream. > > Perhaps, but on the principle that explicit is better than implicit, > another design might be for each stream, source or redundancy, to have a > unique RID, and for redundancy streams to include a list of RID values th= at > they provide redundancy for. That way, there is no scope for confusion > between source and redundancy streams. > =E2=80=8BWhen does a redundancy stream apply to more than one source RTP st= ream? Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? Wo= uld anything ever refer to it? If not, let's just not include it (it just wastes bytes). So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes). We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension). What are we left with? An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams. That sounds good to me, but we've just gone and re-invented RID. So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams. -- > Colin Perkins > https://csperkins.org/ > > > > > --089e0149c716eb3b03052aceb04c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins= .org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft= on a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to t= ake on this work as a work item (both adding a milestone for the work and a= dopting the existing draft as the starting point for a working group docume= nt).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (= by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a working group item.=
>
> However, I do think the working group should carefully review the sema= ntics of the RID before this is published as an RFC. The complaint in the I= ntroduction that none of the previous attempts to address this problem =E2= =80=9Chave the proper ordinality to refer to an individual stream; all such= identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2= =80=99t align with the later requirements that main and redundancy RTP stre= ams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise by saying &quo= t;have the proper ordinality to refer to an individual source RTP stream; a= ll such identifiers can appear in more than one source RTP stream"=E2= =80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B=C2= =A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP= stream to indicate which source RTP stream they are redundant with (or rep= air, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2= =80=99t matter how many redundancy RTP streams there are per RID, as long a= s there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, anothe= r design might be for each stream, source or redundancy, to have a unique R= ID, and for redundancy streams to include a list of RID values that they pr= ovide redundancy for. That way, there is no scope for confusion between sou= rce and redundancy streams.

=E2=80= =8BWhen does a redundancy stream apply to more than one source RTP stream?= =C2=A0 Flexfec is the only case I can think of, and that already provides a= ll of the necessary info in the payload, so there's no need for a heade= r extension. =C2=A0

=E2=80=8BAnd what value would an I= D of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it= ?=C2=A0 If not, let's just not include it (it just wastes bytes).
=

So let's start with your idea, remove the IDs of the re= dundancy RTP streams (since no one refers to them, they have no value, and = just waste bytes).=C2=A0 We'll also reduce the list to a single value (= since only flexfec would have a list, and flexfec doesn't need the head= er extension).=C2=A0 What are we left with?=C2=A0 An ID in the source RTP s= tream, and a reference to that ID in the redundancy RTP streams.=C2=A0 That= sounds good to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is mul= tiple RIDs in the redundancy RTP streams. But I don't really see a use = case for that, and on the principle of simple is better than complex, I'= ;d prefer a single value in the redundancy RTP streams.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> --
Colin Perkins
htt= ps://csperkins.org/





--089e0149c716eb3b03052aceb04c-- From nobody Thu Feb 4 14:58:03 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1791B3380 for ; Thu, 4 Feb 2016 14:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 f04N_Rf6jex9 for ; Thu, 4 Feb 2016 14:57:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9F5F11A01F7 for ; Thu, 4 Feb 2016 14:57:59 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u14Mvpdc017276 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 4 Feb 2016 16:57:52 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Peter Thatcher , Colin Perkins References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> From: Adam Roach Message-ID: <56B3D76F.3000606@nostrum.com> Date: Thu, 4 Feb 2016 16:57:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002080100080707090906" Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 22:58:02 -0000 This is a multi-part message in MIME format. --------------080002080100080707090906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs). Does anyone else want to weigh in? /a On 2/2/16 13:41, Peter Thatcher wrote: > > > On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins > wrote: > > > > On 2 Feb 2016, at 18:45, Peter Thatcher > wrote: > > > > > > > > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins > wrote: > > > On 1 Feb 2016, at 18:43, Jonathan Lennox > wrote: > > > > > > Hello, AVTEXT — > > > > > > As discussed in Yokohama, Adam Roach et al have submitted a > draft on a “RID” SDES item and header extension for identifying > encoded and dependent streams. > > > > > > This is a call to see whether the AVTEXT working group wants > to take on this work as a work item (both adding a milestone for > the work and adopting the existing draft as the starting point for > a working group document). > > > > > > Please comment on the AVTEXT mailing list in the next two > weeks (by February 15, 2016). > > > > I don’t object to adopting this draft as a working group item. > > > > However, I do think the working group should carefully review > the semantics of the RID before this is published as an RFC. The > complaint in the Introduction that none of the previous attempts > to address this problem “have the proper ordinality to refer to an > individual stream; all such identifiers can appear in more than > one stream at a time” doesn’t align with the later requirements > that main and redundancy RTP streams have the same RID. > > > > > > ​Perhaps the introduction could be more precise by saying "have > the proper ordinality to refer to an individual source RTP stream; > all such identifiers can appear in more than one source RTP stream"​ > > > > ​There is one RID per source RTP stream. ​​ ​The redundancy RTP > streams have the same RID as the source RTP stream to indicate > which source RTP stream they are redundant with (or repair, or > refer to, or whatever you want to call it). It doesn’t matter > how many redundancy RTP streams there are per RID, as long as > there is only one source RTP stream. > > Perhaps, but on the principle that explicit is better than > implicit, another design might be for each stream, source or > redundancy, to have a unique RID, and for redundancy streams to > include a list of RID values that they provide redundancy for. > That way, there is no scope for confusion between source and > redundancy streams. > > > ​When does a redundancy stream apply to more than one source RTP > stream? Flexfec is the only case I can think of, and that already > provides all of the necessary info in the payload, so there's no need > for a header extension. > > ​And what value would an ID of a redundancy RTP stream provide? Would > anything ever refer to it? If not, let's just not include it (it just > wastes bytes). > > So let's start with your idea, remove the IDs of the redundancy RTP > streams (since no one refers to them, they have no value, and just > waste bytes). We'll also reduce the list to a single value (since > only flexfec would have a list, and flexfec doesn't need the header > extension). What are we left with? An ID in the source RTP stream, > and a reference to that ID in the redundancy RTP streams. That sounds > good to me, but we've just gone and re-invented RID. > > So it sounds like what you're really asking for is multiple RIDs in > the redundancy RTP streams. But I don't really see a use case for > that, and on the principle of simple is better than complex, I'd > prefer a single value in the redundancy RTP streams. > > -- > Colin Perkins > https://csperkins.org/ > > > > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --------------080002080100080707090906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT —
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don’t object to adopting this draft as a working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem “have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time” doesn’t align with the later requirements that main and redundancy RTP streams have the same RID.
>
>
> ​Perhaps the introduction could be more precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"​
>
> ​There is one RID per source RTP stream. ​​  ​The redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn’t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

​When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

​And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext

--------------080002080100080707090906-- From nobody Thu Feb 4 15:21:03 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66411B33E5 for ; Thu, 4 Feb 2016 15:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 gngeHpRNKGM8 for ; Thu, 4 Feb 2016 15:21:00 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 75B201B33E6 for ; Thu, 4 Feb 2016 15:21:00 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id s2so30670756oie.2 for ; Thu, 04 Feb 2016 15:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yo2nFKCybDy3un/z/6XYb+u3glWDgWcA3GaleUOv2VU=; b=k6r+IX4/qVOE4YuaRiHAx+J+opzhge7KFkrD8ZMNxXG+98f8WIDJZBQX+PCgZv5yqx BFMcE0V4yr8GwqKVGK4tMRQ1qEzsOifdv8XMpTX4UxGBMdFF/MFOID2och2HV/yB6N7R d5J/+ZW6+I1yaBt531PzmmmRvyjqLUtuSc+qTP3wgjfN/xsT7we4Kr9gGWCW5NP4QFQQ zP5EBM0SmEMiuI20jz+jp/AflB3bi3s1nrtamkIvd/sSTDcBil7/Z/noV0TIRlzJnG16 MTSbLwUqXiFbR31587hQWAQxvShv7cLonOJyb+XsO8SIrpgatD3wNj4Ti11i2AkTj2gr wwFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yo2nFKCybDy3un/z/6XYb+u3glWDgWcA3GaleUOv2VU=; b=TTkEH0hPyCWOUP3EwzkooG5GKgSVZbZ/z/8HH+4qkoP6uvvegW8Bp+UlaQx5Y8d4uM /ao6t3TsU4xupv4LYrKfsquEecm7SuaQBuNF2YyoMOwwiSat5jqr56Xve7fwruGhNyKS YUUdJXVJ8QlnENWDvGmNBo3fI3m0c3D9/KM3Q6KtsqsLnnL+TRDcB1NT2FsS/PmZTLqW MPruoai4XOVMNx2IM7cMs9X0+9FQKy4JVuisi+o5JEhLq050C7YeGL0l5IH96WV5W3NR cBUQvuiw+J8WtmghhIf+vUmPE6HFdtfSOy5XiQUOe++N7JLyCXNqU2C/P8P4HcrReUCG pO8w== X-Gm-Message-State: AG10YOROUNUBS193tfAjXQnE2yfC0QbfXYIWWzEsjQY/fh1T4Cbhou5TjhNY8iLfh9diHzh/5kwOzK+Pl2rBVeds X-Received: by 10.182.213.71 with SMTP id nq7mr9550516obc.65.1454628059636; Thu, 04 Feb 2016 15:20:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 15:20:20 -0800 (PST) In-Reply-To: <56B3D76F.3000606@nostrum.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> From: Peter Thatcher Date: Thu, 4 Feb 2016 15:20:20 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c2d4e8c6bf93052af9fc87 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:21:02 -0000 --001a11c2d4e8c6bf93052af9fc87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You already know which I prefer, but if we were to choose to put a ID on the redundancy stream, we'd need to have two IDs in the header extensions, or two header extensions: one for the redundancy stream to refer to itself and one for the redundancy stream to refer to the source stream. And if we did so, I'd prefer to make the redundancy stream's ID/heeader-extension referring to itself to be optional. On Thu, Feb 4, 2016 at 2:57 PM, Adam Roach wrote: > I don't have a strong opinion one way or another here. At this point, I > hear one voice for keeping as-is, and another for giving redundancy strea= ms > their own RID (or RIDs? I don't understand the suggestion that we use a > list of RIDs). > > Does anyone else want to weigh in? > > /a > > On 2/2/16 13:41, Peter Thatcher wrote: > > > > On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote: > >> >> > On 2 Feb 2016, at 18:45, Peter Thatcher < >> pthatcher@google.com> wrote: >> > >> > >> > >> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >> csp@csperkins.org> wrote: >> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >> jonathan@vidyo.com> wrote: >> > > >> > > Hello, AVTEXT =E2=80=94 >> > > >> > > As discussed in Yokohama, Adam Roach et al have submitted a draft on >> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying e= ncoded and >> dependent streams. >> > > >> > > This is a call to see whether the AVTEXT working group wants to take >> on this work as a work item (both adding a milestone for the work and >> adopting the existing draft as the starting point for a working group >> document). >> > > >> > > Please comment on the AVTEXT mailing list in the next two weeks (by >> February 15, 2016). >> > >> > I don=E2=80=99t object to adopting this draft as a working group item. >> > >> > However, I do think the working group should carefully review the >> semantics of the RID before this is published as an RFC. The complaint i= n >> the Introduction that none of the previous attempts to address this prob= lem >> =E2=80=9Chave the proper ordinality to refer to an individual stream; al= l such >> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >> with the later requirements that main and redundancy RTP streams have th= e >> same RID. >> > >> > >> > =E2=80=8BPerhaps the introduction could be more precise by saying "hav= e the >> proper ordinality to refer to an individual source RTP stream; all such >> identifiers can appear in more than one source RTP stream"=E2=80=8B >> > >> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >> streams have the same RID as the source RTP stream to indicate which sou= rce >> RTP stream they are redundant with (or repair, or refer to, or whatever = you >> want to call it). It doesn=E2=80=99t matter how many redundancy RTP st= reams there >> are per RID, as long as there is only one source RTP stream. >> >> Perhaps, but on the principle that explicit is better than implicit, >> another design might be for each stream, source or redundancy, to have a >> unique RID, and for redundancy streams to include a list of RID values t= hat >> they provide redundancy for. That way, there is no scope for confusion >> between source and redundancy streams. >> > > =E2=80=8BWhen does a redundancy stream apply to more than one source RTP = stream? > Flexfec is the only case I can think of, and that already provides all of > the necessary info in the payload, so there's no need for a header > extension. > > =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? = Would > anything ever refer to it? If not, let's just not include it (it just > wastes bytes). > > So let's start with your idea, remove the IDs of the redundancy RTP > streams (since no one refers to them, they have no value, and just waste > bytes). We'll also reduce the list to a single value (since only flexfec > would have a list, and flexfec doesn't need the header extension). What > are we left with? An ID in the source RTP stream, and a reference to tha= t > ID in the redundancy RTP streams. That sounds good to me, but we've just > gone and re-invented RID. > > So it sounds like what you're really asking for is multiple RIDs in the > redundancy RTP streams. But I don't really see a use case for that, and o= n > the principle of simple is better than complex, I'd prefer a single value > in the redundancy RTP streams. > > -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > _______________________________________________ > avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/a= vtext > > > --001a11c2d4e8c6bf93052af9fc87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You already know which I prefer, but if we were to choo= se to put a ID on the redundancy stream, we'd need to have two IDs in t= he header extensions, or two header extensions: one for the redundancy stre= am to refer to itself and one for the redundancy stream to refer to the sou= rce stream.=C2=A0 And if we did so, I'd prefer to make the redundancy s= tream's ID/heeader-extension referring to itself to be optional. =C2=A0=

On Th= u, Feb 4, 2016 at 2:57 PM, Adam Roach <adam@nostrum.com> wrot= e:
=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80=8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext


--001a11c2d4e8c6bf93052af9fc87-- From nobody Thu Feb 4 15:54:39 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA49E1A914F for ; Thu, 4 Feb 2016 15:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 oH5qbTJXI3Um for ; Thu, 4 Feb 2016 15:54:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D0C411A911E for ; Thu, 4 Feb 2016 15:54:36 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u14NsNaL022923 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 4 Feb 2016 17:54:29 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Peter Thatcher References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> From: Adam Roach Message-ID: <56B3E4AB.90203@nostrum.com> Date: Thu, 4 Feb 2016 17:54:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040803090504060906050304" Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:54:38 -0000 This is a multi-part message in MIME format. --------------040803090504060906050304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/4/16 17:20, Peter Thatcher wrote: > You already know which I prefer, but if we were to choose to put a ID > on the redundancy stream, we'd need to have two IDs in the header > extensions, or two header extensions: one for the redundancy stream to > refer to itself and one for the redundancy stream to refer to the > source stream. And if we did so, I'd prefer to make the redundancy > stream's ID/heeader-extension referring to itself to be optional. So, there's a third option here in which the redundancy stream gets its own RID, and we bind those RIDs together in the SDP. Minimally, if we had a source RTP stream with a RID of 0, and assigned its redundancy stream a RID of 1, you could make the application aware of their association like this: a=rid:0 send a=rid:1 send depend=0 In fact, as I'm rummaging around in my memory, I think this use case is why we added "depend" to the mmusic document in the first place. This seems effective and clean. Am I overlooking something? /a --------------040803090504060906050304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/16 17:20, Peter Thatcher wrote:
You already know which I prefer, but if we were to choose to put a ID on the redundancy stream, we'd need to have two IDs in the header extensions, or two header extensions: one for the redundancy stream to refer to itself and one for the redundancy stream to refer to the source stream.  And if we did so, I'd prefer to make the redundancy stream's ID/heeader-extension referring to itself to be optional.

So, there's a third option here in which the redundancy stream gets its own RID, and we bind those RIDs together in the SDP. Minimally, if we had a source RTP stream with a RID of 0, and assigned its redundancy stream a RID of 1, you could make the application aware of their association like this:

  a=rid:0 send
  a=rid:1 send depend=0

In fact, as I'm rummaging around in my memory, I think this use case is why we added "depend" to the mmusic document in the first place. This seems effective and clean. Am I overlooking something?

/a
--------------040803090504060906050304-- From nobody Thu Feb 4 15:55:13 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7AE1A9172 for ; Thu, 4 Feb 2016 15:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 C3YllTps4Oun for ; Thu, 4 Feb 2016 15:55:08 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11131A916B for ; Thu, 4 Feb 2016 15:55:08 -0800 (PST) Received: from [81.187.2.149] (port=37755 helo=[192.168.0.64]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRTjs-0000fn-1r; Thu, 04 Feb 2016 23:55:05 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_412A4683-3F0F-4CF8-B2E3-CB7AEF59CE39" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56B3D76F.3000606@nostrum.com> Date: Thu, 4 Feb 2016 23:54:57 +0000 Message-Id: <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:55:12 -0000 --Apple-Mail=_412A4683-3F0F-4CF8-B2E3-CB7AEF59CE39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Feb 2016, at 22:57, Adam Roach wrote: >=20 > I don't have a strong opinion one way or another here. At this point, = I hear one voice for keeping as-is, and another for giving redundancy = streams their own RID (or RIDs? I don't understand the suggestion that = we use a list of RIDs). Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to = do two things: provide a unique identifier for an RTP stream, and = provide an identifier which can connect a redundancy RTP stream and the = RTP stream it is protecting. I was suggesting that these functions = should be kept separate. Each stream, whether original or redundancy, = could optionally have a RID assigned to it. The original and redundant = streams would have different RIDs. Each stream that has a RID assigned = to it could also (optionally) include a list of other RID values that = it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, these other = RID values could be the stream(s) that it=E2=80=99s protecting; if = it=E2=80=99s a simulcast stream, they could be the other versions; if = it=E2=80=99s a layered stream, they could be the other layers, etc. Each = stream therefore has a unique identifier, and relationships between them = are explicit rather than implicit.=20 (We can argue later about whether this is one SDES item with two parts = to it, or two SDES items; the syntax isn=E2=80=99t the important part)=20= Yes, this has slightly higher overhead (although if you care about = overhead that much, you probably want to rethink sending a redundant = video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex = in some ways; but it=E2=80=99s simpler in that each stream has a unique = identifier that can unambiguously refer to it, whether from another RTP = stream or from the signalling channel, so we won=E2=80=99t have to = define yet another identifier if we later find a requirement to refer to = original and redundant streams independently.=20 Colin > Does anyone else want to weigh in? >=20 > /a >=20 > On 2/2/16 13:41, Peter Thatcher wrote: >>=20 >>=20 >> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins > wrote: >>=20 >> > On 2 Feb 2016, at 18:45, Peter Thatcher < = pthatcher@google.com = > wrote: >> > >> > >> > >> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < = csp@csperkins.org > = wrote: >> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < = jonathan@vidyo.com = > wrote: >> > > >> > > Hello, AVTEXT =E2=80=94 >> > > >> > > As discussed in Yokohama, Adam Roach et al have submitted a draft = on a =E2=80=9CRID=E2=80=9D SDES item and header extension for = identifying encoded and dependent streams. >> > > >> > > This is a call to see whether the AVTEXT working group wants to = take on this work as a work item (both adding a milestone for the work = and adopting the existing draft as the starting point for a working = group document). >> > > >> > > Please comment on the AVTEXT mailing list in the next two weeks = (by February 15, 2016). >> > >> > I don=E2=80=99t object to adopting this draft as a working group = item. >> > >> > However, I do think the working group should carefully review the = semantics of the RID before this is published as an RFC. The complaint = in the Introduction that none of the previous attempts to address this = problem =E2=80=9Chave the proper ordinality to refer to an individual = stream; all such identifiers can appear in more than one stream at a = time=E2=80=9D doesn=E2=80=99t align with the later requirements that = main and redundancy RTP streams have the same RID. >> > >> > >> > =E2=80=8BPerhaps the introduction could be more precise by saying = "have the proper ordinality to refer to an individual source RTP stream; = all such identifiers can appear in more than one source RTP stream"=E2=80=8B= >> > >> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP = stream to indicate which source RTP stream they are redundant with (or = repair, or refer to, or whatever you want to call it). It doesn=E2=80=99= t matter how many redundancy RTP streams there are per RID, as long as = there is only one source RTP stream. >>=20 >> Perhaps, but on the principle that explicit is better than implicit, = another design might be for each stream, source or redundancy, to have a = unique RID, and for redundancy streams to include a list of RID values = that they provide redundancy for. That way, there is no scope for = confusion between source and redundancy streams. >>=20 >> =E2=80=8BWhen does a redundancy stream apply to more than one source = RTP stream? Flexfec is the only case I can think of, and that already = provides all of the necessary info in the payload, so there's no need = for a header extension. =20 >>=20 >> =E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide? Would anything ever refer to it? If not, let's just not = include it (it just wastes bytes). >>=20 >> So let's start with your idea, remove the IDs of the redundancy RTP = streams (since no one refers to them, they have no value, and just waste = bytes). We'll also reduce the list to a single value (since only = flexfec would have a list, and flexfec doesn't need the header = extension). What are we left with? An ID in the source RTP stream, and = a reference to that ID in the redundancy RTP streams. That sounds good = to me, but we've just gone and re-invented RID. >>=20 >> So it sounds like what you're really asking for is multiple RIDs in = the redundancy RTP streams. But I don't really see a use case for that, = and on the principle of simple is better than complex, I'd prefer a = single value in the redundancy RTP streams. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext = >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_412A4683-3F0F-4CF8-B2E3-CB7AEF59CE39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> = wrote:

=20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Perhaps I didn=E2=80=99t explain myself well. The = RID draft is trying to do two things: provide a unique identifier for an = RTP stream, and provide an identifier which can connect a redundancy RTP = stream and the RTP stream it is protecting. I was suggesting that these = functions should be kept separate. Each stream, whether original or = redundancy, could optionally have a RID assigned to it. The original and = redundant streams would have different RIDs. Each stream that has a RID = assigned to it could also (optionally) include a list of other RID = values that it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, = these other RID values could be the stream(s) that it=E2=80=99s = protecting; if it=E2=80=99s a simulcast stream, they could be the other = versions; if it=E2=80=99s a layered stream, they could be the other = layers, etc. Each stream therefore has a unique identifier, and = relationships between them are explicit rather than = implicit. 

(We can argue later = about whether this is one SDES item with two parts to it, or two SDES = items; the syntax isn=E2=80=99t the important part) 

Yes, this has slightly higher overhead (although = if you care about overhead that much, you probably want to rethink = sending a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps = slightly more complex in some ways; but it=E2=80=99s simpler in that = each stream has a unique identifier that can unambiguously refer to it, = whether from another RTP stream or from the signalling channel, so we = won=E2=80=99t have to define yet another identifier if we later find a = requirement to refer to original and redundant streams = independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and = header extension for identifying encoded and dependent = streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group = document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a = working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an = individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the = later requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more = precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. = =E2=80=8B=E2=80=8B  =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn=E2=80=99t matter = how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think = of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

=E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide?  Would anything ever refer to it?  If not, let's = just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce = the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header = extension).  What are we left with?  An ID in the source RTP = stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just = gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org=
/mailman/listinfo/avtext




-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_412A4683-3F0F-4CF8-B2E3-CB7AEF59CE39-- From nobody Thu Feb 4 15:56:14 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E461A9250 for ; Thu, 4 Feb 2016 15:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 sOJ6BJGrKMZC for ; Thu, 4 Feb 2016 15:56:11 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56E91A9241 for ; Thu, 4 Feb 2016 15:56:10 -0800 (PST) Received: from [81.187.2.149] (port=43823 helo=[192.168.0.64]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRTkt-0000qh-23; Thu, 04 Feb 2016 23:56:07 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_610A3248-9B13-42E7-8D84-E433D001FFC5" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56B3E4AB.90203@nostrum.com> Date: Thu, 4 Feb 2016 23:56:05 +0000 Message-Id: <86E06484-4104-4EA6-97F1-D1F37C6836E1@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <56B3E4AB.90203@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:56:13 -0000 --Apple-Mail=_610A3248-9B13-42E7-8D84-E433D001FFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Feb 2016, at 23:54, Adam Roach wrote: >=20 > On 2/4/16 17:20, Peter Thatcher wrote: >> You already know which I prefer, but if we were to choose to put a ID = on the redundancy stream, we'd need to have two IDs in the header = extensions, or two header extensions: one for the redundancy stream to = refer to itself and one for the redundancy stream to refer to the source = stream. And if we did so, I'd prefer to make the redundancy stream's = ID/heeader-extension referring to itself to be optional. >=20 > So, there's a third option here in which the redundancy stream gets = its own RID, and we bind those RIDs together in the SDP. Minimally, if = we had a source RTP stream with a RID of 0, and assigned its redundancy = stream a RID of 1, you could make the application aware of their = association like this: >=20 > a=3Drid:0 send > a=3Drid:1 send depend=3D0 >=20 > In fact, as I'm rummaging around in my memory, I think this use case = is why we added "depend" to the mmusic document in the first place. This = seems effective and clean. Am I overlooking something? That=E2=80=99s essentially what I=E2=80=99m proposing, except that I was = also giving the option of making the dependency explicit in the RTP = packets.=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_610A3248-9B13-42E7-8D84-E433D001FFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Feb 2016, at 23:54, Adam Roach <adam@nostrum.com> = wrote:

=20 =20
On 2/4/16 17:20, Peter Thatcher = wrote:
You already know which I prefer, but if we were to choose to put a ID on the redundancy stream, we'd need to have two IDs in the header extensions, or two header extensions: one for the redundancy stream to refer to itself and one for the redundancy stream to refer to the source stream.  And if we did so, I'd prefer = to make the redundancy stream's ID/heeader-extension referring to itself to be optional.

So, there's a third option here in which the redundancy stream gets its own RID, and we bind those RIDs together in the SDP. Minimally, if we had a source RTP stream with a RID of 0, and assigned its redundancy stream a RID of 1, you could make the application aware of their association like this:

  a=3Drid:0 send
  a=3Drid:1 send depend=3D0

In fact, as I'm rummaging around in my memory, I think this use case is why we added "depend" to the mmusic document in the first place. This seems effective and clean. Am I overlooking something?

That=E2=80=99= s essentially what I=E2=80=99m proposing, except that I was also giving = the option of making the dependency explicit in the RTP = packets. 


-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_610A3248-9B13-42E7-8D84-E433D001FFC5-- From nobody Thu Feb 4 16:08:48 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623EA1ABC0F for ; Thu, 4 Feb 2016 16:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 vzCvGQYFpjOq for ; Thu, 4 Feb 2016 16:08:46 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 491C51A92E7 for ; Thu, 4 Feb 2016 16:08:46 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id wb13so76238455obb.1 for ; Thu, 04 Feb 2016 16:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CkrcBBP7gRc0hYIiaHln3MF+csptpHdJs8lHqmndfAc=; b=Jd/RbDkTOPeT/gWxofPDi+fVgoF+pGI/TqD83TcdagNnWToXdO3bEryP86ZBIgDQLr 8DSAWvZxhgQN8hVvLxBQtfXCOUHp6CcAwtRmbEnWxfB+f9kaV8b9XAyhtTX78i0icN44 Y+7a6v7KP1TpmQx/I2NgMh2fvIy3CMyYraK05/fcQMQpCkdygV++c4MzG8fXJzDYomEY vI4J5kKtLl51PFGfejMEh7mVd8u1u39IIuyf6XFMo46mHa4e/Udn7yYDZfXqEFKHYhHc WCriPo4HGsmLNi79z9aK1vpFvlED4o1jkG/CZELNE9WvVYEbKXTCizFEWyjvYBpt8Hah oI/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CkrcBBP7gRc0hYIiaHln3MF+csptpHdJs8lHqmndfAc=; b=TCoAyZltI3vaN+gTztqQU1Lf0jDHpxADOjYXa1A5uqjql+w3JWhl3KQTtr73hNoaxC s/8MB4utyRKlb9NDws5D2xfDnKG3WwTT7ieqS2CrMsVQLeXsisdvQZvnrYMP6MSrXixH 5KI+ZACRb1uhGfOU14adKMmB2JfrqgZXCZN47w1hZcr/fAZs7eh9cm5ZYitcWK6motOo yboRMfWyvR1IftpBWRqy36jkjJbvtLeVoN37GwTY+/FTVyOYSJjrNMIRomLteaVQK1+H mWPxv+KcVq1WLe6o4tZ97gif138QHieuNxwCKA2NCvbbq3+NnQEEdM48BNYlg+PXCpIC nC8Q== X-Gm-Message-State: AG10YOQ9vxK5t2h8Z49l6dpENmCy/dD54rroKm1h+jXJtgMciL9N1yxFqxNhqrdwJ0zGAEgR3hid+XqvJC4O2pik X-Received: by 10.60.58.103 with SMTP id p7mr10160177oeq.2.1454630925519; Thu, 04 Feb 2016 16:08:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 16:08:06 -0800 (PST) In-Reply-To: <56B3E4AB.90203@nostrum.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <56B3E4AB.90203@nostrum.com> From: Peter Thatcher Date: Thu, 4 Feb 2016 16:08:06 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e0158adcc989c4b052afaa79e Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:08:47 -0000 --089e0158adcc989c4b052afaa79e Content-Type: text/plain; charset=UTF-8 That seems like needless complexity to me. Do we really need to make this more complex? On Thu, Feb 4, 2016 at 3:54 PM, Adam Roach wrote: > On 2/4/16 17:20, Peter Thatcher wrote: > > You already know which I prefer, but if we were to choose to put a ID on > the redundancy stream, we'd need to have two IDs in the header extensions, > or two header extensions: one for the redundancy stream to refer to itself > and one for the redundancy stream to refer to the source stream. And if we > did so, I'd prefer to make the redundancy stream's ID/heeader-extension > referring to itself to be optional. > > > So, there's a third option here in which the redundancy stream gets its > own RID, and we bind those RIDs together in the SDP. Minimally, if we had a > source RTP stream with a RID of 0, and assigned its redundancy stream a RID > of 1, you could make the application aware of their association like this: > > a=rid:0 send > a=rid:1 send depend=0 > > In fact, as I'm rummaging around in my memory, I think this use case is > why we added "depend" to the mmusic document in the first place. This seems > effective and clean. Am I overlooking something? > > /a > --089e0158adcc989c4b052afaa79e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That seems like needless complexity to me.=C2=A0 Do we = really need to make this more complex?

=
On Thu, Feb 4, 2016 at 3:54 PM, Adam Roach <adam= @nostrum.com> wrote:
=20 =20 =20
On 2/4/16 17:20, Peter Thatcher wrote:
You already know which I prefer, but if we were to choose to put a ID on the redundancy stream, we'd need to have two IDs in the heade= r extensions, or two header extensions: one for the redundancy stream to refer to itself and one for the redundancy stream to refer to the source stream.=C2=A0 And if we did so, I'd prefe= r to make the redundancy stream's ID/heeader-extension referring t= o itself to be optional.

 So, there's a third option here in which the redundancy stream gets its own RID, and we bind those RIDs together in the SDP. Minimally, if we had a source RTP stream with a RID of 0, and assigned its redundancy stream a RID of 1, you could make the application aware of their association like this:

=C2=A0 a=3Drid:0 send
=C2=A0 a=3Drid:1 send depend=3D0

In fact, as I'm rummaging around in my memory, I think this use cas= e is why we added "depend" to the mmusic document in the first = place. This seems effective and clean. Am I overlooking something?

/a

--089e0158adcc989c4b052afaa79e-- From nobody Thu Feb 4 16:14:47 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC80A1ACDC0 for ; Thu, 4 Feb 2016 16:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 s-9BIqmyyqJW for ; Thu, 4 Feb 2016 16:14:43 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 E9F7B1ACD78 for ; Thu, 4 Feb 2016 16:14:41 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id x21so31608649oix.3 for ; Thu, 04 Feb 2016 16:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mkkfJadGETc9bUx4cqhw9R2mIYY+lRx7GBrDeaXNlOU=; b=BGqq+K/Sg+52CxLGCtaL0iZR9HD8ZLhMIhu/trVjIypee+vkvC7NWIkNeIdEZA4meQ Mb+sgoRV5Y1GwS0wL0GCiq55FuDOo0CuvEaSikxSg0/7JfeGQl/CmGgb6DUSL3PgeSfy avjkzK2AKlHyZal6zaDSe5eIyBW/nTBQimLkeVB6idsTcaWaFMRnqfF6Gny3V+sQGOas SsZFsEG7B1nuDHReboYFfOlO/P5eZ8STcbeahD69I3d4BawI2HkS2lX2pPfiRTytpL9L 5jC0h1u9SEBl3QB7MM8CgABTykmGi4w4/74oDhsXFLT4joffL3ovsDBBuQRrftebIarT IrIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mkkfJadGETc9bUx4cqhw9R2mIYY+lRx7GBrDeaXNlOU=; b=NfnGfoo8TNFCM34t0k0urx3V2hIk35zkvzWIJv4dkFsjLC0QgD25mcpzJWYCf1vdYP yEJZLYWX9EUpkIzfdi2a3HiYaO6sDpfFNHQBztoQgpSqITPTEgb4rr2ddTrsVh3MI4WK lijPDWRWvzUUR1CaTLy8PSA66dgSBa3U5dPo0xoJLuK4yMfZUZyVRkm2Wf07hA0kAGzN zAjWtuojP9Vu/AcnlOCsx/Jygv+uvp4LWJl45U3KdIvAnHyeO3+7If0X7HPdTp2KZ+6Q 9CCzsndO0wwLzNlMpBriu0ZXPtgb+7hcN/hiWcJ5KoBKW5szWJnIwt3k8yk5fqhVEywf hjgQ== X-Gm-Message-State: AG10YORxcggN51sr26kva8Y186ReYSUvSpW3Tln60IV7wvT+sYe7ih43qEIYIrer9TaJoLzfXI3ybBZPqAC++jPH X-Received: by 10.202.217.67 with SMTP id q64mr5906248oig.58.1454631281238; Thu, 04 Feb 2016 16:14:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 16:14:01 -0800 (PST) In-Reply-To: <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> From: Peter Thatcher Date: Thu, 4 Feb 2016 16:14:01 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a113cf48ccc7a5e052afabc45 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:14:46 -0000 --001a113cf48ccc7a5e052afabc45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I want to be able to pick one ID and put that one ID in the RTP packets and the SDP and be done. If we define optional additional IDs and flexibility on top of that, I'm not opposed to that, but I want the common use case to be simple: pick one ID, send one ID, and leave the other things optional (or non-existent). It's not worth complicating the main use case for other, theoretical uses. On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: > > On 4 Feb 2016, at 22:57, Adam Roach wrote: > > I don't have a strong opinion one way or another here. At this point, I > hear one voice for keeping as-is, and another for giving redundancy strea= ms > their own RID (or RIDs? I don't understand the suggestion that we use a > list of RIDs). > > > Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to = do two > things: provide a unique identifier for an RTP stream, and provide an > identifier which can connect a redundancy RTP stream and the RTP stream i= t > is protecting. I was suggesting that these functions should be kept > separate. Each stream, whether original or redundancy, could optionally > have a RID assigned to it. The original and redundant streams would have > different RIDs. Each stream that has a RID assigned to it could also > (optionally) include a list of other RID values that it=E2=80=99s associa= ted with. > If it=E2=80=99s a FEC stream, these other RID values could be the stream(= s) that > it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could b= e the other > versions; if it=E2=80=99s a layered stream, they could be the other layer= s, etc. > Each stream therefore has a unique identifier, and relationships between > them are explicit rather than implicit. > > (We can argue later about whether this is one SDES item with two parts to > it, or two SDES items; the syntax isn=E2=80=99t the important part) > > Yes, this has slightly higher overhead (although if you care about > overhead that much, you probably want to rethink sending a redundant vide= o > stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in some= ways; but it=E2=80=99s > simpler in that each stream has a unique identifier that can unambiguousl= y > refer to it, whether from another RTP stream or from the signalling > channel, so we won=E2=80=99t have to define yet another identifier if we = later find > a requirement to refer to original and redundant streams independently. > > Colin > > > > Does anyone else want to weigh in? > > /a > > On 2/2/16 13:41, Peter Thatcher wrote: > > > > On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote: > >> >> > On 2 Feb 2016, at 18:45, Peter Thatcher < >> pthatcher@google.com> wrote: >> > >> > >> > >> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >> csp@csperkins.org> wrote: >> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >> jonathan@vidyo.com> wrote: >> > > >> > > Hello, AVTEXT =E2=80=94 >> > > >> > > As discussed in Yokohama, Adam Roach et al have submitted a draft on >> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying e= ncoded and >> dependent streams. >> > > >> > > This is a call to see whether the AVTEXT working group wants to take >> on this work as a work item (both adding a milestone for the work and >> adopting the existing draft as the starting point for a working group >> document). >> > > >> > > Please comment on the AVTEXT mailing list in the next two weeks (by >> February 15, 2016). >> > >> > I don=E2=80=99t object to adopting this draft as a working group item. >> > >> > However, I do think the working group should carefully review the >> semantics of the RID before this is published as an RFC. The complaint i= n >> the Introduction that none of the previous attempts to address this prob= lem >> =E2=80=9Chave the proper ordinality to refer to an individual stream; al= l such >> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >> with the later requirements that main and redundancy RTP streams have th= e >> same RID. >> > >> > >> > =E2=80=8BPerhaps the introduction could be more precise by saying "hav= e the >> proper ordinality to refer to an individual source RTP stream; all such >> identifiers can appear in more than one source RTP stream"=E2=80=8B >> > >> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >> streams have the same RID as the source RTP stream to indicate which sou= rce >> RTP stream they are redundant with (or repair, or refer to, or whatever = you >> want to call it). It doesn=E2=80=99t matter how many redundancy RTP st= reams there >> are per RID, as long as there is only one source RTP stream. >> >> Perhaps, but on the principle that explicit is better than implicit, >> another design might be for each stream, source or redundancy, to have a >> unique RID, and for redundancy streams to include a list of RID values t= hat >> they provide redundancy for. That way, there is no scope for confusion >> between source and redundancy streams. >> > > =E2=80=8BWhen does a redundancy stream apply to more than one source RTP = stream? > Flexfec is the only case I can think of, and that already provides all of > the necessary info in the payload, so there's no need for a header > extension. > > =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? = Would > anything ever refer to it? If not, let's just not include it (it just > wastes bytes). > > So let's start with your idea, remove the IDs of the redundancy RTP > streams (since no one refers to them, they have no value, and just waste > bytes). We'll also reduce the list to a single value (since only flexfec > would have a list, and flexfec doesn't need the header extension). What > are we left with? An ID in the source RTP stream, and a reference to tha= t > ID in the redundancy RTP streams. That sounds good to me, but we've just > gone and re-invented RID. > > So it sounds like what you're really asking for is multiple RIDs in the > redundancy RTP streams. But I don't really see a use case for that, and o= n > the principle of simple is better than complex, I'd prefer a single value > in the redundancy RTP streams. > > -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > _______________________________________________ > avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/a= vtext > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a113cf48ccc7a5e052afabc45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I want to be able to pick one ID and put that one ID in= the RTP packets and the SDP and be done.=C2=A0 If we define optional addit= ional IDs and flexibility on top of that, I'm not opposed to that, but = I want the common use case to be simple: pick one ID, send one ID, and leav= e the other things optional (or non-existent).=C2=A0 It's not worth com= plicating the main use case for other, theoretical uses.

On Thu, Feb 4, 2016 = at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam = Roach <adam@nostru= m.com> wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

P= erhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do = two things: provide a unique identifier for an RTP stream, and provide an i= dentifier which can connect a redundancy RTP stream and the RTP stream it i= s protecting. I was suggesting that these functions should be kept separate= . Each stream, whether original or redundancy, could optionally have a RID = assigned to it. The original and redundant streams would have different RID= s. Each stream that has a RID assigned to it could also (optionally) includ= e a list of other RID values that it=E2=80=99s associated with. If it=E2=80= =99s a FEC stream, these other RID values could be the stream(s) that it=E2= =80=99s protecting; if it=E2=80=99s a simulcast stream, they could be the o= ther versions; if it=E2=80=99s a layered stream, they could be the other la= yers, etc. Each stream therefore has a unique identifier, and relationships= between them are explicit rather than implicit.=C2=A0

=
(We can argue later about whether this is one SDES item with two parts= to it, or two SDES items; the syntax isn=E2=80=99t the important part)=C2= =A0

Yes, this has slightly higher overhead (althou= gh if you care about overhead that much, you probably want to rethink sendi= ng a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly m= ore complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from anothe= r RTP stream or from the signalling channel, so we won=E2=80=99t have to de= fine yet another identifier if we later find a requirement to refer to orig= inal and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80=8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext




--=C2= =A0
Colin Perkins

<= /span>



--001a113cf48ccc7a5e052afabc45-- From nobody Thu Feb 4 16:26:25 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D01B2A5D for ; Thu, 4 Feb 2016 16:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 pLnH8gb4ZD_8 for ; Thu, 4 Feb 2016 16:26:20 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE171B2A5C for ; Thu, 4 Feb 2016 16:26:19 -0800 (PST) Received: from [81.187.2.149] (port=44644 helo=[192.168.0.64]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRUE0-0003n1-83; Fri, 05 Feb 2016 00:26:15 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7ACE5F9-F3AB-450E-B05E-8F5B60353591" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Fri, 5 Feb 2016 00:26:05 +0000 Message-Id: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> To: Peter Thatcher X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:26:23 -0000 --Apple-Mail=_B7ACE5F9-F3AB-450E-B05E-8F5B60353591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Pick your complexity: multiple simple identifiers, one for each need, = where the complexity comes from knowing which to implement for which = applications, or one (slightly) more complex identifier that can address = multiple needs.=20 Colin > On 5 Feb 2016, at 00:14, Peter Thatcher wrote: >=20 > I want to be able to pick one ID and put that one ID in the RTP = packets and the SDP and be done. If we define optional additional IDs = and flexibility on top of that, I'm not opposed to that, but I want the = common use case to be simple: pick one ID, send one ID, and leave the = other things optional (or non-existent). It's not worth complicating = the main use case for other, theoretical uses. >=20 > On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins > wrote: >=20 >> On 4 Feb 2016, at 22:57, Adam Roach > wrote: >>=20 >> I don't have a strong opinion one way or another here. At this point, = I hear one voice for keeping as-is, and another for giving redundancy = streams their own RID (or RIDs? I don't understand the suggestion that = we use a list of RIDs). >=20 > Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying = to do two things: provide a unique identifier for an RTP stream, and = provide an identifier which can connect a redundancy RTP stream and the = RTP stream it is protecting. I was suggesting that these functions = should be kept separate. Each stream, whether original or redundancy, = could optionally have a RID assigned to it. The original and redundant = streams would have different RIDs. Each stream that has a RID assigned = to it could also (optionally) include a list of other RID values that = it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, these other = RID values could be the stream(s) that it=E2=80=99s protecting; if = it=E2=80=99s a simulcast stream, they could be the other versions; if = it=E2=80=99s a layered stream, they could be the other layers, etc. Each = stream therefore has a unique identifier, and relationships between them = are explicit rather than implicit.=20 >=20 > (We can argue later about whether this is one SDES item with two parts = to it, or two SDES items; the syntax isn=E2=80=99t the important part)=20= >=20 > Yes, this has slightly higher overhead (although if you care about = overhead that much, you probably want to rethink sending a redundant = video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex = in some ways; but it=E2=80=99s simpler in that each stream has a unique = identifier that can unambiguously refer to it, whether from another RTP = stream or from the signalling channel, so we won=E2=80=99t have to = define yet another identifier if we later find a requirement to refer to = original and redundant streams independently.=20 >=20 > Colin >=20 >=20 >=20 >> Does anyone else want to weigh in? >>=20 >> /a >>=20 >> On 2/2/16 13:41, Peter Thatcher wrote: >>>=20 >>>=20 >>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins > wrote: >>>=20 >>> > On 2 Feb 2016, at 18:45, Peter Thatcher < = pthatcher@google.com = > wrote: >>> > >>> > >>> > >>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < = csp@csperkins.org > = wrote: >>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < = jonathan@vidyo.com = > wrote: >>> > > >>> > > Hello, AVTEXT =E2=80=94 >>> > > >>> > > As discussed in Yokohama, Adam Roach et al have submitted a = draft on a =E2=80=9CRID=E2=80=9D SDES item and header extension for = identifying encoded and dependent streams. >>> > > >>> > > This is a call to see whether the AVTEXT working group wants to = take on this work as a work item (both adding a milestone for the work = and adopting the existing draft as the starting point for a working = group document). >>> > > >>> > > Please comment on the AVTEXT mailing list in the next two weeks = (by February 15, 2016). >>> > >>> > I don=E2=80=99t object to adopting this draft as a working group = item. >>> > >>> > However, I do think the working group should carefully review the = semantics of the RID before this is published as an RFC. The complaint = in the Introduction that none of the previous attempts to address this = problem =E2=80=9Chave the proper ordinality to refer to an individual = stream; all such identifiers can appear in more than one stream at a = time=E2=80=9D doesn=E2=80=99t align with the later requirements that = main and redundancy RTP streams have the same RID. >>> > >>> > >>> > =E2=80=8BPerhaps the introduction could be more precise by saying = "have the proper ordinality to refer to an individual source RTP stream; = all such identifiers can appear in more than one source RTP stream"=E2=80=8B= >>> > >>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP = stream to indicate which source RTP stream they are redundant with (or = repair, or refer to, or whatever you want to call it). It doesn=E2=80=99= t matter how many redundancy RTP streams there are per = RID, as long as there is only one source RTP stream. >>>=20 >>> Perhaps, but on the principle that explicit is better than implicit, = another design might be for each stream, source or redundancy, to have a = unique RID, and for redundancy streams to include a list of RID values = that they provide redundancy for. That way, there is no scope for = confusion between source and redundancy streams. >>>=20 >>> =E2=80=8BWhen does a redundancy stream apply to more than one source = RTP stream? Flexfec is the only case I can think of, and that already = provides all of the necessary info in the payload, so there's no need = for a header extension. =20 >>>=20 >>> =E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide? Would anything ever refer to it? If not, let's just not = include it (it just wastes bytes). >>>=20 >>> So let's start with your idea, remove the IDs of the redundancy RTP = streams (since no one refers to them, they have no value, and just waste = bytes). We'll also reduce the list to a single value (since only = flexfec would have a list, and flexfec doesn't need the header = extension). What are we left with? An ID in the source RTP stream, and = a reference to that ID in the redundancy RTP streams. That sounds good = to me, but we've just gone and re-invented RID. >>>=20 >>> So it sounds like what you're really asking for is multiple RIDs in = the redundancy RTP streams. But I don't really see a use case for that, = and on the principle of simple is better than complex, I'd prefer a = single value in the redundancy RTP streams. >>>=20 >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext = >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_B7ACE5F9-F3AB-450E-B05E-8F5B60353591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Pick your complexity: multiple simple identifiers, one for = each need, where the complexity comes from knowing which to implement = for which applications, or one (slightly) more complex identifier that = can address multiple needs. 

Colin




On = 5 Feb 2016, at 00:14, Peter Thatcher <pthatcher@google.com> wrote:

I want to be able to = pick one ID and put that one ID in the RTP packets and the SDP and be = done.  If we define optional additional IDs and flexibility on top = of that, I'm not opposed to that, but I want the common use case to be = simple: pick one ID, send one ID, and leave the other things optional = (or non-existent).  It's not worth complicating the main use case = for other, theoretical uses.

On Thu, = Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Perhaps I = didn=E2=80=99t explain myself well. The RID draft is trying to do two = things: provide a unique identifier for an RTP stream, and provide an = identifier which can connect a redundancy RTP stream and the RTP stream = it is protecting. I was suggesting that these functions should be kept = separate. Each stream, whether original or redundancy, could optionally = have a RID assigned to it. The original and redundant streams would have = different RIDs. Each stream that has a RID assigned to it could also = (optionally) include a list of other RID values that it=E2=80=99s = associated with. If it=E2=80=99s a FEC stream, these other RID values = could be the stream(s) that it=E2=80=99s protecting; if it=E2=80=99s a = simulcast stream, they could be the other versions; if it=E2=80=99s a = layered stream, they could be the other layers, etc. Each stream = therefore has a unique identifier, and relationships between them are = explicit rather than implicit. 

(We can argue later about whether this = is one SDES item with two parts to it, or two SDES items; the syntax = isn=E2=80=99t the important part) 

Yes, this has slightly higher overhead = (although if you care about overhead that much, you probably want to = rethink sending a redundant video stream=E2=80=A6). Yes, it=E2=80=99s = perhaps slightly more complex in some ways; but it=E2=80=99s simpler in = that each stream has a unique identifier that can unambiguously refer to = it, whether from another RTP stream or from the signalling channel, so = we won=E2=80=99t have to define yet another identifier if we later find = a requirement to refer to original and redundant streams = independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and = header extension for identifying encoded and dependent = streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group = document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a = working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an = individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the = later requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more = precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. = =E2=80=8B=E2=80=8B  =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn=E2=80=99t matter = how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think = of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

=E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide?  Would anything ever refer to it?  If not, let's = just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce = the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header = extension).  What are we left with?  An ID in the source RTP = stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just = gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




-- 
Colin Perkins
https://csperkins.org/








-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_B7ACE5F9-F3AB-450E-B05E-8F5B60353591-- From nobody Thu Feb 4 16:33:46 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDB71B2A9F for ; Thu, 4 Feb 2016 16:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 SXxgA3qUAfJE for ; Thu, 4 Feb 2016 16:33:42 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 A91381B2A9E for ; Thu, 4 Feb 2016 16:33:42 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id w5so31802509oie.1 for ; Thu, 04 Feb 2016 16:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aajhONyz3NWlYk1R3G3fQtsuI09krpJsSighdI+1Wb0=; b=OMEOFFjPP+F4LreNMVtnRJ6DC2h7cBCKTdAl5H/e6jQW4dYFBbq7ULYL3kbktQHCMa wv/mgVPOxNIHGyeJ+SoZCmfIeX+J9jTU6t+HoUrLf8nVVA/SIjLk0ZQ3nXte3DKKTfHG ghyXGdBodKK8KAd5A8rEzZmDLUrp5T8WxHvdTIJLcC/NzsHW0hpFUugBlB07zLggkLSq oybqOaVQuU4dKzUDG7DMtobhaYfMG/xqD4s61O+tGyOYDH3lEL/8rR1oY8L2k/PcKqoX UEZF6S0F9ytoTT51+B4PryfpYZ8RJLa7YMaUzIgbdz0bIB0SNRstxILtyGvLdriZZCLj BSYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aajhONyz3NWlYk1R3G3fQtsuI09krpJsSighdI+1Wb0=; b=lqOJCBrJ+LOIVQwyASzW4eg5i98vNrLZX6xe5/ZZpqdx8inJI+tScMWIC6py5jMHcH I6qKH1/3CAy+i82Rdar+6N3+JJsEBi4hF0IWbg3BG7EypMxmzHQFBCJamdtESFV/bi2P j3fx44coe/HzS13dQ0fEbGjXvRjr9MynxKwDCrwH3kO3sZCCcB/kKyk4e8lQ8h66sMDm vAP49e2MkMEVuriacLUBHX50wivJGHmgvFb6UqoZAVcjWvcy2u2CrR9PggRCJTpNFUas bVsjIB0KiRE9fu821c3030afTdUkAcgGmqa+2+yt/y4GPsyQqjqCUUOByIw2BNJxPyWn LBuw== X-Gm-Message-State: AG10YOTslYYEEOF1HUxd3gEutJZdXw/IXn293ooPUW7wdZHVAh1qIoLSiFrNVUMaQdSyKNgygNvvCKEzlVSM1W6y X-Received: by 10.202.217.67 with SMTP id q64mr5959701oig.58.1454632421845; Thu, 04 Feb 2016 16:33:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 16:33:02 -0800 (PST) In-Reply-To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> From: Peter Thatcher Date: Thu, 4 Feb 2016 16:33:02 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a113cf48cc8b692052afb0055 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:33:45 -0000 --001a113cf48cc8b692052afb0055 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That sounds to me like "solve the problem we know in a simple way" or "solve the problem we know and maybe other problems we can't think of yet with a more complex way". I'll go with the simple solution to the known problem. The implications of multiple IDs don't just affect the complexity of the header extension or the SDP. They also affect how the WebRTC API that will ultimately use these. And so changes to this here and now will ripple there way through more discussions and designs and edge cases to figure out in other groups. So the "slightly" on the more complex part can grow pretty quickly. On Thu, Feb 4, 2016 at 4:26 PM, Colin Perkins wrote: > Pick your complexity: multiple simple identifiers, one for each need, > where the complexity comes from knowing which to implement for which > applications, or one (slightly) more complex identifier that can address > multiple needs. > > Colin > > > > > > On 5 Feb 2016, at 00:14, Peter Thatcher wrote: > > I want to be able to pick one ID and put that one ID in the RTP packets > and the SDP and be done. If we define optional additional IDs and > flexibility on top of that, I'm not opposed to that, but I want the commo= n > use case to be simple: pick one ID, send one ID, and leave the other thin= gs > optional (or non-existent). It's not worth complicating the main use cas= e > for other, theoretical uses. > > On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: > >> >> On 4 Feb 2016, at 22:57, Adam Roach wrote: >> >> I don't have a strong opinion one way or another here. At this point, I >> hear one voice for keeping as-is, and another for giving redundancy stre= ams >> their own RID (or RIDs? I don't understand the suggestion that we use a >> list of RIDs). >> >> >> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to= do two >> things: provide a unique identifier for an RTP stream, and provide an >> identifier which can connect a redundancy RTP stream and the RTP stream = it >> is protecting. I was suggesting that these functions should be kept >> separate. Each stream, whether original or redundancy, could optionally >> have a RID assigned to it. The original and redundant streams would have >> different RIDs. Each stream that has a RID assigned to it could also >> (optionally) include a list of other RID values that it=E2=80=99s associ= ated with. >> If it=E2=80=99s a FEC stream, these other RID values could be the stream= (s) that >> it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could = be the other >> versions; if it=E2=80=99s a layered stream, they could be the other laye= rs, etc. >> Each stream therefore has a unique identifier, and relationships between >> them are explicit rather than implicit. >> >> (We can argue later about whether this is one SDES item with two parts t= o >> it, or two SDES items; the syntax isn=E2=80=99t the important part) >> >> Yes, this has slightly higher overhead (although if you care about >> overhead that much, you probably want to rethink sending a redundant vid= eo >> stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in som= e ways; but it=E2=80=99s >> simpler in that each stream has a unique identifier that can unambiguous= ly >> refer to it, whether from another RTP stream or from the signalling >> channel, so we won=E2=80=99t have to define yet another identifier if we= later find >> a requirement to refer to original and redundant streams independently. >> >> Colin >> >> >> >> Does anyone else want to weigh in? >> >> /a >> >> On 2/2/16 13:41, Peter Thatcher wrote: >> >> >> >> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote= : >> >>> >>> > On 2 Feb 2016, at 18:45, Peter Thatcher < >>> pthatcher@google.com> wrote: >>> > >>> > >>> > >>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >>> csp@csperkins.org> wrote: >>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >>> jonathan@vidyo.com> wrote: >>> > > >>> > > Hello, AVTEXT =E2=80=94 >>> > > >>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft o= n >>> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and >>> dependent streams. >>> > > >>> > > This is a call to see whether the AVTEXT working group wants to tak= e >>> on this work as a work item (both adding a milestone for the work and >>> adopting the existing draft as the starting point for a working group >>> document). >>> > > >>> > > Please comment on the AVTEXT mailing list in the next two weeks (by >>> February 15, 2016). >>> > >>> > I don=E2=80=99t object to adopting this draft as a working group item= . >>> > >>> > However, I do think the working group should carefully review the >>> semantics of the RID before this is published as an RFC. The complaint = in >>> the Introduction that none of the previous attempts to address this pro= blem >>> =E2=80=9Chave the proper ordinality to refer to an individual stream; a= ll such >>> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >>> with the later requirements that main and redundancy RTP streams have t= he >>> same RID. >>> > >>> > >>> > =E2=80=8BPerhaps the introduction could be more precise by saying "ha= ve the >>> proper ordinality to refer to an individual source RTP stream; all such >>> identifiers can appear in more than one source RTP stream"=E2=80=8B >>> > >>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >>> streams have the same RID as the source RTP stream to indicate which so= urce >>> RTP stream they are redundant with (or repair, or refer to, or whatever= you >>> want to call it). It doesn=E2=80=99t matter how many redundancy RTP s= treams there >>> are per RID, as long as there is only one source RTP stream. >>> >>> Perhaps, but on the principle that explicit is better than implicit, >>> another design might be for each stream, source or redundancy, to have = a >>> unique RID, and for redundancy streams to include a list of RID values = that >>> they provide redundancy for. That way, there is no scope for confusion >>> between source and redundancy streams. >>> >> >> =E2=80=8BWhen does a redundancy stream apply to more than one source RTP= stream? >> Flexfec is the only case I can think of, and that already provides all o= f >> the necessary info in the payload, so there's no need for a header >> extension. >> >> =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? = Would >> anything ever refer to it? If not, let's just not include it (it just >> wastes bytes). >> >> So let's start with your idea, remove the IDs of the redundancy RTP >> streams (since no one refers to them, they have no value, and just waste >> bytes). We'll also reduce the list to a single value (since only flexfe= c >> would have a list, and flexfec doesn't need the header extension). What >> are we left with? An ID in the source RTP stream, and a reference to th= at >> ID in the redundancy RTP streams. That sounds good to me, but we've jus= t >> gone and re-invented RID. >> >> So it sounds like what you're really asking for is multiple RIDs in the >> redundancy RTP streams. But I don't really see a use case for that, and = on >> the principle of simple is better than complex, I'd prefer a single valu= e >> in the redundancy RTP streams. >> >> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/= avtext >> >> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a113cf48cc8b692052afb0055 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That sounds to me like "solve the problem we know = in a simple way" or "solve the problem we know and maybe other pr= oblems we can't think of yet with a more complex way".
I'll go with the simple solution to the known problem.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">
The implications of multiple IDs don't just affect the c= omplexity of the header extension or the SDP.=C2=A0 They also affect how th= e WebRTC API that will ultimately use these.=C2=A0 And so changes to this h= ere and now will ripple there way through more discussions and designs and = edge cases to figure out in other groups.=C2=A0 So the "slightly"= on the more complex part can grow pretty quickly.



On Thu= , Feb 4, 2016 at 4:26 PM, Colin Perkins <csp@csperkins.org> = wrote:
Pick your complexity: multiple simple identifiers, one for each need, whe= re the complexity comes from knowing which to implement for which applicati= ons, or one (slightly) more complex identifier that can address multiple ne= eds.=C2=A0

Co= lin





On 5 Feb 20= 16, at 00:14, Peter Thatcher <pthatcher@google.com> wrote:

I want to be= able to pick one ID and put that one ID in the RTP packets and the SDP and= be done.=C2=A0 If we define optional additional IDs and flexibility on top= of that, I'm not opposed to that, but I want the common use case to be= simple: pick one ID, send one ID, and leave the other things optional (or = non-existent).=C2=A0 It's not worth complicating the main use case for = other, theoretical uses.

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@= csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

P= erhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do = two things: provide a unique identifier for an RTP stream, and provide an i= dentifier which can connect a redundancy RTP stream and the RTP stream it i= s protecting. I was suggesting that these functions should be kept separate= . Each stream, whether original or redundancy, could optionally have a RID = assigned to it. The original and redundant streams would have different RID= s. Each stream that has a RID assigned to it could also (optionally) includ= e a list of other RID values that it=E2=80=99s associated with. If it=E2=80= =99s a FEC stream, these other RID values could be the stream(s) that it=E2= =80=99s protecting; if it=E2=80=99s a simulcast stream, they could be the o= ther versions; if it=E2=80=99s a layered stream, they could be the other la= yers, etc. Each stream therefore has a unique identifier, and relationships= between them are explicit rather than implicit.=C2=A0

=
(We can argue later about whether this is one SDES item with two parts= to it, or two SDES items; the syntax isn=E2=80=99t the important part)=C2= =A0

Yes, this has slightly higher overhead (althou= gh if you care about overhead that much, you probably want to rethink sendi= ng a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly m= ore complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from anothe= r RTP stream or from the signalling channel, so we won=E2=80=99t have to de= fine yet another identifier if we later find a requirement to refer to orig= inal and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80= =8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80= =8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let&= #39;s start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext


<= span style=3D"font-size:9px">


--=C2=A0





--=C2=A0
Colin Perkins





= --001a113cf48cc8b692052afb0055-- From nobody Thu Feb 4 17:35:40 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0EC1B2C34 for ; Thu, 4 Feb 2016 17:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham 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 mn_6SIKSiKE2 for ; Thu, 4 Feb 2016 17:35:35 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F261B2C37 for ; Thu, 4 Feb 2016 17:35:35 -0800 (PST) Received: from [81.187.2.149] (port=45541 helo=[192.168.0.74]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRVJ5-0001zX-AJ; Fri, 05 Feb 2016 01:35:33 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-86C54FB4-695D-40B7-9EBB-4FA904209D68 Mime-Version: 1.0 (1.0) From: Colin Perkins X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Fri, 5 Feb 2016 01:35:27 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6AB8A27D-8DC6-4B3B-8FD5-12867B7A202E@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> To: Peter Thatcher X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 01:35:39 -0000 --Apple-Mail-86C54FB4-695D-40B7-9EBB-4FA904209D68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree, of course: if we give each stream a unique RID, and explicitly link= them, that introduces some complexity in SDP and the WebRTC API that we'd n= eed to resolve.=20 But, so does the proposal to define RID exactly as you need it today, withou= t thought for extension. Any change in requirements, perhaps to distinguish o= riginal and redundant streams, to label streams for a different reason, or t= o associate streams in a different way, then requires another identifier to b= e introduced. And that new identifier then has to be added to SDP, exposed v= ia the WebRTC API, have its edge cases and interactions with other mechanism= s defined, and so on. There's complexity here too, and I'd argue worse compl= exity, since =E2=80=93 unless we really think WebRTC will never need any fut= ure extensions in this area =E2=80=93 we'd end up with an ad-hoc and non-ort= hogonal set of features to combine.=20 --=20 Colin Perkins http://csperkins.org/ > On 5 Feb 2016, at 00:33, Peter Thatcher wrote: >=20 > That sounds to me like "solve the problem we know in a simple way" or "sol= ve the problem we know and maybe other problems we can't think of yet with a= more complex way". >=20 > I'll go with the simple solution to the known problem. >=20 > The implications of multiple IDs don't just affect the complexity of the h= eader extension or the SDP. They also affect how the WebRTC API that will u= ltimately use these. And so changes to this here and now will ripple there w= ay through more discussions and designs and edge cases to figure out in othe= r groups. So the "slightly" on the more complex part can grow pretty quickl= y. >=20 >=20 >=20 >> On Thu, Feb 4, 2016 at 4:26 PM, Colin Perkins wrote: >> Pick your complexity: multiple simple identifiers, one for each need, whe= re the complexity comes from knowing which to implement for which applicatio= ns, or one (slightly) more complex identifier that can address multiple need= s.=20 >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 5 Feb 2016, at 00:14, Peter Thatcher wrote: >>>=20 >>> I want to be able to pick one ID and put that one ID in the RTP packets a= nd the SDP and be done. If we define optional additional IDs and flexibilit= y on top of that, I'm not opposed to that, but I want the common use case to= be simple: pick one ID, send one ID, and leave the other things optional (o= r non-existent). It's not worth complicating the main use case for other, t= heoretical uses. >>>=20 >>>> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote= : >>>>=20 >>>>> On 4 Feb 2016, at 22:57, Adam Roach wrote: >>>>>=20 >>>>> I don't have a strong opinion one way or another here. At this point, I= hear one voice for keeping as-is, and another for giving redundancy streams= their own RID (or RIDs? I don't understand the suggestion that we use a lis= t of RIDs). >>>>=20 >>>> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying t= o do two things: provide a unique identifier for an RTP stream, and provide a= n identifier which can connect a redundancy RTP stream and the RTP stream it= is protecting. I was suggesting that these functions should be kept separat= e. Each stream, whether original or redundancy, could optionally have a RID a= ssigned to it. The original and redundant streams would have different RIDs.= Each stream that has a RID assigned to it could also (optionally) include a= list of other RID values that it=E2=80=99s associated with. If it=E2=80=99s= a FEC stream, these other RID values could be the stream(s) that it=E2=80=99= s protecting; if it=E2=80=99s a simulcast stream, they could be the other ve= rsions; if it=E2=80=99s a layered stream, they could be the other layers, et= c. Each stream therefore has a unique identifier, and relationships between t= hem are explicit rather than implicit.=20 >>>>=20 >>>> (We can argue later about whether this is one SDES item with two parts t= o it, or two SDES items; the syntax isn=E2=80=99t the important part)=20 >>>>=20 >>>> Yes, this has slightly higher overhead (although if you care about over= head that much, you probably want to rethink sending a redundant video strea= m=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in some ways; b= ut it=E2=80=99s simpler in that each stream has a unique identifier that can= unambiguously refer to it, whether from another RTP stream or from the sign= alling channel, so we won=E2=80=99t have to define yet another identifier if= we later find a requirement to refer to original and redundant streams inde= pendently.=20 >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>>> Does anyone else want to weigh in? >>>>>=20 >>>>> /a >>>>>=20 >>>>>> On 2/2/16 13:41, Peter Thatcher wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins w= rote: >>>>>>>=20 >>>>>>> > On 2 Feb 2016, at 18:45, Peter Thatcher wro= te: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins w= rote: >>>>>>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox wr= ote: >>>>>>> > > >>>>>>> > > Hello, AVTEXT =E2=80=94 >>>>>>> > > >>>>>>> > > As discussed in Yokohama, Adam Roach et al have submitted a draf= t on a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying e= ncoded and dependent streams. >>>>>>> > > >>>>>>> > > This is a call to see whether the AVTEXT working group wants to t= ake on this work as a work item (both adding a milestone for the work and ad= opting the existing draft as the starting point for a working group document= ). >>>>>>> > > >>>>>>> > > Please comment on the AVTEXT mailing list in the next two weeks (= by February 15, 2016). >>>>>>> > >>>>>>> > I don=E2=80=99t object to adopting this draft as a working group i= tem. >>>>>>> > >>>>>>> > However, I do think the working group should carefully review the s= emantics of the RID before this is published as an RFC. The complaint in the= Introduction that none of the previous attempts to address this problem =E2= =80=9Chave the proper ordinality to refer to an individual stream; all such i= dentifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80= =99t align with the later requirements that main and redundancy RTP streams h= ave the same RID. >>>>>>> > >>>>>>> > >>>>>>> > =E2=80=8BPerhaps the introduction could be more precise by saying "= have the proper ordinality to refer to an individual source RTP stream; all s= uch identifiers can appear in more than one source RTP stream"=E2=80=8B >>>>>>> > >>>>>>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B= =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP st= ream to indicate which source RTP stream they are redundant with (or repair,= or refer to, or whatever you want to call it). It doesn=E2=80=99t matter h= ow many redundancy RTP streams there are per RID, as long as there is only o= ne source RTP stream. >>>>>>>=20 >>>>>>> Perhaps, but on the principle that explicit is better than implicit,= another design might be for each stream, source or redundancy, to have a un= ique RID, and for redundancy streams to include a list of RID values that th= ey provide redundancy for. That way, there is no scope for confusion between= source and redundancy streams. >>>>>>=20 >>>>>> =E2=80=8BWhen does a redundancy stream apply to more than one source R= TP stream? Flexfec is the only case I can think of, and that already provid= es all of the necessary info in the payload, so there's no need for a header= extension. =20 >>>>>>=20 >>>>>> =E2=80=8BAnd what value would an ID of a redundancy RTP stream provid= e? Would anything ever refer to it? If not, let's just not include it (it j= ust wastes bytes). >>>>>>=20 >>>>>> So let's start with your idea, remove the IDs of the redundancy RTP s= treams (since no one refers to them, they have no value, and just waste byte= s). We'll also reduce the list to a single value (since only flexfec would h= ave a list, and flexfec doesn't need the header extension). What are we lef= t with? An ID in the source RTP stream, and a reference to that ID in the r= edundancy RTP streams. That sounds good to me, but we've just gone and re-i= nvented RID. >>>>>>=20 >>>>>> So it sounds like what you're really asking for is multiple RIDs in t= he redundancy RTP streams. But I don't really see a use case for that, and o= n the principle of simple is better than complex, I'd prefer a single value i= n the redundancy RTP streams. >>>>>>=20 >>>>>>> -- >>>>>>> Colin Perkins >>>>>>> https://csperkins.org/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> avtext mailing list >>>>>> avtext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Colin Perkins >>>> https://csperkins.org/ >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >=20 --Apple-Mail-86C54FB4-695D-40B7-9EBB-4FA904209D68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree, of course: if we give each st= ream a unique RID, and explicitly link them, that introduces some complexity= in SDP and the WebRTC API that we'd need to resolve. 

But, so does th= e proposal to define RID exactly as you need it today, without thought for e= xtension. Any change in requirements, perhaps to distinguish original and re= dundant streams, to label streams for a different reason, or to associate st= reams in a different way, then requires another identifier to be introduced.= And that new identifier then has to be added to SDP, exposed via the WebRTC= API, have its edge cases and interactions with other mechanisms defined, an= d so on. There's complexity here too, and I'd argue worse complexity, since =E2= =80=93 unless we really think WebRTC will never need any future extensions i= n this area =E2=80=93 we'd end up with an ad-hoc and non-orthogonal set of f= eatures to combine. 

-- 
Colin Perkins

On 5 Feb 2016, at 00:33, Peter Tha= tcher <pthatcher@google.com&g= t; wrote:

That= sounds to me like "solve the problem we know in a simple way" or "solve the= problem we know and maybe other problems we can't think of yet with a more c= omplex way".

I'll go with the simple solution to the know= n problem.

The implications of multiple IDs don't just af= fect the complexity of the header extension or the SDP.  They also affe= ct how the WebRTC API that will ultimately use these.  And so changes t= o this here and now will ripple there way through more discussions and desig= ns and edge cases to figure out in other groups.  So the "slightly" on t= he more complex part can grow pretty quickly.



On Thu, Feb 4, 2= 016 at 4:26 PM, Colin Perkins <csp@csperkins.org> wrote:
Pick your co= mplexity: multiple simple identifiers, one for each need, where the complexi= ty comes from knowing which to implement for which applications, or one (sli= ghtly) more complex identifier that can address multiple needs. 

Colin




<= div>
On 5 Feb 2016, at 00:14, Peter T= hatcher <pthatc= her@google.com> wrote:

I want to be able to pick one ID and p= ut that one ID in the RTP packets and the SDP and be done.  If we defin= e optional additional IDs and flexibility on top of that, I'm not opposed to= that, but I want the common use case to be simple: pick one ID, send one ID= , and leave the other things optional (or non-existent).  It's not wort= h complicating the main use case for other, theoretical uses.

On Thu, Feb 4, 20= 16 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> w= rote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Pe= rhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do tw= o things: provide a unique identifier for an RTP stream, and provide an iden= tifier which can connect a redundancy RTP stream and the RTP stream it is pr= otecting. I was suggesting that these functions should be kept separate. Eac= h stream, whether original or redundancy, could optionally have a RID assign= ed to it. The original and redundant streams would have different RIDs. Each= stream that has a RID assigned to it could also (optionally) include a list= of other RID values that it=E2=80=99s associated with. If it=E2=80=99s a FE= C stream, these other RID values could be the stream(s) that it=E2=80=99s pr= otecting; if it=E2=80=99s a simulcast stream, they could be the other versio= ns; if it=E2=80=99s a layered stream, they could be the other layers, etc. E= ach stream therefore has a unique identifier, and relationships between them= are explicit rather than implicit. 

(We can a= rgue later about whether this is one SDES item with two parts to it, or two S= DES items; the syntax isn=E2=80=99t the important part) 

=
Yes, this has slightly higher overhead (although if you care abou= t overhead that much, you probably want to rethink sending a redundant video= stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in some w= ays; but it=E2=80=99s simpler in that each stream has a unique identifier th= at can unambiguously refer to it, whether from another RTP stream or from th= e signalling channel, so we won=E2=80=99t have to define yet another identif= ier if we later find a requirement to refer to original and redundant stream= s independently. 

Col= in



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and hea= der extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
= > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a workin= g group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the later= requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise b= y saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B= =E2=80=8B  =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn=E2=80=99t matter how ma= ny redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8B= When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

=E2=80=8B= And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just no= t include it (it just wastes bytes).

So let's= start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream,= and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/avtext




-- 
Colin P= erkins








-- 
=
Colin Perkins




<= /div> = --Apple-Mail-86C54FB4-695D-40B7-9EBB-4FA904209D68-- From nobody Thu Feb 4 17:48:50 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8AC1B2C71 for ; Thu, 4 Feb 2016 17:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 M11q6QyI3ugC for ; Thu, 4 Feb 2016 17:48:44 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 CE7391B2C6E for ; Thu, 4 Feb 2016 17:48:43 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id w5so32667538oie.1 for ; Thu, 04 Feb 2016 17:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wQOdw5rXGjJ/jSndpxfCpAzpBlGBgFZQNzo5177vXAI=; b=jRlcL5pjrZ77sOcTdOpvMshPp//c2vbi4uVE65+Tkt77konwqDHw7oBOUHteu9sC6x hBrIbMqoUFngT7xsjmdlt7lI94Qt4e0N7h3/GmM0QFGNoMB94rxHehoOyLUsB+wupEHk Vj10EOTM4ZpVhGzlHnvk8OcHlkx1qfoytY8vj5z0xdHb5kjFAlODI/Im/Eu9kCrLC84G yP4E4xBQTuaHpiJxZlgotRI3576XcdTVK7A+DdcyYb3BqadXGAq14v/BGlcl8KUa3gMY L4csEmDXSXmdbPXNm3jL+c05cxceFcRZcDUK8BpAMwT3GCXR8Hkunage3rCvCZEMzIg0 q6Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wQOdw5rXGjJ/jSndpxfCpAzpBlGBgFZQNzo5177vXAI=; b=IxdDSW+1pp5n3VBkJQeCK6m3SYqVAR/tHXaGLz02+x9iZDEVil6xGU6S2zEp9u8gz8 GnpXba2xlzaA4bFofSrUM71A1cQnJTui/A7q1uqq2I2jbtZOn0L4Z9exnVgPDCPtcu3T kyzp89JtM//qjapTRCG+OP9uyZ7flgYFrrAwLcM8Fc281bOB3OCpLOSQm74cSAFPEvga OgD78sf/mhbTSy4BKRjvFCETRx1mHLyirH2q+4+EmxI+n0L2G1mpYVGV+EiGOF0ADQTT iLCs0BfoHRDvMuj7GiQwPeETChRLaBeTXATmfHgNbpz0NsMAiT0MiBCKJB9+f0gvi51S 8ZzA== X-Gm-Message-State: AG10YORXOwrc/gUgX/O8YKgHSArWE1+UaxXNeOT/7B/HLEwEhsakGzQZUmWmnb8wSmhvDDl0JjRf11VWwYXfwGw/ X-Received: by 10.202.2.8 with SMTP id 8mr5621208oic.60.1454636923115; Thu, 04 Feb 2016 17:48:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 17:48:03 -0800 (PST) In-Reply-To: <6AB8A27D-8DC6-4B3B-8FD5-12867B7A202E@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <6AB8A27D-8DC6-4B3B-8FD5-12867B7A202E@csperkins.org> From: Peter Thatcher Date: Thu, 4 Feb 2016 17:48:03 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a1137a378149d1e052afc0d29 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 01:48:47 -0000 --001a1137a378149d1e052afc0d29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Again, you're arguing to make a simple solution for a known problem into a complex solution for a theoretical problem. Let's not over-engineer this. On Thu, Feb 4, 2016 at 5:35 PM, Colin Perkins wrote: > I agree, of course: if we give each stream a unique RID, and explicitly > link them, that introduces some complexity in SDP and the WebRTC API that > we'd need to resolve. > > But, so does the proposal to define RID exactly as you need it today, > without thought for extension. Any change in requirements, perhaps to > distinguish original and redundant streams, to label streams for a > different reason, or to associate streams in a different way, then requir= es > another identifier to be introduced. And that new identifier then has to = be > added to SDP, exposed via the WebRTC API, have its edge cases and > interactions with other mechanisms defined, and so on. There's complexity > here too, and I'd argue worse complexity, since =E2=80=93 unless we reall= y think > WebRTC will never need any future extensions in this area =E2=80=93 we'd = end up > with an ad-hoc and non-orthogonal set of features to combine. > > -- > Colin Perkins > http://csperkins.org/ > > On 5 Feb 2016, at 00:33, Peter Thatcher wrote: > > That sounds to me like "solve the problem we know in a simple way" or > "solve the problem we know and maybe other problems we can't think of yet > with a more complex way". > > I'll go with the simple solution to the known problem. > > The implications of multiple IDs don't just affect the complexity of the > header extension or the SDP. They also affect how the WebRTC API that wi= ll > ultimately use these. And so changes to this here and now will ripple > there way through more discussions and designs and edge cases to figure o= ut > in other groups. So the "slightly" on the more complex part can grow > pretty quickly. > > > > On Thu, Feb 4, 2016 at 4:26 PM, Colin Perkins wrote: > >> Pick your complexity: multiple simple identifiers, one for each need, >> where the complexity comes from knowing which to implement for which >> applications, or one (slightly) more complex identifier that can address >> multiple needs. >> >> Colin >> >> >> >> >> >> On 5 Feb 2016, at 00:14, Peter Thatcher wrote: >> >> I want to be able to pick one ID and put that one ID in the RTP packets >> and the SDP and be done. If we define optional additional IDs and >> flexibility on top of that, I'm not opposed to that, but I want the comm= on >> use case to be simple: pick one ID, send one ID, and leave the other thi= ngs >> optional (or non-existent). It's not worth complicating the main use ca= se >> for other, theoretical uses. >> >> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: >> >>> >>> On 4 Feb 2016, at 22:57, Adam Roach wrote: >>> >>> I don't have a strong opinion one way or another here. At this point, I >>> hear one voice for keeping as-is, and another for giving redundancy str= eams >>> their own RID (or RIDs? I don't understand the suggestion that we use a >>> list of RIDs). >>> >>> >>> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying t= o do two >>> things: provide a unique identifier for an RTP stream, and provide an >>> identifier which can connect a redundancy RTP stream and the RTP stream= it >>> is protecting. I was suggesting that these functions should be kept >>> separate. Each stream, whether original or redundancy, could optionally >>> have a RID assigned to it. The original and redundant streams would hav= e >>> different RIDs. Each stream that has a RID assigned to it could also >>> (optionally) include a list of other RID values that it=E2=80=99s assoc= iated with. >>> If it=E2=80=99s a FEC stream, these other RID values could be the strea= m(s) that >>> it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could= be the other >>> versions; if it=E2=80=99s a layered stream, they could be the other lay= ers, etc. >>> Each stream therefore has a unique identifier, and relationships betwee= n >>> them are explicit rather than implicit. >>> >>> (We can argue later about whether this is one SDES item with two parts >>> to it, or two SDES items; the syntax isn=E2=80=99t the important part) >>> >>> Yes, this has slightly higher overhead (although if you care about >>> overhead that much, you probably want to rethink sending a redundant vi= deo >>> stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in so= me ways; but it=E2=80=99s >>> simpler in that each stream has a unique identifier that can unambiguou= sly >>> refer to it, whether from another RTP stream or from the signalling >>> channel, so we won=E2=80=99t have to define yet another identifier if w= e later find >>> a requirement to refer to original and redundant streams independently. >>> >>> Colin >>> >>> >>> >>> Does anyone else want to weigh in? >>> >>> /a >>> >>> On 2/2/16 13:41, Peter Thatcher wrote: >>> >>> >>> >>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins >>> wrote: >>> >>>> >>>> > On 2 Feb 2016, at 18:45, Peter Thatcher < >>>> pthatcher@google.com> wrote: >>>> > >>>> > >>>> > >>>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >>>> csp@csperkins.org> wrote: >>>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >>>> jonathan@vidyo.com> wrote: >>>> > > >>>> > > Hello, AVTEXT =E2=80=94 >>>> > > >>>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft >>>> on a =E2=80=9CRID=E2=80=9D SDES item and header extension for identify= ing encoded and >>>> dependent streams. >>>> > > >>>> > > This is a call to see whether the AVTEXT working group wants to >>>> take on this work as a work item (both adding a milestone for the work= and >>>> adopting the existing draft as the starting point for a working group >>>> document). >>>> > > >>>> > > Please comment on the AVTEXT mailing list in the next two weeks (b= y >>>> February 15, 2016). >>>> > >>>> > I don=E2=80=99t object to adopting this draft as a working group ite= m. >>>> > >>>> > However, I do think the working group should carefully review the >>>> semantics of the RID before this is published as an RFC. The complaint= in >>>> the Introduction that none of the previous attempts to address this pr= oblem >>>> =E2=80=9Chave the proper ordinality to refer to an individual stream; = all such >>>> identifiers can appear in more than one stream at a time=E2=80=9D does= n=E2=80=99t align >>>> with the later requirements that main and redundancy RTP streams have = the >>>> same RID. >>>> > >>>> > >>>> > =E2=80=8BPerhaps the introduction could be more precise by saying "h= ave the >>>> proper ordinality to refer to an individual source RTP stream; all suc= h >>>> identifiers can appear in more than one source RTP stream"=E2=80=8B >>>> > >>>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >>>> streams have the same RID as the source RTP stream to indicate which s= ource >>>> RTP stream they are redundant with (or repair, or refer to, or whateve= r you >>>> want to call it). It doesn=E2=80=99t matter how many redundancy RTP = streams there >>>> are per RID, as long as there is only one source RTP stream. >>>> >>>> Perhaps, but on the principle that explicit is better than implicit, >>>> another design might be for each stream, source or redundancy, to have= a >>>> unique RID, and for redundancy streams to include a list of RID values= that >>>> they provide redundancy for. That way, there is no scope for confusion >>>> between source and redundancy streams. >>>> >>> >>> =E2=80=8BWhen does a redundancy stream apply to more than one source RT= P >>> stream? Flexfec is the only case I can think of, and that already prov= ides >>> all of the necessary info in the payload, so there's no need for a head= er >>> extension. >>> >>> =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide?= Would >>> anything ever refer to it? If not, let's just not include it (it just >>> wastes bytes). >>> >>> So let's start with your idea, remove the IDs of the redundancy RTP >>> streams (since no one refers to them, they have no value, and just wast= e >>> bytes). We'll also reduce the list to a single value (since only flexf= ec >>> would have a list, and flexfec doesn't need the header extension). Wha= t >>> are we left with? An ID in the source RTP stream, and a reference to t= hat >>> ID in the redundancy RTP streams. That sounds good to me, but we've ju= st >>> gone and re-invented RID. >>> >>> So it sounds like what you're really asking for is multiple RIDs in the >>> redundancy RTP streams. But I don't really see a use case for that, and= on >>> the principle of simple is better than complex, I'd prefer a single val= ue >>> in the redundancy RTP streams. >>> >>> -- >>>> Colin Perkins >>>> https://csperkins.org/ >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo= /avtext >>> >>> >>> >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > --001a1137a378149d1e052afc0d29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Again, you're arguing to make a simple solution for= a known problem into a complex solution for a theoretical problem. =C2=A0 = Let's not over-engineer this.



On Thu, Feb 4, 2016 at 5:= 35 PM, Colin Perkins <csp@csperkins.org> wrote:
I agree, of course: if we give= each stream a unique RID, and explicitly link them, that introduces some c= omplexity in SDP and the WebRTC API that we'd need to resolve.=C2=A0

But, so does the proposal to define RID exactly as y= ou need it today, without thought for extension. Any change in requirements= , perhaps to distinguish original and redundant streams, to label streams f= or a different reason, or to associate streams in a different way, then req= uires another identifier to be introduced. And that new identifier then has= to be added to SDP, exposed via the WebRTC API, have its edge cases and in= teractions with other mechanisms defined, and so on. There's complexity= here too, and I'd argue worse complexity, since =E2=80=93 unless we re= ally think WebRTC will never need any future extensions in this area =E2=80= =93 we'd end up with an ad-hoc and non-orthogonal set of features to co= mbine.=C2=A0
=
--=C2=A0
Colin Perkins
=

On 5 Feb 2016, at 00:33, Peter Thatcher <= ;pthatcher@google= .com> wrote:

That sounds to = me like "solve the problem we know in a simple way" or "solv= e the problem we know and maybe other problems we can't think of yet wi= th a more complex way".

I'll go with the simple solution to the known problem.

The implications of multiple IDs don'= t just affect the complexity of the header extension or the SDP.=C2=A0 They= also affect how the WebRTC API that will ultimately use these.=C2=A0 And s= o changes to this here and now will ripple there way through more discussio= ns and designs and edge cases to figure out in other groups.=C2=A0 So the &= quot;slightly" on the more complex part can grow pretty quickly.



On Thu, Feb 4, 2016 at 4:26 PM, Col= in Perkins <csp@csperkins.org> wrote:
Pick your complexity: mul= tiple simple identifiers, one for each need, where the complexity comes fro= m knowing which to implement for which applications, or one (slightly) more= complex identifier that can address multiple needs.=C2=A0

Colin



=


On 5 Feb = 2016, at 00:14, Peter Thatcher <pthatcher@google.com> wrote:

I want to b= e able to pick one ID and put that one ID in the RTP packets and the SDP an= d be done.=C2=A0 If we define optional additional IDs and flexibility on to= p of that, I'm not opposed to that, but I want the common use case to b= e simple: pick one ID, send one ID, and leave the other things optional (or= non-existent).=C2=A0 It's not worth complicating the main use case for= other, theoretical uses.

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp= @csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

P= erhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do = two things: provide a unique identifier for an RTP stream, and provide an i= dentifier which can connect a redundancy RTP stream and the RTP stream it i= s protecting. I was suggesting that these functions should be kept separate= . Each stream, whether original or redundancy, could optionally have a RID = assigned to it. The original and redundant streams would have different RID= s. Each stream that has a RID assigned to it could also (optionally) includ= e a list of other RID values that it=E2=80=99s associated with. If it=E2=80= =99s a FEC stream, these other RID values could be the stream(s) that it=E2= =80=99s protecting; if it=E2=80=99s a simulcast stream, they could be the o= ther versions; if it=E2=80=99s a layered stream, they could be the other la= yers, etc. Each stream therefore has a unique identifier, and relationships= between them are explicit rather than implicit.=C2=A0

=
(We can argue later about whether this is one SDES item with two parts= to it, or two SDES items; the syntax isn=E2=80=99t the important part)=C2= =A0

Yes, this has slightly higher overhead (althou= gh if you care about overhead that much, you probably want to rethink sendi= ng a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly m= ore complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from anothe= r RTP stream or from the signalling channel, so we won=E2=80=99t have to de= fine yet another identifier if we later find a requirement to refer to orig= inal and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80= =8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80= =8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let&= #39;s start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext


<= span style=3D"font-size:9px">


--=C2=A0





--=C2=A0
Colin Perkins





=

--001a1137a378149d1e052afc0d29-- From nobody Thu Feb 4 18:38:56 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B511B2D5E for ; Thu, 4 Feb 2016 18:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 xnS0HKnttdfU for ; Thu, 4 Feb 2016 18:38:52 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 6C9E51B2D5D for ; Thu, 4 Feb 2016 18:38:52 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id ba1so77832089obb.3 for ; Thu, 04 Feb 2016 18:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DjRWsPXHYArm7jX+hrQQg3QHeO1S84mLaQqUBr/fCDs=; b=muw8WhfNrgpZPo/sC5KPQ+fm2JAcykSDCaxdgHxrP1Q8L23kuGJNqo3GkX3wr18qu/ jBM6Z0eLNw28vo/+R2/cwrokE2xLqrNqxVjwP0a/cE86NmXBufT743bm++m46rDDqK/u Wcgu1YJpH8LQ+TqYGoYf8IPkZ+xuTMS+7mq9HOmu7Iz2is0ncybXpN9usAsadYjwU6v0 ZeSEEhccXnuSyeFgL//bbUHCR/OvbcP+Stqlrk3GGxSdXZK86C4Ht+fR7xoUmNMPnVBM tWOwJ7QqF3tEL//hXMg7fUFBSMASS03nJIN2O8yBy3W/R+brj0iV1AMcl3IPMkbGh5Yh SlSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DjRWsPXHYArm7jX+hrQQg3QHeO1S84mLaQqUBr/fCDs=; b=X2P69hYU+CvTVUNlc+CBwjvGUmV1Ua3nRZoqBF77kPJoBePMOOx+29NRILkwCDM29w jBWpV1CxIixTHn2HjiiMdmRrKWIo16kkgU3joh1t4vb/ejha0RydMAt3+JQtUDN9tjz4 ekcTlBQDphdSIskAmJh8IsfspN+xBIXS0oog8r9b5jhHePtagPoL2B6jKseaenD1xLMP Lgr3f5pb76qKdmJII7OUxblXDjLRvX7vZeA5C3JhYlJFAqBi1Pnu1M11SBBt23AqpaXx 1nirjrjZ/TU4FaftfOKs+Of+ALc6i1rlbzGmMPCWt0LzzB6KYb9dC8PUxWej3BUNJSsF xd7g== X-Gm-Message-State: AG10YOQpUQmxS/ZG3F/PPuoS6vBieyp7lyx/lp32S/mK/HY+qP/57nNr1f6ydO/hLEwo+noCyTKMBdJ0RIXu/8K9 X-Received: by 10.182.213.71 with SMTP id nq7mr10107095obc.65.1454639931544; Thu, 04 Feb 2016 18:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 18:38:12 -0800 (PST) In-Reply-To: <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> From: Peter Thatcher Date: Thu, 4 Feb 2016 18:38:12 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11c2d4e865a96e052afcc01f Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 02:38:56 -0000 --001a11c2d4e865a96e052afcc01f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, I'll try a little more detailed thought/design experiment. First, we're really talking about two different IDs, so let's give them different names for a moment to avoid confusion: SRID: source RTP stream ID: can only refer to a source RTP stream ID ARID: any RTP stream ID: can refer to any RTP stream ID Now let's compare how we could use them, with two options: Option A (current RID draft): The source RTP stream's packets contain an SRID, which identifies itself. The redundancy RTP stream's packets contain an SRID, which is the SRID of the source RTP stream that it protects. Option B (your idea as I understand it): The source RTP stream's packets contain an ARID, which identifies itself. The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects. Option C (another possibility mentioned in the thread, I think): The source RTP stream's packets contain an ARID, which identifies itself. The redundancy RTP stream's packets contain an ARID which identifies itself The ARID of the source and redundancy streams are tied together by signaling. I don't like Option C at all. It requires too much signaling and API complexity. However, let's go back to Option B. If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it: Option B2 (your idea, with the ARID optional on the redundancy stream): The source RTP stream's packets contain an ARID, which identifies itself. The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself) Now another question: what if you get an SRID in a source RTP stream? What does that mean? Well, it could only mean one thing: the ID refers to the source stream itself, which means it's functionally equivalent to an ARID on a source RTP stream. If this were allowed, we would end up with this option: Option B3 (your idea, with the ARID optional on the source and redundancy streams): The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself. The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself) Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything). The SDP/API implications for this would be to basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", and then given a name to ARID (probably just "rid"). Either that or leave "rid" to mean SRID and think of a new name for ARID. That would be a lot less work, but I can't think of a good name for the ARID. I don't think Option B3 is worth the additional complexity, since I don't think the ARID is worth having, but if the WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them. And Option C is right out. I hope that helps explain my thinking. On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: > > On 4 Feb 2016, at 22:57, Adam Roach wrote: > > I don't have a strong opinion one way or another here. At this point, I > hear one voice for keeping as-is, and another for giving redundancy strea= ms > their own RID (or RIDs? I don't understand the suggestion that we use a > list of RIDs). > > > Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to = do two > things: provide a unique identifier for an RTP stream, and provide an > identifier which can connect a redundancy RTP stream and the RTP stream i= t > is protecting. I was suggesting that these functions should be kept > separate. Each stream, whether original or redundancy, could optionally > have a RID assigned to it. The original and redundant streams would have > different RIDs. Each stream that has a RID assigned to it could also > (optionally) include a list of other RID values that it=E2=80=99s associa= ted with. > If it=E2=80=99s a FEC stream, these other RID values could be the stream(= s) that > it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could b= e the other > versions; if it=E2=80=99s a layered stream, they could be the other layer= s, etc. > Each stream therefore has a unique identifier, and relationships between > them are explicit rather than implicit. > > (We can argue later about whether this is one SDES item with two parts to > it, or two SDES items; the syntax isn=E2=80=99t the important part) > > Yes, this has slightly higher overhead (although if you care about > overhead that much, you probably want to rethink sending a redundant vide= o > stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in some= ways; but it=E2=80=99s > simpler in that each stream has a unique identifier that can unambiguousl= y > refer to it, whether from another RTP stream or from the signalling > channel, so we won=E2=80=99t have to define yet another identifier if we = later find > a requirement to refer to original and redundant streams independently. > > Colin > > > > Does anyone else want to weigh in? > > /a > > On 2/2/16 13:41, Peter Thatcher wrote: > > > > On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote: > >> >> > On 2 Feb 2016, at 18:45, Peter Thatcher < >> pthatcher@google.com> wrote: >> > >> > >> > >> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >> csp@csperkins.org> wrote: >> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >> jonathan@vidyo.com> wrote: >> > > >> > > Hello, AVTEXT =E2=80=94 >> > > >> > > As discussed in Yokohama, Adam Roach et al have submitted a draft on >> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying e= ncoded and >> dependent streams. >> > > >> > > This is a call to see whether the AVTEXT working group wants to take >> on this work as a work item (both adding a milestone for the work and >> adopting the existing draft as the starting point for a working group >> document). >> > > >> > > Please comment on the AVTEXT mailing list in the next two weeks (by >> February 15, 2016). >> > >> > I don=E2=80=99t object to adopting this draft as a working group item. >> > >> > However, I do think the working group should carefully review the >> semantics of the RID before this is published as an RFC. The complaint i= n >> the Introduction that none of the previous attempts to address this prob= lem >> =E2=80=9Chave the proper ordinality to refer to an individual stream; al= l such >> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >> with the later requirements that main and redundancy RTP streams have th= e >> same RID. >> > >> > >> > =E2=80=8BPerhaps the introduction could be more precise by saying "hav= e the >> proper ordinality to refer to an individual source RTP stream; all such >> identifiers can appear in more than one source RTP stream"=E2=80=8B >> > >> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >> streams have the same RID as the source RTP stream to indicate which sou= rce >> RTP stream they are redundant with (or repair, or refer to, or whatever = you >> want to call it). It doesn=E2=80=99t matter how many redundancy RTP st= reams there >> are per RID, as long as there is only one source RTP stream. >> >> Perhaps, but on the principle that explicit is better than implicit, >> another design might be for each stream, source or redundancy, to have a >> unique RID, and for redundancy streams to include a list of RID values t= hat >> they provide redundancy for. That way, there is no scope for confusion >> between source and redundancy streams. >> > > =E2=80=8BWhen does a redundancy stream apply to more than one source RTP = stream? > Flexfec is the only case I can think of, and that already provides all of > the necessary info in the payload, so there's no need for a header > extension. > > =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? = Would > anything ever refer to it? If not, let's just not include it (it just > wastes bytes). > > So let's start with your idea, remove the IDs of the redundancy RTP > streams (since no one refers to them, they have no value, and just waste > bytes). We'll also reduce the list to a single value (since only flexfec > would have a list, and flexfec doesn't need the header extension). What > are we left with? An ID in the source RTP stream, and a reference to tha= t > ID in the redundancy RTP streams. That sounds good to me, but we've just > gone and re-invented RID. > > So it sounds like what you're really asking for is multiple RIDs in the > redundancy RTP streams. But I don't really see a use case for that, and o= n > the principle of simple is better than complex, I'd prefer a single value > in the redundancy RTP streams. > > -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > _______________________________________________ > avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/a= vtext > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a11c2d4e865a96e052afcc01f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, I'll try a little more detailed thought/design = experiment. =C2=A0

First, we're really talking abo= ut two different IDs, so let's give them different names for a moment t= o avoid confusion:

SRID: source RTP stream ID: can onl= y refer to a source RTP stream ID
ARID: any RTP stream ID: can re= fer to any RTP stream ID


Now let's co= mpare how we could use them, with two options:

Option = A (current RID draft):

The source RTP stream's pac= kets contain an SRID, which identifies itself.
The redundancy RTP s= tream's packets contain an SRID, which is the SRID of the source RTP st= ream that it protects.

Option B (your idea as I unders= tand it):

The source RTP stream's packets contain = an ARID, which identifies itself.
The redundancy RTP stream's= packets contain an ARID which identifies itself, *and* an SRID, which is t= he ARID of the source RTP stream that it protects.

Opt= ion C (another possibility mentioned in the thread, I think):

<= /div>
The source RTP stream's packets co= ntain an ARID, which identifies itself.
T= he redundancy RTP stream's packets contain an ARID which identifies its= elf
The ARID of the source and redundancy= streams are tied together by signaling.
=

I don't like Option C at all.=C2=A0 It requires too much signaling a= nd API complexity.

However, let's go back to Option B. =C2=A0 If make t= he ARID on the redundancy RTP stream referring to itself optional (since it= 's not used most of the time, why include it?), then we end up with how= I would use it:

Option B2 (your idea, with the = ARID optional on the redundancy stream):
=
The source RTP stream's packets = contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID= of the source RTP stream that it protects (and optionally an ARID which id= entifies itself)


Now another question:= what if you get an SRID in a source RTP stream?=C2=A0 What does that mean?= =C2=A0 Well, it could only mean one thing: =C2=A0the ID refers to the sourc= e stream itself, which means it's functionally equivalent to an ARID on= a source RTP stream.=C2=A0 If this were allowed, we would end up with this= option:

Option B3 (your idea, with the ARID opt= ional on the source and redundancy streams):

The source RTP stream's pack= ets contain an SRID (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets cont= ain an SRID, which is the ARID of the source RTP stream that it protects (a= nd optionally an ARID which identifies itself)

Now, that looks like a system = that would allow me to do what I want (put one SRID on both) and let you do= what you want (put an ARID on everything).=C2=A0


The SDP/API implications for this would be to basically rename = every instance of "rid" in the MMUSIC RID drafts, JSEP, and the W= ebRTC API with "srid", and then given a name to ARID (probably ju= st "rid"). =C2=A0 Either that or leave "rid" to mean SR= ID and think of a new name for ARID.=C2=A0 That would be a lot less work, b= ut I can't think of a good name for the ARID.


I don't think Option B3 is worth the additional complexity,= since I don't think the ARID is worth having, but if the WG wants to h= ave it, then I'm not strongly opposed, as long as ARIDs are optional an= d I can choose not to use them. =C2=A0
And Option C is right out.

I hope that h= elps explain my thinking.=C2=A0

On Thu, Feb 4, 2016 at 3:54 PM,= Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

P= erhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do = two things: provide a unique identifier for an RTP stream, and provide an i= dentifier which can connect a redundancy RTP stream and the RTP stream it i= s protecting. I was suggesting that these functions should be kept separate= . Each stream, whether original or redundancy, could optionally have a RID = assigned to it. The original and redundant streams would have different RID= s. Each stream that has a RID assigned to it could also (optionally) includ= e a list of other RID values that it=E2=80=99s associated with. If it=E2=80= =99s a FEC stream, these other RID values could be the stream(s) that it=E2= =80=99s protecting; if it=E2=80=99s a simulcast stream, they could be the o= ther versions; if it=E2=80=99s a layered stream, they could be the other la= yers, etc. Each stream therefore has a unique identifier, and relationships= between them are explicit rather than implicit.=C2=A0

=
(We can argue later about whether this is one SDES item with two parts= to it, or two SDES items; the syntax isn=E2=80=99t the important part)=C2= =A0

Yes, this has slightly higher overhead (althou= gh if you care about overhead that much, you probably want to rethink sendi= ng a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly m= ore complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from anothe= r RTP stream or from the signalling channel, so we won=E2=80=99t have to de= fine yet another identifier if we later find a requirement to refer to orig= inal and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80=8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext




--=C2= =A0
Colin Perkins

<= /span>



--001a11c2d4e865a96e052afcc01f-- From nobody Thu Feb 4 18:40:35 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2341C1B2C71 for ; Thu, 4 Feb 2016 18:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 XfNWGzTuZRvE for ; Thu, 4 Feb 2016 18:40:30 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 BA93F1B2D5D for ; Thu, 4 Feb 2016 18:40:29 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id wb13so78808803obb.1 for ; Thu, 04 Feb 2016 18:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1oAVJTf9Zm9MdapzKVg2UH0gLrEril4xOSbAkDDA9Qw=; b=JXLznnvKD7rexXAVPclXeriHN53x+9BNJk8LosEgJUrWl6ujc311DHTZrWCMsej2bA 895aULyYwTRz2hXBfyeTIL4HqTlN2v/O47tZ0I2/9aEcA1jfhGpEaW/0xgDVL+ME1onY i+lJwzEMslIaDpqLUVAdQIlU6wcp9tu+/T5e64IWBIJq++1U1pRhbEcNZQHuNJyVLfQr PR7yYXbZuSu9hRrEgKrvy6OH+r+uJsPe8wsz3lGWCHsd0bFA5OPIle80yI5xELG6ukY6 +7c8VUnFbwN+UD1CkmPxsJZYYemDpGouzOs5Ll/yx4rJn6JG01129knHG89ird2QkJhz inHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1oAVJTf9Zm9MdapzKVg2UH0gLrEril4xOSbAkDDA9Qw=; b=cmzhfpAwyKiYTzu8HHG+D+fSN/rL5+G9anktoveoKS0dG6B+zfkZA1/QWtjAO4tjNv mGzPgVynArYaiykizByghzoY1r0WqMDza5yy5o7CG9rIXsawCcfANXtdG168t4bYTal/ y9VJRJsbdCLOBvqpL9hAqacIZMAlAqGEe6mAz6KpfToard62uPZ8Y8SksIB0TIRJtsuG zT3psW/eBn/ci2n0sng7VnPhaaJQh0dOWGQvfiMnUJCXkLelzU8e5yw8QTXS0cPPbG5h NReXWcxXAHFuSVgLQ2Z+6Js2LoA5jsEW0jMM3zuDYp9fMgsRmdJxfKivdYpzu7DrvEoN JRBQ== X-Gm-Message-State: AG10YOSdwZMFIVvqjgZf2QRUIC+kN4uW5W6XbBfKPInOiJldFu00Soq4CphtMK2S6tJFVeScarCJfVPjhZiJEgCy X-Received: by 10.60.50.98 with SMTP id b2mr10091727oeo.38.1454640029054; Thu, 04 Feb 2016 18:40:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 4 Feb 2016 18:39:49 -0800 (PST) In-Reply-To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> From: Peter Thatcher Date: Thu, 4 Feb 2016 18:39:49 -0800 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11c1e276358cf4052afcc6c9 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 02:40:34 -0000 --001a11c1e276358cf4052afcc6c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, one minor correction to that, the Option B3 should read: The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself. The redundancy RTP stream's packets contain an SRID, which is the SRID/ARID (either way) of the source RTP stream that it protects (and optionally an ARID which identifies itself) On Thu, Feb 4, 2016 at 6:38 PM, Peter Thatcher wrote= : > OK, I'll try a little more detailed thought/design experiment. > > First, we're really talking about two different IDs, so let's give them > different names for a moment to avoid confusion: > > SRID: source RTP stream ID: can only refer to a source RTP stream ID > ARID: any RTP stream ID: can refer to any RTP stream ID > > > Now let's compare how we could use them, with two options: > > Option A (current RID draft): > > The source RTP stream's packets contain an SRID, which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the SRID of > the source RTP stream that it protects. > > Option B (your idea as I understand it): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an ARID which identifies > itself, *and* an SRID, which is the ARID of the source RTP stream that it > protects. > > Option C (another possibility mentioned in the thread, I think): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an ARID which identifies itse= lf > The ARID of the source and redundancy streams are tied together by > signaling. > > > I don't like Option C at all. It requires too much signaling and API > complexity. > > However, let's go back to Option B. If make the ARID on the redundancy > RTP stream referring to itself optional (since it's not used most of the > time, why include it?), then we end up with how I would use it: > > Option B2 (your idea, with the ARID optional on the redundancy stream): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID of > the source RTP stream that it protects (and optionally an ARID which > identifies itself) > > > Now another question: what if you get an SRID in a source RTP stream? > What does that mean? Well, it could only mean one thing: the ID refers = to > the source stream itself, which means it's functionally equivalent to an > ARID on a source RTP stream. If this were allowed, we would end up with > this option: > > Option B3 (your idea, with the ARID optional on the source and redundancy > streams): > > The source RTP stream's packets contain an SRID (or, optionally, an ARID)= , > which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID of > the source RTP stream that it protects (and optionally an ARID which > identifies itself) > > Now, that looks like a system that would allow me to do what I want (put > one SRID on both) and let you do what you want (put an ARID on everything= ). > > > The SDP/API implications for this would be to basically rename every > instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with > "srid", and then given a name to ARID (probably just "rid"). Either tha= t > or leave "rid" to mean SRID and think of a new name for ARID. That would > be a lot less work, but I can't think of a good name for the ARID. > > > I don't think Option B3 is worth the additional complexity, since I don't > think the ARID is worth having, but if the WG wants to have it, then I'm > not strongly opposed, as long as ARIDs are optional and I can choose not = to > use them. > > And Option C is right out. > > I hope that helps explain my thinking. > > On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: > >> >> On 4 Feb 2016, at 22:57, Adam Roach wrote: >> >> I don't have a strong opinion one way or another here. At this point, I >> hear one voice for keeping as-is, and another for giving redundancy stre= ams >> their own RID (or RIDs? I don't understand the suggestion that we use a >> list of RIDs). >> >> >> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to= do two >> things: provide a unique identifier for an RTP stream, and provide an >> identifier which can connect a redundancy RTP stream and the RTP stream = it >> is protecting. I was suggesting that these functions should be kept >> separate. Each stream, whether original or redundancy, could optionally >> have a RID assigned to it. The original and redundant streams would have >> different RIDs. Each stream that has a RID assigned to it could also >> (optionally) include a list of other RID values that it=E2=80=99s associ= ated with. >> If it=E2=80=99s a FEC stream, these other RID values could be the stream= (s) that >> it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could = be the other >> versions; if it=E2=80=99s a layered stream, they could be the other laye= rs, etc. >> Each stream therefore has a unique identifier, and relationships between >> them are explicit rather than implicit. >> >> (We can argue later about whether this is one SDES item with two parts t= o >> it, or two SDES items; the syntax isn=E2=80=99t the important part) >> >> Yes, this has slightly higher overhead (although if you care about >> overhead that much, you probably want to rethink sending a redundant vid= eo >> stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in som= e ways; but it=E2=80=99s >> simpler in that each stream has a unique identifier that can unambiguous= ly >> refer to it, whether from another RTP stream or from the signalling >> channel, so we won=E2=80=99t have to define yet another identifier if we= later find >> a requirement to refer to original and redundant streams independently. >> >> Colin >> >> >> >> Does anyone else want to weigh in? >> >> /a >> >> On 2/2/16 13:41, Peter Thatcher wrote: >> >> >> >> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins wrote= : >> >>> >>> > On 2 Feb 2016, at 18:45, Peter Thatcher < >>> pthatcher@google.com> wrote: >>> > >>> > >>> > >>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >>> csp@csperkins.org> wrote: >>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >>> jonathan@vidyo.com> wrote: >>> > > >>> > > Hello, AVTEXT =E2=80=94 >>> > > >>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft o= n >>> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and >>> dependent streams. >>> > > >>> > > This is a call to see whether the AVTEXT working group wants to tak= e >>> on this work as a work item (both adding a milestone for the work and >>> adopting the existing draft as the starting point for a working group >>> document). >>> > > >>> > > Please comment on the AVTEXT mailing list in the next two weeks (by >>> February 15, 2016). >>> > >>> > I don=E2=80=99t object to adopting this draft as a working group item= . >>> > >>> > However, I do think the working group should carefully review the >>> semantics of the RID before this is published as an RFC. The complaint = in >>> the Introduction that none of the previous attempts to address this pro= blem >>> =E2=80=9Chave the proper ordinality to refer to an individual stream; a= ll such >>> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >>> with the later requirements that main and redundancy RTP streams have t= he >>> same RID. >>> > >>> > >>> > =E2=80=8BPerhaps the introduction could be more precise by saying "ha= ve the >>> proper ordinality to refer to an individual source RTP stream; all such >>> identifiers can appear in more than one source RTP stream"=E2=80=8B >>> > >>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >>> streams have the same RID as the source RTP stream to indicate which so= urce >>> RTP stream they are redundant with (or repair, or refer to, or whatever= you >>> want to call it). It doesn=E2=80=99t matter how many redundancy RTP s= treams there >>> are per RID, as long as there is only one source RTP stream. >>> >>> Perhaps, but on the principle that explicit is better than implicit, >>> another design might be for each stream, source or redundancy, to have = a >>> unique RID, and for redundancy streams to include a list of RID values = that >>> they provide redundancy for. That way, there is no scope for confusion >>> between source and redundancy streams. >>> >> >> =E2=80=8BWhen does a redundancy stream apply to more than one source RTP= stream? >> Flexfec is the only case I can think of, and that already provides all o= f >> the necessary info in the payload, so there's no need for a header >> extension. >> >> =E2=80=8BAnd what value would an ID of a redundancy RTP stream provide? = Would >> anything ever refer to it? If not, let's just not include it (it just >> wastes bytes). >> >> So let's start with your idea, remove the IDs of the redundancy RTP >> streams (since no one refers to them, they have no value, and just waste >> bytes). We'll also reduce the list to a single value (since only flexfe= c >> would have a list, and flexfec doesn't need the header extension). What >> are we left with? An ID in the source RTP stream, and a reference to th= at >> ID in the redundancy RTP streams. That sounds good to me, but we've jus= t >> gone and re-invented RID. >> >> So it sounds like what you're really asking for is multiple RIDs in the >> redundancy RTP streams. But I don't really see a use case for that, and = on >> the principle of simple is better than complex, I'd prefer a single valu= e >> in the redundancy RTP streams. >> >> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/= avtext >> >> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > --001a11c1e276358cf4052afcc6c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, one minor correction to that, the Option B3 shou= ld read:

The source RTP stream's packets contain an SRID (or, optiona= lly, an ARID), which identifies itself.
The redundancy RTP stream's packets contain a= n SRID, which is the SRID/ARID (either way) of the source RTP stream that i= t protects (and optionally an ARID which identifies itself)

On Thu, Feb 4, = 2016 at 6:38 PM, Peter Thatcher <pthatcher@google.com> wr= ote:
OK, I'll try= a little more detailed thought/design experiment. =C2=A0

First, we're really talking about two different IDs, so let's= give them different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID<= /div>
ARID: any RTP stream ID: can refer to any RTP stream ID

Now let's compare how we could use them, with tw= o options:

Option A (current RID draft):

<= /div>
The source RTP stream's packets contain an SRID, which identifi= es itself.
The redundancy RTP stream's packets contain an SRID,= which is the SRID of the source RTP stream that it protects.

<= /div>
Option B (your idea as I understand it):

The s= ource RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identif= ies itself, *and* an SRID, which is the ARID of the source RTP stream that = it protects.

Option C (another possibility mentioned i= n the thread, I think):

T= he source RTP stream's packets contain an ARID, which identifies itself= .
The redundancy RTP stream's packets= contain an ARID which identifies itself
= The ARID of the source and redundancy streams are tied together by signalin= g.


I don't like Option C at all.= =C2=A0 It requires too much signaling and API complexity.

However, let'= s go back to Option B. =C2=A0 If make the ARID on the redundancy RTP stream= referring to itself optional (since it's not used most of the time, wh= y include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stre= am):

The source RTP stream's packets contain an ARID, which identifies it= self.
The redundancy RTP stream's pac= kets contain an SRID, which is the ARID of the source RTP stream that it pr= otects (and optionally an ARID which identifies itself)


Now another question: what if you get an SRID in a sourc= e RTP stream?=C2=A0 What does that mean?=C2=A0 Well, it could only mean one= thing: =C2=A0the ID refers to the source stream itself, which means it'= ;s functionally equivalent to an ARID on a source RTP stream.=C2=A0 If this= were allowed, we would end up with this option:

Option B3 (your idea, with the ARID optional on the source and redundancy = streams):

The source RTP stream's packets contain an SRID (or, optionally= , an ARID), which identifies itself.
The = redundancy RTP stream's packets contain an SRID, which is the ARID of t= he source RTP stream that it protects (and optionally an ARID which identif= ies itself)

Now, that looks like a system that would allow me to do what I wa= nt (put one SRID on both) and let you do what you want (put an ARID on ever= ything).=C2=A0


The SDP/API implication= s for this would be to basically rename every instance of "rid" i= n the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", an= d then given a name to ARID (probably just "rid"). =C2=A0 Either = that or leave "rid" to mean SRID and think of a new name for ARID= .=C2=A0 That would be a lot less work, but I can't think of a good name= for the ARID.


I don't think Optio= n B3 is worth the additional complexity, since I don't think the ARID i= s worth having, but if the WG wants to have it, then I'm not strongly o= pposed, as long as ARIDs are optional and I can choose not to use them. =C2= =A0

And Option C is right out.

I hope that helps explain my thinking.=C2=A0

On Thu, Feb 4, 2016 at 3:5= 4 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wro= te:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

P= erhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do = two things: provide a unique identifier for an RTP stream, and provide an i= dentifier which can connect a redundancy RTP stream and the RTP stream it i= s protecting. I was suggesting that these functions should be kept separate= . Each stream, whether original or redundancy, could optionally have a RID = assigned to it. The original and redundant streams would have different RID= s. Each stream that has a RID assigned to it could also (optionally) includ= e a list of other RID values that it=E2=80=99s associated with. If it=E2=80= =99s a FEC stream, these other RID values could be the stream(s) that it=E2= =80=99s protecting; if it=E2=80=99s a simulcast stream, they could be the o= ther versions; if it=E2=80=99s a layered stream, they could be the other la= yers, etc. Each stream therefore has a unique identifier, and relationships= between them are explicit rather than implicit.=C2=A0

=
(We can argue later about whether this is one SDES item with two parts= to it, or two SDES items; the syntax isn=E2=80=99t the important part)=C2= =A0

Yes, this has slightly higher overhead (althou= gh if you care about overhead that much, you probably want to rethink sendi= ng a redundant video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly m= ore complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from anothe= r RTP stream or from the signalling channel, so we won=E2=80=99t have to de= fine yet another identifier if we later find a requirement to refer to orig= inal and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and he= ader extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document). > >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a worki= ng group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the late= r requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise = by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. =E2=80= =8B=E2=80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0It doesn=E2=80=99t matter how m= any redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80=8BAnd what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If not, let's ju= st not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce t= he list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).= =C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream= , and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds good to me, but we've just g= one and re-invented RID.

So it sounds like what you're really asking for is multiple RID= s in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext




--=C2= =A0
Colin Perkins

<= /span>




--001a11c1e276358cf4052afcc6c9-- From nobody Fri Feb 5 00:24:37 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC51A1AFF for ; Fri, 5 Feb 2016 00:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 AmoyW_NQXXZv for ; Fri, 5 Feb 2016 00:24:28 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BC11A1AFB for ; Fri, 5 Feb 2016 00:24:28 -0800 (PST) Received: from [81.187.2.149] (port=46336 helo=[192.168.0.64]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRbgj-0002Aj-QE; Fri, 05 Feb 2016 08:24:24 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA100429-AB5D-4292-A8F9-8D7777EAF3F4" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Fri, 5 Feb 2016 08:24:10 +0000 Message-Id: <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> To: Peter Thatcher X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 08:24:35 -0000 --Apple-Mail=_AA100429-AB5D-4292-A8F9-8D7777EAF3F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My proposal is actually much simpler: every stream can have a RID; = streams that have a RID can also express an association with another = RID; both are optional.=20 Colin > On 5 Feb 2016, at 02:38, Peter Thatcher wrote: >=20 > OK, I'll try a little more detailed thought/design experiment. =20 >=20 > First, we're really talking about two different IDs, so let's give = them different names for a moment to avoid confusion: >=20 > SRID: source RTP stream ID: can only refer to a source RTP stream ID > ARID: any RTP stream ID: can refer to any RTP stream ID >=20 >=20 > Now let's compare how we could use them, with two options: >=20 > Option A (current RID draft): >=20 > The source RTP stream's packets contain an SRID, which identifies = itself. > The redundancy RTP stream's packets contain an SRID, which is the SRID = of the source RTP stream that it protects. >=20 > Option B (your idea as I understand it): >=20 > The source RTP stream's packets contain an ARID, which identifies = itself. > The redundancy RTP stream's packets contain an ARID which identifies = itself, *and* an SRID, which is the ARID of the source RTP stream that = it protects. >=20 > Option C (another possibility mentioned in the thread, I think): >=20 > The source RTP stream's packets contain an ARID, which identifies = itself. > The redundancy RTP stream's packets contain an ARID which identifies = itself > The ARID of the source and redundancy streams are tied together by = signaling. >=20 >=20 > I don't like Option C at all. It requires too much signaling and API = complexity. >=20 > However, let's go back to Option B. If make the ARID on the = redundancy RTP stream referring to itself optional (since it's not used = most of the time, why include it?), then we end up with how I would use = it: >=20 > Option B2 (your idea, with the ARID optional on the redundancy = stream): >=20 > The source RTP stream's packets contain an ARID, which identifies = itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID = of the source RTP stream that it protects (and optionally an ARID which = identifies itself) >=20 >=20 > Now another question: what if you get an SRID in a source RTP stream? = What does that mean? Well, it could only mean one thing: the ID refers = to the source stream itself, which means it's functionally equivalent to = an ARID on a source RTP stream. If this were allowed, we would end up = with this option: >=20 > Option B3 (your idea, with the ARID optional on the source and = redundancy streams): >=20 > The source RTP stream's packets contain an SRID (or, optionally, an = ARID), which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID = of the source RTP stream that it protects (and optionally an ARID which = identifies itself) >=20 > Now, that looks like a system that would allow me to do what I want = (put one SRID on both) and let you do what you want (put an ARID on = everything).=20 >=20 >=20 > The SDP/API implications for this would be to basically rename every = instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API = with "srid", and then given a name to ARID (probably just "rid"). = Either that or leave "rid" to mean SRID and think of a new name for = ARID. That would be a lot less work, but I can't think of a good name = for the ARID. >=20 >=20 > I don't think Option B3 is worth the additional complexity, since I = don't think the ARID is worth having, but if the WG wants to have it, = then I'm not strongly opposed, as long as ARIDs are optional and I can = choose not to use them. =20 >=20 > And Option C is right out. >=20 > I hope that helps explain my thinking.=20 >=20 > On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins > wrote: >=20 >> On 4 Feb 2016, at 22:57, Adam Roach > wrote: >>=20 >> I don't have a strong opinion one way or another here. At this point, = I hear one voice for keeping as-is, and another for giving redundancy = streams their own RID (or RIDs? I don't understand the suggestion that = we use a list of RIDs). >=20 > Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying = to do two things: provide a unique identifier for an RTP stream, and = provide an identifier which can connect a redundancy RTP stream and the = RTP stream it is protecting. I was suggesting that these functions = should be kept separate. Each stream, whether original or redundancy, = could optionally have a RID assigned to it. The original and redundant = streams would have different RIDs. Each stream that has a RID assigned = to it could also (optionally) include a list of other RID values that = it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, these other = RID values could be the stream(s) that it=E2=80=99s protecting; if = it=E2=80=99s a simulcast stream, they could be the other versions; if = it=E2=80=99s a layered stream, they could be the other layers, etc. Each = stream therefore has a unique identifier, and relationships between them = are explicit rather than implicit.=20 >=20 > (We can argue later about whether this is one SDES item with two parts = to it, or two SDES items; the syntax isn=E2=80=99t the important part)=20= >=20 > Yes, this has slightly higher overhead (although if you care about = overhead that much, you probably want to rethink sending a redundant = video stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex = in some ways; but it=E2=80=99s simpler in that each stream has a unique = identifier that can unambiguously refer to it, whether from another RTP = stream or from the signalling channel, so we won=E2=80=99t have to = define yet another identifier if we later find a requirement to refer to = original and redundant streams independently.=20 >=20 > Colin >=20 >=20 >=20 >> Does anyone else want to weigh in? >>=20 >> /a >>=20 >> On 2/2/16 13:41, Peter Thatcher wrote: >>>=20 >>>=20 >>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins > wrote: >>>=20 >>> > On 2 Feb 2016, at 18:45, Peter Thatcher < = pthatcher@google.com = > wrote: >>> > >>> > >>> > >>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < = csp@csperkins.org > = wrote: >>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < = jonathan@vidyo.com = > wrote: >>> > > >>> > > Hello, AVTEXT =E2=80=94 >>> > > >>> > > As discussed in Yokohama, Adam Roach et al have submitted a = draft on a =E2=80=9CRID=E2=80=9D SDES item and header extension for = identifying encoded and dependent streams. >>> > > >>> > > This is a call to see whether the AVTEXT working group wants to = take on this work as a work item (both adding a milestone for the work = and adopting the existing draft as the starting point for a working = group document). >>> > > >>> > > Please comment on the AVTEXT mailing list in the next two weeks = (by February 15, 2016). >>> > >>> > I don=E2=80=99t object to adopting this draft as a working group = item. >>> > >>> > However, I do think the working group should carefully review the = semantics of the RID before this is published as an RFC. The complaint = in the Introduction that none of the previous attempts to address this = problem =E2=80=9Chave the proper ordinality to refer to an individual = stream; all such identifiers can appear in more than one stream at a = time=E2=80=9D doesn=E2=80=99t align with the later requirements that = main and redundancy RTP streams have the same RID. >>> > >>> > >>> > =E2=80=8BPerhaps the introduction could be more precise by saying = "have the proper ordinality to refer to an individual source RTP stream; = all such identifiers can appear in more than one source RTP stream"=E2=80=8B= >>> > >>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP = stream to indicate which source RTP stream they are redundant with (or = repair, or refer to, or whatever you want to call it). It doesn=E2=80=99= t matter how many redundancy RTP streams there are per = RID, as long as there is only one source RTP stream. >>>=20 >>> Perhaps, but on the principle that explicit is better than implicit, = another design might be for each stream, source or redundancy, to have a = unique RID, and for redundancy streams to include a list of RID values = that they provide redundancy for. That way, there is no scope for = confusion between source and redundancy streams. >>>=20 >>> =E2=80=8BWhen does a redundancy stream apply to more than one source = RTP stream? Flexfec is the only case I can think of, and that already = provides all of the necessary info in the payload, so there's no need = for a header extension. =20 >>>=20 >>> =E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide? Would anything ever refer to it? If not, let's just not = include it (it just wastes bytes). >>>=20 >>> So let's start with your idea, remove the IDs of the redundancy RTP = streams (since no one refers to them, they have no value, and just waste = bytes). We'll also reduce the list to a single value (since only = flexfec would have a list, and flexfec doesn't need the header = extension). What are we left with? An ID in the source RTP stream, and = a reference to that ID in the redundancy RTP streams. That sounds good = to me, but we've just gone and re-invented RID. >>>=20 >>> So it sounds like what you're really asking for is multiple RIDs in = the redundancy RTP streams. But I don't really see a use case for that, = and on the principle of simple is better than complex, I'd prefer a = single value in the redundancy RTP streams. >>>=20 >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext = >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_AA100429-AB5D-4292-A8F9-8D7777EAF3F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My proposal is actually much simpler: every stream can have a = RID; streams that have a RID can also express an association with = another RID; both are optional. 

Colin



On = 5 Feb 2016, at 02:38, Peter Thatcher <pthatcher@google.com> wrote:

OK, I'll try a little = more detailed thought/design experiment.  

First, we're really = talking about two different IDs, so let's give them different names for = a moment to avoid confusion:

SRID: source RTP stream = ID: can only refer to a source RTP stream ID
ARID: any RTP stream = ID: can refer to any RTP stream ID


Now let's compare how = we could use them, with two options:

Option A (current RID = draft):

The source RTP stream's = packets contain an SRID, which identifies itself.
The redundancy RTP = stream's packets contain an SRID, which is the SRID of the source RTP = stream that it protects.

Option B (your idea as = I understand it):

The source RTP stream's = packets contain an ARID, which identifies itself.
The redundancy RTP = stream's packets contain an ARID which identifies itself, *and* an SRID, = which is the ARID of the source RTP stream that it protects.

Option C (another = possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, = which identifies itself.
The = redundancy RTP stream's packets contain an ARID which identifies = itself
The ARID of the source and = redundancy streams are tied together by signaling.


I don't like Option C at all.  It requires = too much signaling and API complexity.

However, let's go back to Option B.   If = make the ARID on the redundancy RTP stream referring to itself optional = (since it's not used most of the time, why include it?), then we end up = with how I would use it:

Option B2 (your idea, with the ARID optional on = the redundancy stream):

The source RTP stream's = packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an = SRID, which is the ARID of the source RTP stream that it protects (and = optionally an ARID which identifies itself)


Now another question: what if you get an SRID in = a source RTP stream?  What does that mean?  Well, it could = only mean one thing:  the ID refers to the source stream itself, = which means it's functionally equivalent to an ARID on a source RTP = stream.  If this were allowed, we would end up with this = option:

Option B3 (your = idea, with the ARID optional on the source and redundancy = streams):

The source RTP stream's packets contain an SRID = (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets contain an = SRID, which is the ARID of the source RTP stream that it protects (and = optionally an ARID which identifies itself)

Now, that looks like a system that would allow = me to do what I want (put one SRID on both) and let you do what you want = (put an ARID on everything). 


The SDP/API implications for this would be to = basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, = and the WebRTC API with "srid", and then given a name to ARID (probably = just "rid").   Either that or leave "rid" to mean SRID and think of = a new name for ARID.  That would be a lot less work, but I can't = think of a good name for the ARID.


I don't think Option B3 is worth the additional = complexity, since I don't think the ARID is worth having, but if the WG = wants to have it, then I'm not strongly opposed, as long as ARIDs are = optional and I can choose not to use them.  

And Option C is right out.

I hope that helps explain my = thinking. 

On Thu, = Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20
I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Perhaps I = didn=E2=80=99t explain myself well. The RID draft is trying to do two = things: provide a unique identifier for an RTP stream, and provide an = identifier which can connect a redundancy RTP stream and the RTP stream = it is protecting. I was suggesting that these functions should be kept = separate. Each stream, whether original or redundancy, could optionally = have a RID assigned to it. The original and redundant streams would have = different RIDs. Each stream that has a RID assigned to it could also = (optionally) include a list of other RID values that it=E2=80=99s = associated with. If it=E2=80=99s a FEC stream, these other RID values = could be the stream(s) that it=E2=80=99s protecting; if it=E2=80=99s a = simulcast stream, they could be the other versions; if it=E2=80=99s a = layered stream, they could be the other layers, etc. Each stream = therefore has a unique identifier, and relationships between them are = explicit rather than implicit. 

(We can argue later about whether this = is one SDES item with two parts to it, or two SDES items; the syntax = isn=E2=80=99t the important part) 

Yes, this has slightly higher overhead = (although if you care about overhead that much, you probably want to = rethink sending a redundant video stream=E2=80=A6). Yes, it=E2=80=99s = perhaps slightly more complex in some ways; but it=E2=80=99s simpler in = that each stream has a unique identifier that can unambiguously refer to = it, whether from another RTP stream or from the signalling channel, so = we won=E2=80=99t have to define yet another identifier if we later find = a requirement to refer to original and redundant streams = independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item and = header extension for identifying encoded and dependent = streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group = document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a = working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Chave the proper ordinality to refer to an = individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80=99t align with the = later requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more = precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID per source RTP stream. = =E2=80=8B=E2=80=8B  =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn=E2=80=99t matter = how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8BWhen does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think = of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

=E2=80=8BAnd what value would an ID of a redundancy RTP stream = provide?  Would anything ever refer to it?  If not, let's = just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce = the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header = extension).  What are we left with?  An ID in the source RTP = stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just = gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




-- 
Colin Perkins
https://csperkins.org/








-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_AA100429-AB5D-4292-A8F9-8D7777EAF3F4-- From nobody Fri Feb 5 06:49:54 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961C1B39DA for ; Fri, 5 Feb 2016 06:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no 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 11-Amma8_MIP for ; Fri, 5 Feb 2016 06:49:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 01F761B39CD for ; Fri, 5 Feb 2016 06:49:48 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u15Enaox025218 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 Feb 2016 08:49:36 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins , Peter Thatcher References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> From: Adam Roach Message-ID: <56B4B67F.9050102@nostrum.com> Date: Fri, 5 Feb 2016 08:49:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> Content-Type: multipart/alternative; boundary="------------060600010907030500020200" Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:49:53 -0000 This is a multi-part message in MIME format. --------------060600010907030500020200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently. I'm sympathetic to Peter's concern that solutions that require multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way. At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future. I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID. And this sub-identifier will be PT. Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation. In Colin's terms: Every stream can have [an identifier] (RID+PT in this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them). In Peter's terms: SRID = RID, and ARID = RID+PT Sound reasonable? /a On 2/5/16 02:24, Colin Perkins wrote: > My proposal is actually much simpler: every stream can have a RID; > streams that have a RID can also express an association with another > RID; both are optional. > > Colin > > > >> On 5 Feb 2016, at 02:38, Peter Thatcher > > wrote: >> >> OK, I'll try a little more detailed thought/design experiment. >> >> First, we're really talking about two different IDs, so let's give >> them different names for a moment to avoid confusion: >> >> SRID: source RTP stream ID: can only refer to a source RTP stream ID >> ARID: any RTP stream ID: can refer to any RTP stream ID >> >> >> Now let's compare how we could use them, with two options: >> >> Option A (current RID draft): >> >> The source RTP stream's packets contain an SRID, which identifies itself. >> The redundancy RTP stream's packets contain an SRID, which is the >> SRID of the source RTP stream that it protects. >> >> Option B (your idea as I understand it): >> >> The source RTP stream's packets contain an ARID, which identifies itself. >> The redundancy RTP stream's packets contain an ARID which identifies >> itself, *and* an SRID, which is the ARID of the source RTP stream >> that it protects. >> >> Option C (another possibility mentioned in the thread, I think): >> >> The source RTP stream's packets contain an ARID, which identifies itself. >> The redundancy RTP stream's packets contain an ARID which identifies >> itself >> The ARID of the source and redundancy streams are tied together by >> signaling. >> >> >> I don't like Option C at all. It requires too much signaling and API >> complexity. >> >> However, let's go back to Option B. If make the ARID on the >> redundancy RTP stream referring to itself optional (since it's not >> used most of the time, why include it?), then we end up with how I >> would use it: >> >> Option B2 (your idea, with the ARID optional on the redundancy stream): >> >> The source RTP stream's packets contain an ARID, which identifies itself. >> The redundancy RTP stream's packets contain an SRID, which is the >> ARID of the source RTP stream that it protects (and optionally an >> ARID which identifies itself) >> >> >> Now another question: what if you get an SRID in a source RTP stream? >> What does that mean? Well, it could only mean one thing: the ID >> refers to the source stream itself, which means it's functionally >> equivalent to an ARID on a source RTP stream. If this were allowed, >> we would end up with this option: >> >> Option B3 (your idea, with the ARID optional on the source and >> redundancy streams): >> >> The source RTP stream's packets contain an SRID (or, optionally, an >> ARID), which identifies itself. >> The redundancy RTP stream's packets contain an SRID, which is the >> ARID of the source RTP stream that it protects (and optionally an >> ARID which identifies itself) >> >> Now, that looks like a system that would allow me to do what I want >> (put one SRID on both) and let you do what you want (put an ARID on >> everything). >> >> >> The SDP/API implications for this would be to basically rename every >> instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API >> with "srid", and then given a name to ARID (probably just "rid"). >> Either that or leave "rid" to mean SRID and think of a new name for >> ARID. That would be a lot less work, but I can't think of a good >> name for the ARID. >> >> >> I don't think Option B3 is worth the additional complexity, since I >> don't think the ARID is worth having, but if the WG wants to have it, >> then I'm not strongly opposed, as long as ARIDs are optional and I >> can choose not to use them. >> >> And Option C is right out. >> >> I hope that helps explain my thinking. >> >> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins > > wrote: >> >> >>> On 4 Feb 2016, at 22:57, Adam Roach >> > wrote: >>> >>> I don't have a strong opinion one way or another here. At this >>> point, I hear one voice for keeping as-is, and another for >>> giving redundancy streams their own RID (or RIDs? I don't >>> understand the suggestion that we use a list of RIDs). >> >> Perhaps I didn’t explain myself well. The RID draft is trying to >> do two things: provide a unique identifier for an RTP stream, and >> provide an identifier which can connect a redundancy RTP stream >> and the RTP stream it is protecting. I was suggesting that these >> functions should be kept separate. Each stream, whether original >> or redundancy, could optionally have a RID assigned to it. The >> original and redundant streams would have different RIDs. Each >> stream that has a RID assigned to it could also (optionally) >> include a list of other RID values that it’s associated with. If >> it’s a FEC stream, these other RID values could be the stream(s) >> that it’s protecting; if it’s a simulcast stream, they could be >> the other versions; if it’s a layered stream, they could be the >> other layers, etc. Each stream therefore has a unique identifier, >> and relationships between them are explicit rather than implicit. >> >> (We can argue later about whether this is one SDES item with two >> parts to it, or two SDES items; the syntax isn’t the important part) >> >> Yes, this has slightly higher overhead (although if you care >> about overhead that much, you probably want to rethink sending a >> redundant video stream…). Yes, it’s perhaps slightly more complex >> in some ways; but it’s simpler in that each stream has a unique >> identifier that can unambiguously refer to it, whether from >> another RTP stream or from the signalling channel, so we won’t >> have to define yet another identifier if we later find a >> requirement to refer to original and redundant streams >> independently. >> >> Colin >> >> >> >>> Does anyone else want to weigh in? >>> >>> /a >>> >>> On 2/2/16 13:41, Peter Thatcher wrote: >>>> >>>> >>>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins >>>> > wrote: >>>> >>>> >>>> > On 2 Feb 2016, at 18:45, Peter Thatcher >>>> > wrote: >>>> > >>>> > >>>> > >>>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins >>>> > wrote: >>>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox >>>> > wrote: >>>> > > >>>> > > Hello, AVTEXT — >>>> > > >>>> > > As discussed in Yokohama, Adam Roach et al have >>>> submitted a draft on a “RID” SDES item and header extension >>>> for identifying encoded and dependent streams. >>>> > > >>>> > > This is a call to see whether the AVTEXT working group >>>> wants to take on this work as a work item (both adding a >>>> milestone for the work and adopting the existing draft as >>>> the starting point for a working group document). >>>> > > >>>> > > Please comment on the AVTEXT mailing list in the next >>>> two weeks (by February 15, 2016). >>>> > >>>> > I don’t object to adopting this draft as a working group >>>> item. >>>> > >>>> > However, I do think the working group should carefully >>>> review the semantics of the RID before this is published as >>>> an RFC. The complaint in the Introduction that none of the >>>> previous attempts to address this problem “have the proper >>>> ordinality to refer to an individual stream; all such >>>> identifiers can appear in more than one stream at a time” >>>> doesn’t align with the later requirements that main and >>>> redundancy RTP streams have the same RID. >>>> > >>>> > >>>> > ​Perhaps the introduction could be more precise by saying >>>> "have the proper ordinality to refer to an individual >>>> source RTP stream; all such identifiers can appear in more >>>> than one source RTP stream"​ >>>> > >>>> > ​There is one RID per source RTP stream. ​​ ​The >>>> redundancy RTP streams have the same RID as the source RTP >>>> stream to indicate which source RTP stream they are >>>> redundant with (or repair, or refer to, or whatever you >>>> want to call it). It doesn’t matter how many redundancy >>>> RTP streams there are per RID, as long as there is only one >>>> source RTP stream. >>>> >>>> Perhaps, but on the principle that explicit is better than >>>> implicit, another design might be for each stream, source >>>> or redundancy, to have a unique RID, and for redundancy >>>> streams to include a list of RID values that they provide >>>> redundancy for. That way, there is no scope for confusion >>>> between source and redundancy streams. >>>> >>>> >>>> ​ When does a redundancy stream apply to more than one source >>>> RTP stream? Flexfec is the only case I can think of, and that >>>> already provides all of the necessary info in the payload, so >>>> there's no need for a header extension. >>>> >>>> ​ And what value would an ID of a redundancy RTP stream >>>> provide? Would anything ever refer to it? If not, let's just >>>> not include it (it just wastes bytes). >>>> >>>> So let's start with your idea, remove the IDs of the redundancy >>>> RTP streams (since no one refers to them, they have no value, >>>> and just waste bytes). We'll also reduce the list to a single >>>> value (since only flexfec would have a list, and flexfec >>>> doesn't need the header extension). What are we left with? An >>>> ID in the source RTP stream, and a reference to that ID in the >>>> redundancy RTP streams. That sounds good to me, but we've just >>>> gone and re-invented RID. >>>> >>>> So it sounds like what you're really asking for is multiple >>>> RIDs in the redundancy RTP streams. But I don't really see a >>>> use case for that, and on the principle of simple is better >>>> than complex, I'd prefer a single value in the redundancy RTP >>>> streams. >>>> >>>> -- >>>> Colin Perkins >>>> https://csperkins.org/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> avtext mailing list >>>> avtext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avtext >>> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > --------------060600010907030500020200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently.

I'm sympathetic to Peter's concern that solutions that require multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way.

At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future.

I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID.

And this sub-identifier will be PT.

Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation.


In Colin's terms: Every stream can have [an identifier] (RID+PT in this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them).

In Peter's terms: SRID = RID, and ARID = RID+PT

Sound reasonable?

/a


On 2/5/16 02:24, Colin Perkins wrote:
My proposal is actually much simpler: every stream can have a RID; streams that have a RID can also express an association with another RID; both are optional. 

Colin



On 5 Feb 2016, at 02:38, Peter Thatcher <pthatcher@google.com> wrote:

OK, I'll try a little more detailed thought/design experiment.  

First, we're really talking about two different IDs, so let's give them different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID
ARID: any RTP stream ID: can refer to any RTP stream ID


Now let's compare how we could use them, with two options:

Option A (current RID draft):

The source RTP stream's packets contain an SRID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the SRID of the source RTP stream that it protects.

Option B (your idea as I understand it):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects.

Option C (another possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself
The ARID of the source and redundancy streams are tied together by signaling.


I don't like Option C at all.  It requires too much signaling and API complexity.

However, let's go back to Option B.   If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stream):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)


Now another question: what if you get an SRID in a source RTP stream?  What does that mean?  Well, it could only mean one thing:  the ID refers to the source stream itself, which means it's functionally equivalent to an ARID on a source RTP stream.  If this were allowed, we would end up with this option:

Option B3 (your idea, with the ARID optional on the source and redundancy streams):

The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)

Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything). 


The SDP/API implications for this would be to basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", and then given a name to ARID (probably just "rid").   Either that or leave "rid" to mean SRID and think of a new name for ARID.  That would be a lot less work, but I can't think of a good name for the ARID.


I don't think Option B3 is worth the additional complexity, since I don't think the ARID is worth having, but if the WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them.  

And Option C is right out.

I hope that helps explain my thinking. 

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).
Perhaps I didn’t explain myself well. The RID draft is trying to do two things: provide a unique identifier for an RTP stream, and provide an identifier which can connect a redundancy RTP stream and the RTP stream it is protecting. I was suggesting that these functions should be kept separate. Each stream, whether original or redundancy, could optionally have a RID assigned to it. The original and redundant streams would have different RIDs. Each stream that has a RID assigned to it could also (optionally) include a list of other RID values that it’s associated with. If it’s a FEC stream, these other RID values could be the stream(s) that it’s protecting; if it’s a simulcast stream, they could be the other versions; if it’s a layered stream, they could be the other layers, etc. Each stream therefore has a unique identifier, and relationships between them are explicit rather than implicit. 

(We can argue later about whether this is one SDES item with two parts to it, or two SDES items; the syntax isn’t the important part) 

Yes, this has slightly higher overhead (although if you care about overhead that much, you probably want to rethink sending a redundant video stream…). Yes, it’s perhaps slightly more complex in some ways; but it’s simpler in that each stream has a unique identifier that can unambiguously refer to it, whether from another RTP stream or from the signalling channel, so we won’t have to define yet another identifier if we later find a requirement to refer to original and redundant streams independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT —
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don’t object to adopting this draft as a working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem “have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time” doesn’t align with the later requirements that main and redundancy RTP streams have the same RID.
>
>
> ​Perhaps the introduction could be more precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"​
>
> ​There is one RID per source RTP stream. ​​  ​The redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn’t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

​ When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

​ And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




-- 
Colin Perkins








-- 
Colin Perkins





--------------060600010907030500020200-- From nobody Fri Feb 5 08:30:08 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4281B3B45 for ; Fri, 5 Feb 2016 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 nJBD6H8Wp7qa for ; Fri, 5 Feb 2016 08:30:02 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 168A61B3B43 for ; Fri, 5 Feb 2016 08:30:02 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id ba1so93175785obb.3 for ; Fri, 05 Feb 2016 08:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2WLcm0vLXYeWX8hqNOdIXkeblojmr2KSeFxi1+pBMrw=; b=YonSTiVRqvqrmuTAZe+bPEAcgNGL2wQPi1WgoBc9H46+UJdoSCmpdfIJFjD90rUBKV shVjvSwzmR3tQZH0kh1F3kGCLHAvZ0kMjA3ySAncpJfUxUPuJ3duV9p4uAkPGUYHno0H EoDSxrevjAghl5k6Pq9td/FR/ZrLcmEBKcMQrjNyV5Xe6II/ZLZ0Qe/XbC2v3d1E8CZZ 9WT6LZXwAVHcQgFQtOD32OsWEVIjk8EDoe96GHxvOSkRFpIuQJHRH/QtiP6OlzGh/RJT ptOV1o2Abz/MX7mvd7aA3vGjpTP2PO1MHAxdLIjDb0g8hT08+r/ReC5jSvD8KdT02OaY qHdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2WLcm0vLXYeWX8hqNOdIXkeblojmr2KSeFxi1+pBMrw=; b=YL43D+TK3zqctNftN697bhdzXL0NBeGlc/Q77qDbgVIxPSMvZ30gV2BPb9vq+qkY8u fRx0hoE+jOn/lgVAarEfp6YtiJhaO0utRU1gApiQ8UtFK1DhYgX4UltQYMVA5Kl1Fyuj 8LwIWB7O1ixS9zYGKfUsdb21bYLF1wHVs5SndDOZHldpfy1Hlq+oGsnj8aaVbUaJn4UL ApdZbIrP9NbogF6I/hKFfKmSMMY/Zf3Dciqn7fENB4EgC9G96xM7DQUHYze5IRUIMsZ5 DpweOdsgiLHKKjEjMBCuZtIxMXUZ/ycvplrJkQdmMVzVfCQ+dqVclXDNg//W10PVcKLc Qr8g== X-Gm-Message-State: AG10YOTVRTNzVY+AumvQxSSNhkKI9UkOAsZtTFwdxQtdJ3u0+FGrI4fV657AN0At2v4TcYuwMMQCn4AuSfEwRClv X-Received: by 10.60.58.103 with SMTP id p7mr13343095oeq.2.1454689801213; Fri, 05 Feb 2016 08:30:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Fri, 5 Feb 2016 08:29:21 -0800 (PST) In-Reply-To: <56B4B67F.9050102@nostrum.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> From: Peter Thatcher Date: Fri, 5 Feb 2016 08:29:21 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e0158adccdc6103052b085c10 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:30:07 -0000 --089e0158adccdc6103052b085c10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds like a good compromise to me. On Fri, Feb 5, 2016 at 6:49 AM, Adam Roach wrote: > In the spirit of finding a compromise, I want to back up a bit and see if > we can't thread this needle a little differently. > > I'm sympathetic to Peter's concern that solutions that require multiple > identifiers in a packet or signaling-level correlation of identifiers > introduce API complexities at the top of the RTP stack, and that these > complexities bubble all the way up to the WebRTC API in a very ugly way. > > At the same time, I share Colin's concerns that designing a solution > without consideration for future applications is needlessly short-sighted= , > and may well lead us back to trying to define a new identifier with even > finer granularity in the foreseeable future. > > I propose that we retain the meaning of RID that is currently in the > document, which should satisfy Peter's concern. I want to address Colin's > concern by proposing that we add text to the document indicating that any > future applications of RID that need to identify a Repair RTP Stream > independently of its Source RTP Stream do so with a RID plus a > sub-identifier. This sub-identifier will be scoped to (and unique within)= a > RID. > > And this sub-identifier will be PT. > > Yes, the purpose of defining RID is to get away from using PTs to identif= y > anything other than the configuration of payload types. But the reason th= at > such a split is necessary is that using naked PTs for identification lead= s > to creation of multiple PTs that represent the same configuration, solely > for the purpose of minting unique identifiers. Since redundancy streams > will already have a unique PT within the scope of any given Source RTP > Stream, this proposal does not result in such a situation. > > > In Colin's terms: Every stream can have [an identifier] (RID+PT in this > proposal); streams that have [an identifier] can also express an > association with another [identifier] (by sharing a common RID); both are > optional (implementations that don't care about having a unique name for > redundancy streams don't need to talk about them). > > In Peter's terms: SRID =3D RID, and ARID =3D RID+PT > > Sound reasonable? > > /a > > > > On 2/5/16 02:24, Colin Perkins wrote: > > My proposal is actually much simpler: every stream can have a RID; stream= s > that have a RID can also express an association with another RID; both ar= e > optional. > > Colin > > > > On 5 Feb 2016, at 02:38, Peter Thatcher < > pthatcher@google.com> wrote: > > OK, I'll try a little more detailed thought/design experiment. > > First, we're really talking about two different IDs, so let's give them > different names for a moment to avoid confusion: > > SRID: source RTP stream ID: can only refer to a source RTP stream ID > ARID: any RTP stream ID: can refer to any RTP stream ID > > > Now let's compare how we could use them, with two options: > > Option A (current RID draft): > > The source RTP stream's packets contain an SRID, which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the SRID of > the source RTP stream that it protects. > > Option B (your idea as I understand it): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an ARID which identifies > itself, *and* an SRID, which is the ARID of the source RTP stream that it > protects. > > Option C (another possibility mentioned in the thread, I think): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an ARID which identifies itse= lf > The ARID of the source and redundancy streams are tied together by > signaling. > > > I don't like Option C at all. It requires too much signaling and API > complexity. > > However, let's go back to Option B. If make the ARID on the redundancy > RTP stream referring to itself optional (since it's not used most of the > time, why include it?), then we end up with how I would use it: > > Option B2 (your idea, with the ARID optional on the redundancy stream): > > The source RTP stream's packets contain an ARID, which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID of > the source RTP stream that it protects (and optionally an ARID which > identifies itself) > > > Now another question: what if you get an SRID in a source RTP stream? > What does that mean? Well, it could only mean one thing: the ID refers = to > the source stream itself, which means it's functionally equivalent to an > ARID on a source RTP stream. If this were allowed, we would end up with > this option: > > Option B3 (your idea, with the ARID optional on the source and redundancy > streams): > > The source RTP stream's packets contain an SRID (or, optionally, an ARID)= , > which identifies itself. > The redundancy RTP stream's packets contain an SRID, which is the ARID of > the source RTP stream that it protects (and optionally an ARID which > identifies itself) > > Now, that looks like a system that would allow me to do what I want (put > one SRID on both) and let you do what you want (put an ARID on everything= ). > > > The SDP/API implications for this would be to basically rename every > instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with > "srid", and then given a name to ARID (probably just "rid"). Either tha= t > or leave "rid" to mean SRID and think of a new name for ARID. That would > be a lot less work, but I can't think of a good name for the ARID. > > > I don't think Option B3 is worth the additional complexity, since I don't > think the ARID is worth having, but if the WG wants to have it, then I'm > not strongly opposed, as long as ARIDs are optional and I can choose not = to > use them. > > And Option C is right out. > > I hope that helps explain my thinking. > > On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins < > csp@csperkins.org> wrote: > >> >> On 4 Feb 2016, at 22:57, Adam Roach wrote: >> >> I don't have a strong opinion one way or another here. At this point, I >> hear one voice for keeping as-is, and another for giving redundancy stre= ams >> their own RID (or RIDs? I don't understand the suggestion that we use a >> list of RIDs). >> >> >> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to= do two >> things: provide a unique identifier for an RTP stream, and provide an >> identifier which can connect a redundancy RTP stream and the RTP stream = it >> is protecting. I was suggesting that these functions should be kept >> separate. Each stream, whether original or redundancy, could optionally >> have a RID assigned to it. The original and redundant streams would have >> different RIDs. Each stream that has a RID assigned to it could also >> (optionally) include a list of other RID values that it=E2=80=99s associ= ated with. >> If it=E2=80=99s a FEC stream, these other RID values could be the stream= (s) that >> it=E2=80=99s protecting; if it=E2=80=99s a simulcast stream, they could = be the other >> versions; if it=E2=80=99s a layered stream, they could be the other laye= rs, etc. >> Each stream therefore has a unique identifier, and relationships between >> them are explicit rather than implicit. >> >> (We can argue later about whether this is one SDES item with two parts t= o >> it, or two SDES items; the syntax isn=E2=80=99t the important part) >> >> Yes, this has slightly higher overhead (although if you care about >> overhead that much, you probably want to rethink sending a redundant vid= eo >> stream=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in som= e ways; but it=E2=80=99s >> simpler in that each stream has a unique identifier that can unambiguous= ly >> refer to it, whether from another RTP stream or from the signalling >> channel, so we won=E2=80=99t have to define yet another identifier if we= later find >> a requirement to refer to original and redundant streams independently. >> >> Colin >> >> >> >> Does anyone else want to weigh in? >> >> /a >> >> On 2/2/16 13:41, Peter Thatcher wrote: >> >> >> >> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins < >> csp@csperkins.org> wrote: >> >>> >>> > On 2 Feb 2016, at 18:45, Peter Thatcher < >>> pthatcher@google.com> wrote: >>> > >>> > >>> > >>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < >>> csp@csperkins.org> wrote: >>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < >>> jonathan@vidyo.com> wrote: >>> > > >>> > > Hello, AVTEXT =E2=80=94 >>> > > >>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft o= n >>> a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying = encoded and >>> dependent streams. >>> > > >>> > > This is a call to see whether the AVTEXT working group wants to tak= e >>> on this work as a work item (both adding a milestone for the work and >>> adopting the existing draft as the starting point for a working group >>> document). >>> > > >>> > > Please comment on the AVTEXT mailing list in the next two weeks (by >>> February 15, 2016). >>> > >>> > I don=E2=80=99t object to adopting this draft as a working group item= . >>> > >>> > However, I do think the working group should carefully review the >>> semantics of the RID before this is published as an RFC. The complaint = in >>> the Introduction that none of the previous attempts to address this pro= blem >>> =E2=80=9Chave the proper ordinality to refer to an individual stream; a= ll such >>> identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align >>> with the later requirements that main and redundancy RTP streams have t= he >>> same RID. >>> > >>> > >>> > =E2=80=8BPerhaps the introduction could be more precise by saying "ha= ve the >>> proper ordinality to refer to an individual source RTP stream; all such >>> identifiers can appear in more than one source RTP stream"=E2=80=8B >>> > >>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B = =E2=80=8BThe redundancy RTP >>> streams have the same RID as the source RTP stream to indicate which so= urce >>> RTP stream they are redundant with (or repair, or refer to, or whatever= you >>> want to call it). It doesn=E2=80=99t matter how many redundancy RTP s= treams there >>> are per RID, as long as there is only one source RTP stream. >>> >>> Perhaps, but on the principle that explicit is better than implicit, >>> another design might be for each stream, source or redundancy, to have = a >>> unique RID, and for redundancy streams to include a list of RID values = that >>> they provide redundancy for. That way, there is no scope for confusion >>> between source and redundancy streams. >>> >> >> =E2=80=8B When does a redundancy stream apply to more than one source RT= P >> stream? Flexfec is the only case I can think of, and that already provi= des >> all of the necessary info in the payload, so there's no need for a heade= r >> extension. >> >> =E2=80=8B And what value would an ID of a redundancy RTP stream provide?= Would >> anything ever refer to it? If not, let's just not include it (it just >> wastes bytes). >> >> So let's start with your idea, remove the IDs of the redundancy RTP >> streams (since no one refers to them, they have no value, and just waste >> bytes). We'll also reduce the list to a single value (since only flexfe= c >> would have a list, and flexfec doesn't need the header extension). What >> are we left with? An ID in the source RTP stream, and a reference to th= at >> ID in the redundancy RTP streams. That sounds good to me, but we've jus= t >> gone and re-invented RID. >> >> So it sounds like what you're really asking for is multiple RIDs in the >> redundancy RTP streams. But I don't really see a use case for that, and = on >> the principle of simple is better than complex, I'd prefer a single valu= e >> in the redundancy RTP streams. >> >> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> avtext mailing listavtext@ietf.orghttps://www.ietf.org/mailman/listinfo/= avtext >> >> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > --089e0158adccdc6103052b085c10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds like a good compromise to me.

On Fri, Feb 5, 2016 at 6= :49 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently.

I'm sympathetic to Peter's concern that solutions that requir= e multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way.

At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future.

I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID.

And this sub-identifier will be PT.

Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation.


In Colin's terms: Every stream can have [an identifier] (RID+PT i= n this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them).

In Peter's terms: SRID =3D RID, and ARID =3D RID+PT

Sound reasonable?

/a



On 2/5/16 02:24, Colin Perkins wrote:
=20 My proposal is actually much simpler: every stream can have a RID; streams that have a RID can also express an association with another RID; both are optional.=C2=A0

Colin



On 5 Feb 2016, at 02:38, Peter Thatcher <pthatcher@google.com> wrote:

OK, I'll try a little more detailed thought/design experiment. =C2=A0

First, we're really talking about two different IDs, so let&= #39;s give them different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID
ARID: any RTP stream ID: can refer to any RTP stream ID


Now let's compare how we could use them, with two options= :

Option A (current RID draft):

The source RTP stream's packets contain an SRID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, whic= h is the SRID of the source RTP stream that it protects.

Option B (your idea as I understand it):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects.

Option C (another possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream= 9;s packets contain an ARID which identifies itself
The ARID of the source and redundancy streams are tied together by signaling.


I don't like Option C at all.=C2=A0 It requires too much signaling and API complexity.

However, let's go back t= o Option B. =C2=A0 If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stream):

The source RTP stream'= s packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)


Now another question: what if you get an SRID in a source RTP stream?=C2=A0 What does that mean?=C2=A0 Well, it could only mean o= ne thing: =C2=A0the ID refers to the source stream itsel= f, which means it's functionally equivalent to an ARID on a source RTP stream.=C2=A0 If this were allowed, we would end up with this option:

Option B3 (your idea, with the ARID optional on the source and redundancy streams):

The source RTP stream= 9;s packets contain an SRID (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)

Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything).=C2=A0


The SDP/API implications for this would be to basically rename every instance of "rid" in the MMU= SIC RID drafts, JSEP, and the WebRTC API with "srid&qu= ot;, and then given a name to ARID (probably just "rid"). =C2=A0 Either that or leave "= ;rid" to mean SRID and think of a new name for ARID.=C2=A0 That would be a lot less work, but I can't think of = a good name for the ARID.


I don't think Option= B3 is worth the additional complexity, since I don't think the ARID is worth having, but if th= e WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them. =C2=A0

And Option C is right out.

I hope that helps explain my thinking.=C2=A0

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).
Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying to do two things: provide a unique identifier for an RTP stream, and provide an identifier which can connect a redundancy RTP stream and the RTP stream it is protecting. I was suggesting that these functions should be kept separate. Each stream, whether original or redundancy, could optionally have a RID assigned to it. The original and redundant streams would have different RIDs. Each stream that has a RID assigned to it could also (optionally) include a list of other RID values that it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, th= ese other RID values could be the stream(s) that it=E2=80=99s protecting; if it=E2=80=99s a simulc= ast stream, they could be the other versions; if it=E2=80=99s= a layered stream, they could be the other layers, etc. Each stream therefore has a unique identifier, and relationships between them are explicit rather than implicit.=C2=A0

(We can argue later about whether this is one SDES item with two parts to it, or two SDES items; the syntax isn=E2=80=99t the impo= rtant part)=C2=A0

Yes, this has slightly higher overhead (although if you care about overhead that much, you probably want to rethink sending a redundant video stream=E2=80=A6). Yes, = it=E2=80=99s perhaps slightly more complex in some ways; but it=E2=80=99s simpler in that each stream has = a unique identifier that can unambiguously refer to it, whether from another RTP stream or from the signalling channel, so we won=E2=80=99t have = to define yet another identifier if we later find a requirement to refer to original and redundant streams independently.=C2=A0

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:
> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80= =94
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item= and header extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Ch= ave the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn= =E2=80=99t align with the later requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise by saying "have th= e proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80= =8B
>
> =E2=80=8BThere is one RID = per source RTP stream. =E2=80=8B=E2= =80=8B=C2=A0 =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).=C2=A0 =C2=A0I= t doesn=E2=80=99t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8B When does a redundancy stream apply to more than one source RTP stream?=C2=A0 Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension. =C2=A0

=E2=80=8B And what value would an ID of a redundancy RTP stream provide?=C2=A0 Would anything ever refer to it?=C2=A0 If no= t, let's just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).=C2=A0 We'll also reduce the lis= t to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).=C2=A0 What are we left with?=C2=A0 An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.=C2=A0 That sounds go= od to me, but we've just gon= e and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







__________________________________=
_____________
avtext mailing list
avtext@ietf.org
=
https://www.ietf.org/mailman/listinfo/avtext




--=C2=A0
Colin Perkins








--=C2=A0
Colin Perkins






--089e0158adccdc6103052b085c10-- From nobody Fri Feb 5 15:57:44 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29C1B302F; Fri, 5 Feb 2016 15:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 t0RYt62cKll1; Fri, 5 Feb 2016 15:57:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D376B1B302E; Fri, 5 Feb 2016 15:57:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BD527180014; Fri, 5 Feb 2016 15:57:19 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160205235719.BD527180014@rfc-editor.org> Date: Fri, 5 Feb 2016 15:57:19 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, avtext@ietf.org, rfc-editor@rfc-editor.org Subject: [avtext] RFC 7728 on RTP Stream Pause and Resume X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 23:57:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7728 Title: RTP Stream Pause and Resume Author: B. Burman, A. Akram, R. Even, M. Westerlund Status: Standards Track Stream: IETF Date: February 2016 Mailbox: bo.burman@ericsson.com, akram.muhammadazam@gmail.com, roni.even@mail01.huawei.com, magnus.westerlund@ericsson.com Pages: 55 Characters: 135619 Updates: RFC 5104 I-D Tag: draft-ietf-avtext-rtp-stream-pause-10.txt URL: https://www.rfc-editor.org/info/rfc7728 DOI: http://dx.doi.org/10.17487/RFC7728 With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. This document is a product of the Audio/Video Transport Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Feb 8 06:22:32 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49491B2BFD for ; Mon, 8 Feb 2016 06:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no 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 nFIYT3TDt-yx for ; Mon, 8 Feb 2016 06:22:26 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 872D91B2BF0 for ; Mon, 8 Feb 2016 06:22:26 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u18EMDM8078686 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Feb 2016 08:22:14 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins , Peter Thatcher References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> From: Adam Roach Message-ID: <56B8A495.8000203@nostrum.com> Date: Mon, 8 Feb 2016 08:22:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4B67F.9050102@nostrum.com> Content-Type: multipart/alternative; boundary="------------020403090005090600090303" Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:22:30 -0000 This is a multi-part message in MIME format. --------------020403090005090600090303 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Colin -- any comment? /a On 2/5/16 08:49, Adam Roach wrote: > In the spirit of finding a compromise, I want to back up a bit and see > if we can't thread this needle a little differently. > > I'm sympathetic to Peter's concern that solutions that require > multiple identifiers in a packet or signaling-level correlation of > identifiers introduce API complexities at the top of the RTP stack, > and that these complexities bubble all the way up to the WebRTC API in > a very ugly way. > > At the same time, I share Colin's concerns that designing a solution > without consideration for future applications is needlessly > short-sighted, and may well lead us back to trying to define a new > identifier with even finer granularity in the foreseeable future. > > I propose that we retain the meaning of RID that is currently in the > document, which should satisfy Peter's concern. I want to address > Colin's concern by proposing that we add text to the document > indicating that any future applications of RID that need to identify a > Repair RTP Stream independently of its Source RTP Stream do so with a > RID plus a sub-identifier. This sub-identifier will be scoped to (and > unique within) a RID. > > And this sub-identifier will be PT. > > Yes, the purpose of defining RID is to get away from using PTs to > identify anything other than the configuration of payload types. But > the reason that such a split is necessary is that using naked PTs for > identification leads to creation of multiple PTs that represent the > same configuration, solely for the purpose of minting unique > identifiers. Since redundancy streams will already have a unique PT > within the scope of any given Source RTP Stream, this proposal does > not result in such a situation. > > > In Colin's terms: Every stream can have [an identifier] (RID+PT in > this proposal); streams that have [an identifier] can also express an > association with another [identifier] (by sharing a common RID); both > are optional (implementations that don't care about having a unique > name for redundancy streams don't need to talk about them). > > In Peter's terms: SRID = RID, and ARID = RID+PT > > Sound reasonable? > > /a > > > On 2/5/16 02:24, Colin Perkins wrote: >> My proposal is actually much simpler: every stream can have a RID; >> streams that have a RID can also express an association with another >> RID; both are optional. >> >> Colin >> >> >> >>> On 5 Feb 2016, at 02:38, Peter Thatcher wrote: >>> >>> OK, I'll try a little more detailed thought/design experiment. >>> >>> First, we're really talking about two different IDs, so let's give >>> them different names for a moment to avoid confusion: >>> >>> SRID: source RTP stream ID: can only refer to a source RTP stream ID >>> ARID: any RTP stream ID: can refer to any RTP stream ID >>> >>> >>> Now let's compare how we could use them, with two options: >>> >>> Option A (current RID draft): >>> >>> The source RTP stream's packets contain an SRID, which identifies >>> itself. >>> The redundancy RTP stream's packets contain an SRID, which is the >>> SRID of the source RTP stream that it protects. >>> >>> Option B (your idea as I understand it): >>> >>> The source RTP stream's packets contain an ARID, which identifies >>> itself. >>> The redundancy RTP stream's packets contain an ARID which identifies >>> itself, *and* an SRID, which is the ARID of the source RTP stream >>> that it protects. >>> >>> Option C (another possibility mentioned in the thread, I think): >>> >>> The source RTP stream's packets contain an ARID, which identifies >>> itself. >>> The redundancy RTP stream's packets contain an ARID which identifies >>> itself >>> The ARID of the source and redundancy streams are tied together by >>> signaling. >>> >>> >>> I don't like Option C at all. It requires too much signaling and >>> API complexity. >>> >>> However, let's go back to Option B. If make the ARID on the >>> redundancy RTP stream referring to itself optional (since it's not >>> used most of the time, why include it?), then we end up with how I >>> would use it: >>> >>> Option B2 (your idea, with the ARID optional on the redundancy stream): >>> >>> The source RTP stream's packets contain an ARID, which identifies >>> itself. >>> The redundancy RTP stream's packets contain an SRID, which is the >>> ARID of the source RTP stream that it protects (and optionally an >>> ARID which identifies itself) >>> >>> >>> Now another question: what if you get an SRID in a source RTP >>> stream? What does that mean? Well, it could only mean one thing: >>> the ID refers to the source stream itself, which means it's >>> functionally equivalent to an ARID on a source RTP stream. If this >>> were allowed, we would end up with this option: >>> >>> Option B3 (your idea, with the ARID optional on the source and >>> redundancy streams): >>> >>> The source RTP stream's packets contain an SRID (or, optionally, an >>> ARID), which identifies itself. >>> The redundancy RTP stream's packets contain an SRID, which is the >>> ARID of the source RTP stream that it protects (and optionally an >>> ARID which identifies itself) >>> >>> Now, that looks like a system that would allow me to do what I want >>> (put one SRID on both) and let you do what you want (put an ARID on >>> everything). >>> >>> >>> The SDP/API implications for this would be to basically rename every >>> instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API >>> with "srid", and then given a name to ARID (probably just "rid"). >>> Either that or leave "rid" to mean SRID and think of a new name for >>> ARID. That would be a lot less work, but I can't think of a good >>> name for the ARID. >>> >>> >>> I don't think Option B3 is worth the additional complexity, since I >>> don't think the ARID is worth having, but if the WG wants to have >>> it, then I'm not strongly opposed, as long as ARIDs are optional and >>> I can choose not to use them. >>> >>> And Option C is right out. >>> >>> I hope that helps explain my thinking. >>> >>> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote: >>> >>> >>>> On 4 Feb 2016, at 22:57, Adam Roach >>> > wrote: >>>> >>>> I don't have a strong opinion one way or another here. At this >>>> point, I hear one voice for keeping as-is, and another for >>>> giving redundancy streams their own RID (or RIDs? I don't >>>> understand the suggestion that we use a list of RIDs). >>> >>> Perhaps I didn’t explain myself well. The RID draft is trying to >>> do two things: provide a unique identifier for an RTP stream, >>> and provide an identifier which can connect a redundancy RTP >>> stream and the RTP stream it is protecting. I was suggesting >>> that these functions should be kept separate. Each stream, >>> whether original or redundancy, could optionally have a RID >>> assigned to it. The original and redundant streams would have >>> different RIDs. Each stream that has a RID assigned to it could >>> also (optionally) include a list of other RID values that it’s >>> associated with. If it’s a FEC stream, these other RID values >>> could be the stream(s) that it’s protecting; if it’s a simulcast >>> stream, they could be the other versions; if it’s a layered >>> stream, they could be the other layers, etc. Each stream >>> therefore has a unique identifier, and relationships between >>> them are explicit rather than implicit. >>> >>> (We can argue later about whether this is one SDES item with two >>> parts to it, or two SDES items; the syntax isn’t the important >>> part) >>> >>> Yes, this has slightly higher overhead (although if you care >>> about overhead that much, you probably want to rethink sending a >>> redundant video stream…). Yes, it’s perhaps slightly more >>> complex in some ways; but it’s simpler in that each stream has a >>> unique identifier that can unambiguously refer to it, whether >>> from another RTP stream or from the signalling channel, so we >>> won’t have to define yet another identifier if we later find a >>> requirement to refer to original and redundant streams >>> independently. >>> >>> Colin >>> >>> >>> >>>> Does anyone else want to weigh in? >>>> >>>> /a >>>> >>>> On 2/2/16 13:41, Peter Thatcher wrote: >>>>> >>>>> >>>>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins >>>>> wrote: >>>>> >>>>> >>>>> > On 2 Feb 2016, at 18:45, Peter Thatcher >>>>> wrote: >>>>> > >>>>> > >>>>> > >>>>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins >>>>> wrote: >>>>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox >>>>> wrote: >>>>> > > >>>>> > > Hello, AVTEXT — >>>>> > > >>>>> > > As discussed in Yokohama, Adam Roach et al have >>>>> submitted a draft on a “RID” SDES item and header >>>>> extension for identifying encoded and dependent streams. >>>>> > > >>>>> > > This is a call to see whether the AVTEXT working group >>>>> wants to take on this work as a work item (both adding a >>>>> milestone for the work and adopting the existing draft as >>>>> the starting point for a working group document). >>>>> > > >>>>> > > Please comment on the AVTEXT mailing list in the next >>>>> two weeks (by February 15, 2016). >>>>> > >>>>> > I don’t object to adopting this draft as a working group >>>>> item. >>>>> > >>>>> > However, I do think the working group should carefully >>>>> review the semantics of the RID before this is published >>>>> as an RFC. The complaint in the Introduction that none of >>>>> the previous attempts to address this problem “have the >>>>> proper ordinality to refer to an individual stream; all >>>>> such identifiers can appear in more than one stream at a >>>>> time” doesn’t align with the later requirements that main >>>>> and redundancy RTP streams have the same RID. >>>>> > >>>>> > >>>>> > ​Perhaps the introduction could be more precise by >>>>> saying "have the proper ordinality to refer to an >>>>> individual source RTP stream; all such identifiers can >>>>> appear in more than one source RTP stream"​ >>>>> > >>>>> > ​There is one RID per source RTP stream. ​​ ​The >>>>> redundancy RTP streams have the same RID as the source RTP >>>>> stream to indicate which source RTP stream they are >>>>> redundant with (or repair, or refer to, or whatever you >>>>> want to call it). It doesn’t matter how many redundancy >>>>> RTP streams there are per RID, as long as there is only >>>>> one source RTP stream. >>>>> >>>>> Perhaps, but on the principle that explicit is better than >>>>> implicit, another design might be for each stream, source >>>>> or redundancy, to have a unique RID, and for redundancy >>>>> streams to include a list of RID values that they provide >>>>> redundancy for. That way, there is no scope for confusion >>>>> between source and redundancy streams. >>>>> >>>>> >>>>> ​ When does a redundancy stream apply to more than one source >>>>> RTP stream? Flexfec is the only case I can think of, and that >>>>> already provides all of the necessary info in the payload, so >>>>> there's no need for a header extension. >>>>> >>>>> ​ And what value would an ID of a redundancy RTP stream >>>>> provide? Would anything ever refer to it? If not, let's just >>>>> not include it (it just wastes bytes). >>>>> >>>>> So let's start with your idea, remove the IDs of the >>>>> redundancy RTP streams (since no one refers to them, they have >>>>> no value, and just waste bytes). We'll also reduce the list >>>>> to a single value (since only flexfec would have a list, and >>>>> flexfec doesn't need the header extension). What are we left >>>>> with? An ID in the source RTP stream, and a reference to that >>>>> ID in the redundancy RTP streams. That sounds good to me, but >>>>> we've just gone and re-invented RID. >>>>> >>>>> So it sounds like what you're really asking for is multiple >>>>> RIDs in the redundancy RTP streams. But I don't really see a >>>>> use case for that, and on the principle of simple is better >>>>> than complex, I'd prefer a single value in the redundancy RTP >>>>> streams. >>>>> >>>>> -- >>>>> Colin Perkins >>>>> https://csperkins.org/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> avtext mailing list >>>>> avtext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/avtext >>>> >>> >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --------------020403090005090600090303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Colin -- any comment?

/a

On 2/5/16 08:49, Adam Roach wrote:
In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently.

I'm sympathetic to Peter's concern that solutions that require multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way.

At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future.

I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID.

And this sub-identifier will be PT.

Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation.


In Colin's terms: Every stream can have [an identifier] (RID+PT in this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them).

In Peter's terms: SRID = RID, and ARID = RID+PT

Sound reasonable?

/a


On 2/5/16 02:24, Colin Perkins wrote:
My proposal is actually much simpler: every stream can have a RID; streams that have a RID can also express an association with another RID; both are optional. 

Colin



On 5 Feb 2016, at 02:38, Peter Thatcher <pthatcher@google.com> wrote:

OK, I'll try a little more detailed thought/design experiment.  

First, we're really talking about two different IDs, so let's give them different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID
ARID: any RTP stream ID: can refer to any RTP stream ID


Now let's compare how we could use them, with two options:

Option A (current RID draft):

The source RTP stream's packets contain an SRID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the SRID of the source RTP stream that it protects.

Option B (your idea as I understand it):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects.

Option C (another possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself
The ARID of the source and redundancy streams are tied together by signaling.


I don't like Option C at all.  It requires too much signaling and API complexity.

However, let's go back to Option B.   If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stream):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)


Now another question: what if you get an SRID in a source RTP stream?  What does that mean?  Well, it could only mean one thing:  the ID refers to the source stream itself, which means it's functionally equivalent to an ARID on a source RTP stream.  If this were allowed, we would end up with this option:

Option B3 (your idea, with the ARID optional on the source and redundancy streams):

The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)

Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything). 


The SDP/API implications for this would be to basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", and then given a name to ARID (probably just "rid").   Either that or leave "rid" to mean SRID and think of a new name for ARID.  That would be a lot less work, but I can't think of a good name for the ARID.


I don't think Option B3 is worth the additional complexity, since I don't think the ARID is worth having, but if the WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them.  

And Option C is right out.

I hope that helps explain my thinking. 

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com> wrote:

I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).
Perhaps I didn’t explain myself well. The RID draft is trying to do two things: provide a unique identifier for an RTP stream, and provide an identifier which can connect a redundancy RTP stream and the RTP stream it is protecting. I was suggesting that these functions should be kept separate. Each stream, whether original or redundancy, could optionally have a RID assigned to it. The original and redundant streams would have different RIDs. Each stream that has a RID assigned to it could also (optionally) include a list of other RID values that it’s associated with. If it’s a FEC stream, these other RID values could be the stream(s) that it’s protecting; if it’s a simulcast stream, they could be the other versions; if it’s a layered stream, they could be the other layers, etc. Each stream therefore has a unique identifier, and relationships between them are explicit rather than implicit. 

(We can argue later about whether this is one SDES item with two parts to it, or two SDES items; the syntax isn’t the important part) 

Yes, this has slightly higher overhead (although if you care about overhead that much, you probably want to rethink sending a redundant video stream…). Yes, it’s perhaps slightly more complex in some ways; but it’s simpler in that each stream has a unique identifier that can unambiguously refer to it, whether from another RTP stream or from the signalling channel, so we won’t have to define yet another identifier if we later find a requirement to refer to original and redundant streams independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT —
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don’t object to adopting this draft as a working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem “have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time” doesn’t align with the later requirements that main and redundancy RTP streams have the same RID.
>
>
> ​Perhaps the introduction could be more precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"​
>
> ​There is one RID per source RTP stream. ​​  ​The redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn’t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

​ When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

​ And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
https://csperkins.org/







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




-- 
Colin Perkins








-- 
Colin Perkins







_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext

--------------020403090005090600090303-- From nobody Fri Feb 12 13:34:19 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850C41A8F4F for ; Fri, 12 Feb 2016 13:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 LrI2BX5hZ5cr for ; Fri, 12 Feb 2016 13:34:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C1D4E1A8F4E for ; Fri, 12 Feb 2016 13:34:15 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1CLYA9Q090739 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Feb 2016 15:34:11 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Fri, 12 Feb 2016 15:34:10 -0600 Message-ID: <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 21:34:17 -0000 I believe this version is ready to go to IETF last call. I will kick = that off shortly. I do have a couple of remaining comments for section 7, but you can = treat these along with any other IETF last call comments: -7, first paragraph: "The splicer MUST either be a mixer or a = translator..." Is the MUST really a requirement, or a statement of fact? -- third paragraph: Can you clarify the assumptions about the SRTP security association(s)? = I assume it's not end to end between the original source and the = receiver, since splicing would seem to violate integrity protection. In = particular, what assumptions allow the insertion to occur without = violating integrity protection, and do not assume the splicer has access = to the keys? Thanks! Ben. On 26 Jan 2016, at 2:27, Huangyihong (Rachel) wrote: > Dear all, > > This version tries to address the AD's comments. Please feel free to = > raise any other suggestions. Thanks. > > BR, > Rachel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, January 26, 2016 4:25 PM > To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli = > Deng > Subject: New Version Notification for = > draft-ietf-avtext-splicing-notification-04.txt > > > A new version of I-D, draft-ietf-avtext-splicing-notification-04.txt > has been successfully submitted by Rachel Huang and posted to the IETF = > repository. > > Name: draft-ietf-avtext-splicing-notification > Revision: 04 > Title: RTP/RTCP extension for RTP Splicing Notification > Document date: 2016-01-26 > Group: avtext > Pages: 19 > URL: = > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notific= ation-04.txt > Status: = > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificatio= n/ > Htmlized: = > https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-04 > Diff: = > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notifica= tion-04 > > Abstract: > Content splicing is a process that replaces the content of a main > multimedia stream with other multimedia content, and delivers the > substitutive multimedia content to the receivers for a period of > time. The splicer is designed to handle RTP splicing and needs to > know when to start and end the splicing. > > This memo defines two RTP/RTCP extensions to indicate the splicing > related information to the splicer: an RTP header extension that > conveys the information in-band and an RTCP packet that conveys the > information out-of-band. > > > > > Please note that it may take a couple of minutes from the time of = > submission until the htmlized version and diff are available at = > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Feb 12 14:02:38 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDAA1A9098; Fri, 12 Feb 2016 14:02:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160212220237.7877.39454.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 14:02:37 -0800 Archived-At: Cc: avtext@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Last Call: (RTP/RTCP extension for RTP Splicing Notification) to Proposed Standard X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:02:37 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'RTP/RTCP extension for RTP Splicing Notification' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2500/ From nobody Mon Feb 15 08:16:07 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 158261A001A; Mon, 15 Feb 2016 08:16:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215161605.11552.75565.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 08:16:05 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:16:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Header Extension for RTCP Source Description Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-03.txt Pages : 15 Date : 2016-02-15 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 15 08:32:16 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8ED1A008B for ; Mon, 15 Feb 2016 08:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 fwapR9dv_CIJ for ; Mon, 15 Feb 2016 08:32:12 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB32A1A007C for ; Mon, 15 Feb 2016 08:32:10 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1FGUGCd027694 for ; Mon, 15 Feb 2016 11:32:10 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 20ypb6bc8c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Feb 2016 11:32:10 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 15 Feb 2016 10:32:08 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Call for adoption of RID draft Thread-Index: AQHRXSB8bx88joHo3UOyBQxc1z/DH58txycA Date: Mon, 15 Feb 2016 16:32:08 +0000 Message-ID: <44EF4551-1434-40E7-A6A5-9BE973DF1329@vidyo.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> In-Reply-To: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <953D2E2E2A50064CAE8F759265BB1213@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-15_07:2016-02-15,2016-02-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602150271 Archived-At: Subject: Re: [avtext] Call for adoption of RID draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:32:14 -0000 DQo+IE9uIEZlYiAxLCAyMDE2LCBhdCAxOjQzIFBNLCBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFu QHZpZHlvLmNvbT4gd3JvdGU6DQo+IA0KPiBIZWxsbywgQVZURVhUIOKAlA0KPiANCj4gQXMgZGlz Y3Vzc2VkIGluIFlva29oYW1hLCBBZGFtIFJvYWNoIGV0IGFsIGhhdmUgc3VibWl0dGVkIGEgZHJh ZnQgb24gYSDigJxSSUTigJ0gU0RFUyBpdGVtIGFuZCBoZWFkZXIgZXh0ZW5zaW9uIGZvciBpZGVu dGlmeWluZyBlbmNvZGVkIGFuZCBkZXBlbmRlbnQgc3RyZWFtcy4NCj4gDQo+IFRoaXMgaXMgYSBj YWxsIHRvIHNlZSB3aGV0aGVyIHRoZSBBVlRFWFQgd29ya2luZyBncm91cCB3YW50cyB0byB0YWtl IG9uIHRoaXMgd29yayBhcyBhIHdvcmsgaXRlbSAoYm90aCBhZGRpbmcgYSBtaWxlc3RvbmUgZm9y IHRoZSB3b3JrIGFuZCBhZG9wdGluZyB0aGUgZXhpc3RpbmcgZHJhZnQgYXMgdGhlIHN0YXJ0aW5n IHBvaW50IGZvciBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQpLg0KPiANCj4gUGxlYXNlIGNvbW1l bnQgb24gdGhlIEFWVEVYVCBtYWlsaW5nIGxpc3QgaW4gdGhlIG5leHQgdHdvIHdlZWtzIChieSBG ZWJydWFyeSAxNSwgMjAxNikuDQoNClRoZXJlIGlzIHVuY29udGVzdGVkIGNvbnNlbnN1cyB0byBk byB0aGUgd29yayBhbmQgYWRvcHQgdGhpcyBkcmFmdC4gIEnigJlsbCB3b3JrIHdpdGggdGhlIEFE IGFuZCB0aGUgYXV0aG9ycyB0byBzZXQgYSBtaWxlc3RvbmUuDQoNCkF1dGhvcnMsIG9uY2UgdGhl IG1pbGVzdG9uZSBpcyBhcHByb3ZlZCwgcGxlYXNlIHN1Ym1pdCB5b3VyIGluZGl2aWR1YWwgc3Vi bWlzc2lvbiB1bmNoYW5nZWQgYXMgYSB3b3JraW5nIGdyb3VwIC0wMCBkcmFmdCwgYW5kIHRoZW4g Y29udGludWUgZGlzY3Vzc2lvbiBhbmQgd29yayBvbiBhbiB1cGRhdGVkIHZlcnNpb24gcmVmbGVj dGluZyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpUaGFuayB5b3UgYWxs IQ0KDQpKb25hdGhhbiBMZW5ub3gNCkFWVEVYVCBjby1jaGFpcg0KDQo= From nobody Mon Feb 15 08:45:30 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649961A8A51 for ; Mon, 15 Feb 2016 08:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Eidglt92SBqj for ; Mon, 15 Feb 2016 08:45:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D66D1A8A50 for ; Mon, 15 Feb 2016 08:45:26 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-2a-56c200a46af5 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.52.20792.4A002C65; Mon, 15 Feb 2016 17:45:24 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.119]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Mon, 15 Feb 2016 17:45:23 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt Thread-Index: AQHRaAwzIZY4kvziqEuOQ89HkLCC/p8tSGuQ Date: Mon, 15 Feb 2016 16:45:22 +0000 Message-ID: References: <20160215161605.11552.75565.idtracker@ietfa.amsl.com> In-Reply-To: <20160215161605.11552.75565.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7me4ShkNhBpduill8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXMnn2QuOCZesa6zmb2B8bhQFyMnh4SAicSXjnPMELaYxIV7 69m6GLk4hAQOM0oc/TmDCcJZwigxafcfJpAqNgENifk77jKC2CIC6hJ3pl9gA7GFBewk/l66 zg4Rt5d4c2wdC4RtJPFwfSdYL4uAqsSCOaeB4hwcvAK+Eo+67EFMIQFHiR1/JUAqOAWcJBb+ 3AE2hVFAVuL+93tgU5gFxCVuPZnPBHGngMSSPeehbhaVePn4HyuErSjx8dU+Roh6HYkFuz+x QdjaEssWvgar5xUQlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUWZSYX F+fn6eWllmxiBEbEwS2/rXYwHnzueIhRgINRiYd3w7kDYUKsiWXFlbmHGCU4mJVEeC1OHwwT 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzrvGeX2YkEB6YklqdmpqQWoRTJaJg1OqgXGukmiS/PY9 UT9yVwffZwmZI7rQzKnm9sEqk77G1TLZjVzTD1+yd9i6KLTqhyBbTkjaeo7ISQc1Ug/sUo64 cSZWb5LBXa51uXMWy86WfJStX21jySykeY7fYb6ciGbT3iWti5n+XxTdtVWxTq8nmPvSErWV r3k1F2X6B13VNrMLFFh7z/VujhJLcUaioRZzUXEiALdQMYeEAgAA Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:45:28 -0000 This version addresses the AD evaluation comments on the security section (= 6). The AD comments on starting an explicit IANA RTP header extension sub-regis= try with urn:ietf:params:rtp-hdrext:sdes as root are still open. The draft = reserves a "sub-space" of the existing registry, but establishes new rules = for the new sub-space, which may not be so obvious for anyone making additi= ons to this "sub-space" unless this is documented in IANA. Should the draft rather be explicit in requesting a new sub-registry, regis= tering...:sdes:cname, and moving the (existing) ...:sdes:mid into this sub-= registry? Further comments are welcome! /Bo B > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 15 februari 2016 17:16 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions of the = IETF. >=20 > Title : RTP Header Extension for RTCP Source Descriptio= n Items > Authors : Magnus Westerlund > Bo Burman > Roni Even > Mo Zanaty > Filename : draft-ietf-avtext-sdes-hdr-ext-03.txt > Pages : 15 > Date : 2016-02-15 >=20 > Abstract: > Source Description (SDES) items are normally transported in RTP > control protocol (RTCP). In some cases it can be beneficial to speed > up the delivery of these items. Mainly when a new source (SSRC) > joins an RTP session and the receivers needs this source's identity, > relation to other sources, or its synchronization context, all of > which may be fully or partially identified using SDES items. To > enable this optimization, this document specifies a new RTP header > extension that can carry SDES items. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-sdes-hdr-ext-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 15 09:36:37 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398121A8A64 for ; Mon, 15 Feb 2016 09:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 w3FCfU4MG9dy for ; Mon, 15 Feb 2016 09:36:35 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042971A8A20 for ; Mon, 15 Feb 2016 09:36:35 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1FHaWZp028676; Mon, 15 Feb 2016 12:36:32 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 20ypb6bdbj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2016 12:36:32 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 15 Feb 2016 11:36:30 -0600 From: Jonathan Lennox To: Bo Burman Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt Thread-Index: AQHRaAwzIZY4kvziqEuOQ89HkLCC/p8tSGuQgAB64AA= Date: Mon, 15 Feb 2016 17:36:30 +0000 Message-ID: References: <20160215161605.11552.75565.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <980244F04337FD46988101CAF9457973@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-15_09:2016-02-15,2016-02-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602150287 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:36:36 -0000 > On Feb 15, 2016, at 11:45 AM, Bo Burman wrote: >=20 > This version addresses the AD evaluation comments on the security section= (6). >=20 > The AD comments on starting an explicit IANA RTP header extension sub-reg= istry with urn:ietf:params:rtp-hdrext:sdes as root are still open. The draf= t reserves a "sub-space" of the existing registry, but establishes new rule= s for the new sub-space, which may not be so obvious for anyone making addi= tions to this "sub-space" unless this is documented in IANA. >=20 > Should the draft rather be explicit in requesting a new sub-registry, reg= istering...:sdes:cname, and moving the (existing) ...:sdes:mid into this su= b-registry? (Speaking as an individual:) This seems like a good idea to me. From nobody Mon Feb 15 12:41:33 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894961A90A6 for ; Mon, 15 Feb 2016 12:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.402 X-Spam-Level: * X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_QP_LONG_LINE=0.001] autolearn=no 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 a255lTJ1_WoD for ; Mon, 15 Feb 2016 12:41:26 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B251A8AF1 for ; Mon, 15 Feb 2016 12:41:26 -0800 (PST) Received: from [81.187.2.149] (port=37277 helo=[192.168.0.87]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aVPxQ-00087S-68; Mon, 15 Feb 2016 20:41:24 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-E0620444-9C9A-4FA8-B0FA-910E68AA07A0 Mime-Version: 1.0 (1.0) From: Colin Perkins X-Mailer: iPad Mail (13D15) In-Reply-To: <56B4B67F.9050102@nostrum.com> Date: Mon, 15 Feb 2016 20:41:13 +0000 Content-Transfer-Encoding: 7bit Message-Id: <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> To: Adam Roach X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:41:31 -0000 --Apple-Mail-E0620444-9C9A-4FA8-B0FA-910E68AA07A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Apologies for the slow reply... Having read this a few times, I'm not sure I object, but I'm also not sure I= see much benefit over the original proposal. Further perpetuating the link t= o payload type numbers seems architecturally problematic. And, while I'm sym= pathetic to WebRTC API issues, using the PT and RID combination to link stre= ams seems more likely to expose non-orthogonal and hard to work with informa= tion in the API, than exposing an additional identifier.=20 So, if I haven't convinced with my arguments, I tend to favour the original p= roposal (what's in the draft now) to the compromise below, since it leaves a= cleaner path to defining the more general identifier later, without having t= o deal with a legacy PT-linked identifier.=20 Colin > On 5 Feb 2016, at 14:49, Adam Roach wrote: >=20 > In the spirit of finding a compromise, I want to back up a bit and see if w= e can't thread this needle a little differently. >=20 > I'm sympathetic to Peter's concern that solutions that require multiple id= entifiers in a packet or signaling-level correlation of identifiers introduc= e API complexities at the top of the RTP stack, and that these complexities b= ubble all the way up to the WebRTC API in a very ugly way. >=20 > At the same time, I share Colin's concerns that designing a solution witho= ut consideration for future applications is needlessly short-sighted, and ma= y well lead us back to trying to define a new identifier with even finer gra= nularity in the foreseeable future. >=20 > I propose that we retain the meaning of RID that is currently in the docum= ent, which should satisfy Peter's concern. I want to address Colin's concern= by proposing that we add text to the document indicating that any future ap= plications of RID that need to identify a Repair RTP Stream independently of= its Source RTP Stream do so with a RID plus a sub-identifier. This sub-iden= tifier will be scoped to (and unique within) a RID. >=20 > And this sub-identifier will be PT. >=20 > Yes, the purpose of defining RID is to get away from using PTs to identify= anything other than the configuration of payload types. But the reason that= such a split is necessary is that using naked PTs for identification leads t= o creation of multiple PTs that represent the same configuration, solely for= the purpose of minting unique identifiers. Since redundancy streams will al= ready have a unique PT within the scope of any given Source RTP Stream, this= proposal does not result in such a situation. >=20 >=20 > In Colin's terms: Every stream can have [an identifier] (RID+PT in this pr= oposal); streams that have [an identifier] can also express an association w= ith another [identifier] (by sharing a common RID); both are optional (imple= mentations that don't care about having a unique name for redundancy streams= don't need to talk about them). >=20 > In Peter's terms: SRID =3D RID, and ARID =3D RID+PT >=20 > Sound reasonable? >=20 > /a >=20 >=20 >> On 2/5/16 02:24, Colin Perkins wrote: >> My proposal is actually much simpler: every stream can have a RID; stream= s that have a RID can also express an association with another RID; both are= optional.=20 >>=20 >> Colin >>=20 >>=20 >>=20 >>> On 5 Feb 2016, at 02:38, Peter Thatcher wrote: >>>=20 >>> OK, I'll try a little more detailed thought/design experiment. =20 >>>=20 >>> First, we're really talking about two different IDs, so let's give them d= ifferent names for a moment to avoid confusion: >>>=20 >>> SRID: source RTP stream ID: can only refer to a source RTP stream ID >>> ARID: any RTP stream ID: can refer to any RTP stream ID >>>=20 >>>=20 >>> Now let's compare how we could use them, with two options: >>>=20 >>> Option A (current RID draft): >>>=20 >>> The source RTP stream's packets contain an SRID, which identifies itself= . >>> The redundancy RTP stream's packets contain an SRID, which is the SRID o= f the source RTP stream that it protects. >>>=20 >>> Option B (your idea as I understand it): >>>=20 >>> The source RTP stream's packets contain an ARID, which identifies itself= . >>> The redundancy RTP stream's packets contain an ARID which identifies its= elf, *and* an SRID, which is the ARID of the source RTP stream that it prote= cts. >>>=20 >>> Option C (another possibility mentioned in the thread, I think): >>>=20 >>> The source RTP stream's packets contain an ARID, which identifies itself= . >>> The redundancy RTP stream's packets contain an ARID which identifies its= elf >>> The ARID of the source and redundancy streams are tied together by signa= ling. >>>=20 >>>=20 >>> I don't like Option C at all. It requires too much signaling and API co= mplexity. >>>=20 >>> However, let's go back to Option B. If make the ARID on the redundancy= RTP stream referring to itself optional (since it's not used most of the ti= me, why include it?), then we end up with how I would use it: >>>=20 >>> Option B2 (your idea, with the ARID optional on the redundancy stream): >>>=20 >>> The source RTP stream's packets contain an ARID, which identifies itself= . >>> The redundancy RTP stream's packets contain an SRID, which is the ARID o= f the source RTP stream that it protects (and optionally an ARID which ident= ifies itself) >>>=20 >>>=20 >>> Now another question: what if you get an SRID in a source RTP stream? W= hat does that mean? Well, it could only mean one thing: the ID refers to t= he source stream itself, which means it's functionally equivalent to an ARID= on a source RTP stream. If this were allowed, we would end up with this op= tion: >>>=20 >>> Option B3 (your idea, with the ARID optional on the source and redundanc= y streams): >>>=20 >>> The source RTP stream's packets contain an SRID (or, optionally, an ARID= ), which identifies itself. >>> The redundancy RTP stream's packets contain an SRID, which is the ARID o= f the source RTP stream that it protects (and optionally an ARID which ident= ifies itself) >>>=20 >>> Now, that looks like a system that would allow me to do what I want (put= one SRID on both) and let you do what you want (put an ARID on everything).= =20 >>>=20 >>>=20 >>> The SDP/API implications for this would be to basically rename every ins= tance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid= ", and then given a name to ARID (probably just "rid"). Either that or lea= ve "rid" to mean SRID and think of a new name for ARID. That would be a lot= less work, but I can't think of a good name for the ARID. >>>=20 >>>=20 >>> I don't think Option B3 is worth the additional complexity, since I don'= t think the ARID is worth having, but if the WG wants to have it, then I'm n= ot strongly opposed, as long as ARIDs are optional and I can choose not to u= se them. =20 >>>=20 >>> And Option C is right out. >>>=20 >>> I hope that helps explain my thinking.=20 >>>=20 >>>> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins wrote= : >>>>=20 >>>>> On 4 Feb 2016, at 22:57, Adam Roach wrote: >>>>>=20 >>>>> I don't have a strong opinion one way or another here. At this point, I= hear one voice for keeping as-is, and another for giving redundancy streams= their own RID (or RIDs? I don't understand the suggestion that we use a lis= t of RIDs). >>>>=20 >>>> Perhaps I didn=E2=80=99t explain myself well. The RID draft is trying t= o do two things: provide a unique identifier for an RTP stream, and provide a= n identifier which can connect a redundancy RTP stream and the RTP stream it= is protecting. I was suggesting that these functions should be kept separat= e. Each stream, whether original or redundancy, could optionally have a RID a= ssigned to it. The original and redundant streams would have different RIDs.= Each stream that has a RID assigned to it could also (optionally) include a= list of other RID values that it=E2=80=99s associated with. If it=E2=80=99s= a FEC stream, these other RID values could be the stream(s) that it=E2=80=99= s protecting; if it=E2=80=99s a simulcast stream, they could be the other ve= rsions; if it=E2=80=99s a layered stream, they could be the other layers, et= c. Each stream therefore has a unique identifier, and relationships between t= hem are explicit rather than implicit.=20 >>>>=20 >>>> (We can argue later about whether this is one SDES item with two parts t= o it, or two SDES items; the syntax isn=E2=80=99t the important part)=20 >>>>=20 >>>> Yes, this has slightly higher overhead (although if you care about over= head that much, you probably want to rethink sending a redundant video strea= m=E2=80=A6). Yes, it=E2=80=99s perhaps slightly more complex in some ways; b= ut it=E2=80=99s simpler in that each stream has a unique identifier that can= unambiguously refer to it, whether from another RTP stream or from the sign= alling channel, so we won=E2=80=99t have to define yet another identifier if= we later find a requirement to refer to original and redundant streams inde= pendently.=20 >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>>> Does anyone else want to weigh in? >>>>>=20 >>>>> /a >>>>>=20 >>>>>> On 2/2/16 13:41, Peter Thatcher wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins w= rote: >>>>>>>=20 >>>>>>> > On 2 Feb 2016, at 18:45, Peter Thatcher wro= te: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins w= rote: >>>>>>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox wr= ote: >>>>>>> > > >>>>>>> > > Hello, AVTEXT =E2=80=94 >>>>>>> > > >>>>>>> > > As discussed in Yokohama, Adam Roach et al have submitted a draf= t on a =E2=80=9CRID=E2=80=9D SDES item and header extension for identifying e= ncoded and dependent streams. >>>>>>> > > >>>>>>> > > This is a call to see whether the AVTEXT working group wants to t= ake on this work as a work item (both adding a milestone for the work and ad= opting the existing draft as the starting point for a working group document= ). >>>>>>> > > >>>>>>> > > Please comment on the AVTEXT mailing list in the next two weeks (= by February 15, 2016). >>>>>>> > >>>>>>> > I don=E2=80=99t object to adopting this draft as a working group i= tem. >>>>>>> > >>>>>>> > However, I do think the working group should carefully review the s= emantics of the RID before this is published as an RFC. The complaint in the= Introduction that none of the previous attempts to address this problem =E2= =80=9Chave the proper ordinality to refer to an individual stream; all such i= dentifiers can appear in more than one stream at a time=E2=80=9D doesn=E2=80= =99t align with the later requirements that main and = redundancy RTP streams have the same RID. >>>>>>> > >>>>>>> > >>>>>>> > =E2=80=8BPerhaps the introduction could be more precise by saying "= have the proper ordinality to refer to an individual source RTP stream; all s= uch identifiers can appear in more than one source RTP stream"=E2=80=8B >>>>>>> > >>>>>>> > =E2=80=8BThere is one RID per source RTP stream. =E2=80=8B=E2=80=8B= =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP st= ream to indicate which source RTP stream they are redundant with (or repair,= or refer to, or whatever you want to call it). It doesn=E2=80=99t matter h= ow many redundancy RTP streams there are per RID, as long as there is only o= ne source RTP stream. >>>>>>>=20 >>>>>>> Perhaps, but on the principle that explicit is better than implicit,= another design might be for each stream, source or redundancy, to have a un= ique RID, and for redundancy streams to include a list of RID values that th= ey provide redundancy for. That way, there is no scope for confusion between= source and redundancy streams. >>>>>>=20 >>>>>> =E2=80=8B When does a redundancy stream apply to more than one source= RTP stream? Flexfec is the only case I can think of, and that already prov= ides all of the necessary info in the payload, so there's no need for a head= er extension. =20 >>>>>>=20 >>>>>> =E2=80=8B And what value would an ID of a redundancy RTP stream provi= de? Would anything ever refer to it? If not, let's just not include it (it= just wastes bytes). >>>>>>=20 >>>>>> So let's start with your idea, remove the IDs of the redundancy RTP s= treams (since no one refers to them, they have no value, and just waste byte= s). We'll also reduce the list to a single value (since only flexfec would h= ave a list, and flexfec doesn't need the header extension). What are we lef= t with? An ID in the source RTP stream, and a reference to that ID in the r= edundancy RTP streams. That sounds good to me, but we've just gone and re-i= nvented RID. >>>>>>=20 >>>>>> So it sounds like what you're really asking for is multiple RIDs in t= he redundancy RTP streams. But I don't really see a use case for that, and o= n the principle of simple is better than complex, I'd prefer a single value i= n the redundancy RTP streams. >>>>>>=20 >>>>>>> -- >>>>>>> Colin Perkins >>>>>>> https://csperkins.org/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> avtext mailing list >>>>>> avtext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Colin Perkins >>>> https://csperkins.org/ >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >=20 --Apple-Mail-E0620444-9C9A-4FA8-B0FA-910E68AA07A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Apologies for the slow reply...

= Having read this a few times, I'm not sure I object, but I'm also not sure I= see much benefit over the original proposal. Further perpetuating the link t= o payload type numbers seems architecturally problematic. And, while I'm sym= pathetic to WebRTC API issues, using the PT and RID combination to link stre= ams seems more likely to expose non-orthogonal and hard to work with informa= tion in the API, than exposing an additional identifier. 

So, if I haven= 't convinced with my arguments, I tend to favour the original proposal (what= 's in the draft now) to the compromise below, since it leaves a cleaner path= to defining the more general identifier later, without having to deal with a= legacy PT-linked identifier. 

=
Colin



On 5 Feb 2016, at 14:49, Ada= m Roach <adam@nostrum.com> wro= te:

=20 =20 =20
In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently.

I'm sympathetic to Peter's concern that solutions that require multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way.

At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future.

I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID.

And this sub-identifier will be PT.

Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation.


In Colin's terms: Every stream can have [an identifier] (RID+PT in this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them).

In Peter's terms: SRID =3D RID, and ARID =3D RID+PT

Sound reasonable?

/a


On 2/5/16 02:24, Colin Perkins wrote:
My proposal is actually much simpler: every stream can have a RID; streams that have a RID can also express an association with another RID; both are optional. 

Colin



On 5 Feb 2016, at 02:38, Peter Thatcher <= p= thatcher@google.com> wrote:

OK, I'll try a little more detailed thought/design experiment.  

First, we're really talking about two different IDs, so let's give them different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID
ARID: any RTP stream ID: can refer to any RTP stream ID


Now let's compare how we could use them, with two options:

Option A (current RID draft):

The source RTP stream's packets contain an SRID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the SRID of the source RTP stream that it protects.

Option B (your idea as I understand it):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects.

Option C (another possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself
The ARID of the source and redundancy streams are tied together by signaling.
=


I don't like Option C at all.  It requires too much signaling and API complexity.

However, let's go back to Option B.   If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stream):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)
=


Now another question: what if you get an SRID in a source RTP stream?  What does that mean?  Well, it could only mean on= e thing:  the ID refers to the source stream itself= , which means it's functionally equivalent to an ARID on a source RTP stream.  If this were allowed, we would end up with this option:

Option B3 (your idea, with the ARID optional on the source and redundancy streams):

The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)

Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything). 


The SDP/API implications for this would be to basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", and then given a name to ARID (probably just "rid").   Either that or leave "rid" to mean SRID and think of a new name for ARID.  That would be a lot less work, but I can't think of a good name for the ARID.


I don't think Option B3 is worth the additional complexity, since I don't think the ARID is worth having, but if the WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them.  

And Option C is right out.

I hope that helps explain my thinking. 

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <csp@csperkins.org> wrote:

On 4 Feb 2016, at 22:57, Adam Roach <adam@nostrum.com&g= t; wrote:

I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).
Perhaps I didn=E2=80=99t explain mys= elf well. The RID draft is trying to do two things: provide a unique identifier for an RTP stream, and provide an identifier which can connect a redundancy RTP stream and the RTP stream it is protecting. I was suggesting that these functions should be kept separate. Each stream, whether original or redundancy, could optionally have a RID assigned to it. The original and redundant streams would have different RIDs. Each stream that has a RID assigned to it could also (optionally) include a list of other RID values that it=E2=80=99s associated with. If it=E2=80=99s a FEC stream, the= se other RID values could be the stream(s) that it=E2=80=99s protecting; if it=E2=80=99s a simulca= st stream, they could be the other versions; if it=E2=80=99s a= layered stream, they could be the other layers, etc. Each stream therefore has a unique identifier, and relationships between them are explicit rather than implicit. 

(We can argue later about whether this is one SDES item with two parts to it, or two SDES items; the syntax isn=E2=80=99t the impor= tant part) 

Yes, this has slightly higher overhead (although if you care about overhead that much, you probably want to rethink sending a redundant video stream=E2=80=A6). Yes, i= t=E2=80=99s perhaps slightly more complex in some ways; but it=E2=80=99s simpler in that each stream has a= unique identifier that can unambiguously refer to it, whether from another RTP stream or from the signalling channel, so we won=E2=80=99t have t= o define yet another identifier if we later find a requirement to refer to original and redundant streams independently. 

Colin



Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:


On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <csp@csperkins.org> wrote:

> On 2 Feb 2016, at 18:45, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <csp@csperkins.org> wrote:
> > On 1 Feb 2016, at 18:43, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >
> > Hello, AVTEXT =E2=80=94=
> >
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a =E2=80=9CRID=E2=80=9D SDES item a= nd header extension for identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).
> >
> > Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
>
> I don=E2=80=99t object to adopting this draft as a working group item.
>
> However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem =E2=80=9Cha= ve the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time=E2=80=9D doesn=E2= =80=99t align with the later requirements that main and redundancy RTP streams have the same RID.
>
>
> =E2=80=8BPerhaps the introduction could be more precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"=E2=80=8B
>
> =E2=80=8BThere is one RID p= er source RTP stream. =E2=80=8B=E2=80= =8B  =E2=80=8BThe redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It= doesn=E2=80=99t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams.

=E2=80=8B When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  

=E2=80=8B And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not= , let's just not include it (it just wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.  That sounds goo= d to me, but we've just gone and re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.

--
Colin Perkins
= ht= tps://csperkins.org/







________________________=
_______________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avt=
ext




-- 
Colin Perkins
https://csperkin= s.org/








-- 
Colin Perkins
https://csperkins.org/





=20
= --Apple-Mail-E0620444-9C9A-4FA8-B0FA-910E68AA07A0-- From nobody Tue Feb 16 13:05:13 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD791B34D5 for ; Tue, 16 Feb 2016 13:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 dQHDMZsQCNyK for ; Tue, 16 Feb 2016 13:05:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 818C41B3571 for ; Tue, 16 Feb 2016 13:05:10 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1GL528j093455 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Feb 2016 15:05:03 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> From: Adam Roach Message-ID: <56C38EFE.4030908@nostrum.com> Date: Tue, 16 Feb 2016 15:05:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> Content-Type: multipart/alternative; boundary="------------040000050900080602060906" Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 21:05:12 -0000 This is a multi-part message in MIME format. --------------040000050900080602060906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/15/16 14:41, Colin Perkins wrote: > Having read this a few times, I'm not sure I object, but I'm also not > sure I see much benefit over the original proposal. Further > perpetuating the link to payload type numbers seems architecturally > problematic. And, while I'm sympathetic to WebRTC API issues, using > the PT and RID combination to link streams seems more likely to expose > non-orthogonal and hard to work with information in the API, than > exposing an additional identifier. Okay, let me take another stab at this, then. Currently, RIDs are UTF8 identifiers, with a format like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID=TBD | length | rid ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What we're looking for is an optional way to identify individual redundant streams associated with a source stream, while also having a single identifier that includes source streams and all of their redundant streams. What if we had two variants of the RID format. If the field starts with the bits "10", then the next six bits encode the identity of the redundancy stream (scoped to the RID): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID=TBD | length |1|0| sub-rid | rid ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Aside: the choice of "10" as the distinguishing bit pattern is based on the fact that RID is a UTF8 encoded field, and no valid UTF8 string can start with that pattern] But for all other bit patterns, the entire field is the RID value (matching the current diagram in the document). This allows unique identification of individual streams for applications that require it, while imposing virtually nothing on those implementations that don't wish to perform such identification -- and it gets us away from the admittedly architecturally inelegant solution of using PT. The use of an escape bit sequence rather than a fixed field is intentional; it prevents imposing a one-byte-per-RID overhead on implementations that don't need to uniquely identify redundancy streams. Sound good? /a --------------040000050900080602060906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/15/16 14:41, Colin Perkins wrote:
Having read this a few times, I'm not sure I object, but I'm also not sure I see much benefit over the original proposal. Further perpetuating the link to payload type numbers seems architecturally problematic. And, while I'm sympathetic to WebRTC API issues, using the PT and RID combination to link streams seems more likely to expose non-orthogonal and hard to work with information in the API, than exposing an additional identifier.

Okay, let me take another stab at this, then.

Currently, RIDs are UTF8 identifiers, with a format like:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=TBD  |     length    | rid                         ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What we're looking for is an optional way to identify individual redundant streams associated with a source stream, while also having a single identifier that includes source streams and all of their redundant streams.

What if we had two variants of the RID format. If the field starts with the bits "10", then the next six bits encode the identity of the redundancy stream (scoped to the RID):

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=TBD  |     length    |1|0|  sub-rid  | rid         ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Aside: the choice of  "10" as the distinguishing bit pattern is based on the fact that RID is a UTF8 encoded field, and no valid UTF8 string can start with that pattern]

But for all other bit patterns, the entire field is the RID value (matching the current diagram in the document). This allows unique identification of individual streams for applications that require it, while imposing virtually nothing on those implementations that don't wish to perform such identification -- and it gets us away from the admittedly architecturally inelegant solution of using PT.

The use of an escape bit sequence rather than a fixed field is intentional; it prevents imposing a one-byte-per-RID overhead on implementations that don't need to uniquely identify redundancy streams.

Sound good?

/a
--------------040000050900080602060906-- From nobody Tue Feb 16 19:30:52 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F61A00DF for ; Tue, 16 Feb 2016 19:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 hQ9GQtJuIHuD for ; Tue, 16 Feb 2016 19:30:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72991A00E2 for ; Tue, 16 Feb 2016 19:30:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIR25834; Wed, 17 Feb 2016 03:30:45 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 03:30:42 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 11:30:38 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt Thread-Index: AQHRZd0jdgkvVSCpd0uA0RVEQhcYDZ8veK1Q Date: Wed, 17 Feb 2016 03:30:37 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> In-Reply-To: <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.56C3E965.016A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cdca2a1f3385c4ef27928c1b9eb4f618 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 03:30:51 -0000 Hi Ben, Thanks for moving this work forward. Please see my replies for the further comments. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Saturday, February 13, 2016 5:34 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-04.txt >=20 > I believe this version is ready to go to IETF last call. I will kick that= off shortly. >=20 > I do have a couple of remaining comments for section 7, but you can treat > these along with any other IETF last call comments: >=20 > -7, first paragraph: "The splicer MUST either be a mixer or a translator.= .." >=20 > Is the MUST really a requirement, or a statement of fact? [Rachel]: RTP protocol considers intermediate boxes at the RTP level either= as mixers or translators. So here it's a statement of fact. But I think th= at we may not need such a RFC2119 terminology in this case. Maybe change to= "can"? >=20 > -- third paragraph: >=20 > Can you clarify the assumptions about the SRTP security association(s)? > I assume it's not end to end between the original source and the receiver= , since > splicing would seem to violate integrity protection. In particular, what > assumptions allow the insertion to occur without violating integrity prot= ection, > and do not assume the splicer has access to the keys? [Rachel]: When splicer works as a translator, it doesn't have a SSRC, so it= just switches the RTP packets between main stream and substitutive stream = when splicing time comes and ends. In that a case, the splicer does not hav= e to access to the keys, it just works like a transport translator. But whe= n splicer works as a mixer like RFC FC6828 suggests, to have the splicer SS= RC so it will prevent to take out the ads based on SSRC. It need to have th= e keying information and decrypt and encrypt the payload.=20 Does the clarification makes sense to you? >=20 > Thanks! >=20 > Ben. >=20 > On 26 Jan 2016, at 2:27, Huangyihong (Rachel) wrote: >=20 > > Dear all, > > > > This version tries to address the AD's comments. Please feel free to > > raise any other suggestions. Thanks. > > > > BR, > > Rachel > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, January 26, 2016 4:25 PM > > To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli > > Deng > > Subject: New Version Notification for > > draft-ietf-avtext-splicing-notification-04.txt > > > > > > A new version of I-D, draft-ietf-avtext-splicing-notification-04.txt > > has been successfully submitted by Rachel Huang and posted to the IETF > > repository. > > > > Name: draft-ietf-avtext-splicing-notification > > Revision: 04 > > Title: RTP/RTCP extension for RTP Splicing Notification > > Document date: 2016-01-26 > > Group: avtext > > Pages: 19 > > URL: > > > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notificat= ion-04.t > xt > > Status: > > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificatio= n/ > > Htmlized: > > https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-04 > > Diff: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notifica= t > > ion-04 > > > > Abstract: > > Content splicing is a process that replaces the content of a main > > multimedia stream with other multimedia content, and delivers the > > substitutive multimedia content to the receivers for a period of time. > > The splicer is designed to handle RTP splicing and needs to know when > > to start and end the splicing. > > > > This memo defines two RTP/RTCP extensions to indicate the splicing > > related information to the splicer: an RTP header extension that > > conveys the information in-band and an RTCP packet that conveys the > > information out-of-band. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Feb 16 19:41:50 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642711A1B81 for ; Tue, 16 Feb 2016 19:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 QYgem5m92yte for ; Tue, 16 Feb 2016 19:41:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 133181A1AB6 for ; Tue, 16 Feb 2016 19:41:47 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1H3fZsj031022 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Feb 2016 21:41:35 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Tue, 16 Feb 2016 21:41:34 -0600 Message-ID: <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 03:41:49 -0000 On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: > -7, first paragraph: "The splicer MUST either be a mixer or a > translator..." >> >> Is the MUST really a requirement, or a statement of fact? > > > [Rachel]: RTP protocol considers intermediate boxes at the RTP level > either as mixers or translators. So here it's a statement of fact. But > I think that we may not need such a RFC2119 terminology in this case. > Maybe change to "can"? "can" works for me. > >> >> -- third paragraph: >> >> Can you clarify the assumptions about the SRTP security >> association(s)? >> I assume it's not end to end between the original source and the >> receiver, since >> splicing would seem to violate integrity protection. In particular, >> what >> assumptions allow the insertion to occur without violating integrity >> protection, >> and do not assume the splicer has access to the keys? > > > [Rachel]: When splicer works as a translator, it doesn't have a SSRC, > so it just switches the RTP packets between main stream and > substitutive stream when splicing time comes and ends. In that a case, > the splicer does not have to access to the keys, it just works like a > transport translator. But when splicer works as a mixer like RFC > FC6828 suggests, to have the splicer SSRC so it will prevent to take > out the ads based on SSRC. It need to have the keying information and > decrypt and encrypt the payload. > > Does the clarification makes sense to you? In the translator case, the receiver starts out receiving packets from the original source. It has the key for those packets through some mechanism (e.g. dtls-srtp or security descriptions). Then the splicer switches to the substitutive source. Presumably, these packets use different keys, since they come from a different source. How does the receiver learn of this? Or do we assume the original source and the substitutive source share keys? Thanks! Ben. From nobody Tue Feb 16 19:50:18 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B33D1ACE0B for ; Tue, 16 Feb 2016 19:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 1e-06b7RA7FA for ; Tue, 16 Feb 2016 19:50:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AF11ACE09 for ; Tue, 16 Feb 2016 19:50:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEN25005; Wed, 17 Feb 2016 03:50:10 +0000 (GMT) Received: from lhreml703-cah.china.huawei.com (10.201.5.104) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 03:50:10 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 03:50:10 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 11:50:06 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt Thread-Index: AQHRZd0jdgkvVSCpd0uA0RVEQhcYDZ8veK1Q//+frQCAAIc6oA== Date: Wed, 17 Feb 2016 03:50:05 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> In-Reply-To: <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56C3EDF3.00E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 58c2c95c34f49f92fc4b78b6bc8e30f3 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 03:50:17 -0000 Inline, please. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, February 17, 2016 11:42 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-04.txt >=20 > On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: >=20 > > -7, first paragraph: "The splicer MUST either be a mixer or a > > translator..." > >> > >> Is the MUST really a requirement, or a statement of fact? > > > > > > [Rachel]: RTP protocol considers intermediate boxes at the RTP level > > either as mixers or translators. So here it's a statement of fact. But > > I think that we may not need such a RFC2119 terminology in this case. > > Maybe change to "can"? >=20 > "can" works for me. >=20 > > > >> > >> -- third paragraph: > >> > >> Can you clarify the assumptions about the SRTP security > >> association(s)? > >> I assume it's not end to end between the original source and the > >> receiver, since splicing would seem to violate integrity protection. > >> In particular, what assumptions allow the insertion to occur without > >> violating integrity protection, and do not assume the splicer has > >> access to the keys? > > > > > > [Rachel]: When splicer works as a translator, it doesn't have a SSRC, > > so it just switches the RTP packets between main stream and > > substitutive stream when splicing time comes and ends. In that a case, > > the splicer does not have to access to the keys, it just works like a > > transport translator. But when splicer works as a mixer like RFC > > FC6828 suggests, to have the splicer SSRC so it will prevent to take > > out the ads based on SSRC. It need to have the keying information and > > decrypt and encrypt the payload. > > > > Does the clarification makes sense to you? >=20 > In the translator case, the receiver starts out receiving packets from th= e > original source. It has the key for those packets through some mechanism = (e.g. > dtls-srtp or security descriptions). Then the splicer switches to the sub= stitutive > source. Presumably, these packets use different keys, since they come fro= m a > different source. How does the receiver learn of this? Or do we assume th= e > original source and the substitutive source share keys? [Rachel]: Yes, they share the keys. I answered it once in the previous comm= ents. I copy it here: " > Does this assume both sources use the same SRTP key, or that the > receiving endpoint is aware which key to use for any given packet? Are > either ever likely to be the case? [Rachel]: Either both sources use the same SRTP key, or the splicer decrypt= s and re-encrypts with a single key. " So maybe I should clarify it in the draft? >=20 > Thanks! >=20 > Ben. From nobody Tue Feb 16 20:18:14 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324711ACE90 for ; Tue, 16 Feb 2016 20:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 k_ZEXcZ1B0vM for ; Tue, 16 Feb 2016 20:18:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 718421ACE68 for ; Tue, 16 Feb 2016 20:18:10 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1H4I24S048020 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Feb 2016 22:18:03 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Tue, 16 Feb 2016 22:18:02 -0600 Message-ID: <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 04:18:12 -0000 On 16 Feb 2016, at 21:50, Huangyihong (Rachel) wrote: > Inline, please. > > BR, > Rachel > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, February 17, 2016 11:42 AM >> To: Huangyihong (Rachel) >> Cc: avtext@ietf.org >> Subject: Re: [avtext] New Version Notification for >> draft-ietf-avtext-splicing-notification-04.txt >> >> On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: >> >>> -7, first paragraph: "The splicer MUST either be a mixer or a >>> translator..." >>>> >>>> Is the MUST really a requirement, or a statement of fact? >>> >>> >>> [Rachel]: RTP protocol considers intermediate boxes at the RTP level >>> either as mixers or translators. So here it's a statement of fact. >>> But >>> I think that we may not need such a RFC2119 terminology in this >>> case. >>> Maybe change to "can"? >> >> "can" works for me. >> >>> >>>> >>>> -- third paragraph: >>>> >>>> Can you clarify the assumptions about the SRTP security >>>> association(s)? >>>> I assume it's not end to end between the original source and the >>>> receiver, since splicing would seem to violate integrity >>>> protection. >>>> In particular, what assumptions allow the insertion to occur >>>> without >>>> violating integrity protection, and do not assume the splicer has >>>> access to the keys? >>> >>> >>> [Rachel]: When splicer works as a translator, it doesn't have a >>> SSRC, >>> so it just switches the RTP packets between main stream and >>> substitutive stream when splicing time comes and ends. In that a >>> case, >>> the splicer does not have to access to the keys, it just works like >>> a >>> transport translator. But when splicer works as a mixer like RFC >>> FC6828 suggests, to have the splicer SSRC so it will prevent to take >>> out the ads based on SSRC. It need to have the keying information >>> and >>> decrypt and encrypt the payload. >>> >>> Does the clarification makes sense to you? >> >> In the translator case, the receiver starts out receiving packets >> from the >> original source. It has the key for those packets through some >> mechanism (e.g. >> dtls-srtp or security descriptions). Then the splicer switches to the >> substitutive >> source. Presumably, these packets use different keys, since they come >> from a >> different source. How does the receiver learn of this? Or do we >> assume the >> original source and the substitutive source share keys? > > [Rachel]: Yes, they share the keys. I answered it once in the previous > comments. I copy it here: Yes, you did :-) > > " > > Does this assume both sources use the same SRTP key, or that the >> receiving endpoint is aware which key to use for any given packet? >> Are >> either ever likely to be the case? > > [Rachel]: Either both sources use the same SRTP key, or the splicer > decrypts and re-encrypts with a single key. > " > So maybe I should clarify it in the draft? > Given I keep asking the same question, others may do so also. So it's probably a good idea to clarify it. Thanks! Ben. From nobody Tue Feb 16 20:27:24 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6511A92EF for ; Tue, 16 Feb 2016 20:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 4kmxthI2JNOg for ; Tue, 16 Feb 2016 20:27:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318FE1AC39A for ; Tue, 16 Feb 2016 20:27:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIR29934; Wed, 17 Feb 2016 04:27:13 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 04:27:12 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 12:27:06 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt Thread-Index: AQHRZd0jdgkvVSCpd0uA0RVEQhcYDZ8veK1Q//+frQCAAIc6oP//gvcAgACH2+A= Date: Wed, 17 Feb 2016 04:27:05 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> In-Reply-To: <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56C3F6A2.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cdca2a1f3385c4ef27928c1b9eb4f618 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 04:27:23 -0000 All right. I'll do it together with other comments that may be produced in = the IETF last call. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, February 17, 2016 12:18 PM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-04.txt >=20 > On 16 Feb 2016, at 21:50, Huangyihong (Rachel) wrote: >=20 > > Inline, please. > > > > BR, > > Rachel > > > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: Wednesday, February 17, 2016 11:42 AM > >> To: Huangyihong (Rachel) > >> Cc: avtext@ietf.org > >> Subject: Re: [avtext] New Version Notification for > >> draft-ietf-avtext-splicing-notification-04.txt > >> > >> On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: > >> > >>> -7, first paragraph: "The splicer MUST either be a mixer or a > >>> translator..." > >>>> > >>>> Is the MUST really a requirement, or a statement of fact? > >>> > >>> > >>> [Rachel]: RTP protocol considers intermediate boxes at the RTP level > >>> either as mixers or translators. So here it's a statement of fact. > >>> But > >>> I think that we may not need such a RFC2119 terminology in this > >>> case. > >>> Maybe change to "can"? > >> > >> "can" works for me. > >> > >>> > >>>> > >>>> -- third paragraph: > >>>> > >>>> Can you clarify the assumptions about the SRTP security > >>>> association(s)? > >>>> I assume it's not end to end between the original source and the > >>>> receiver, since splicing would seem to violate integrity > >>>> protection. > >>>> In particular, what assumptions allow the insertion to occur > >>>> without violating integrity protection, and do not assume the > >>>> splicer has access to the keys? > >>> > >>> > >>> [Rachel]: When splicer works as a translator, it doesn't have a > >>> SSRC, so it just switches the RTP packets between main stream and > >>> substitutive stream when splicing time comes and ends. In that a > >>> case, the splicer does not have to access to the keys, it just works > >>> like a transport translator. But when splicer works as a mixer like > >>> RFC > >>> FC6828 suggests, to have the splicer SSRC so it will prevent to take > >>> out the ads based on SSRC. It need to have the keying information > >>> and decrypt and encrypt the payload. > >>> > >>> Does the clarification makes sense to you? > >> > >> In the translator case, the receiver starts out receiving packets > >> from the original source. It has the key for those packets through > >> some mechanism (e.g. > >> dtls-srtp or security descriptions). Then the splicer switches to the > >> substitutive source. Presumably, these packets use different keys, > >> since they come from a different source. How does the receiver learn > >> of this? Or do we assume the original source and the substitutive > >> source share keys? > > > > [Rachel]: Yes, they share the keys. I answered it once in the previous > > comments. I copy it here: >=20 > Yes, you did :-) >=20 > > > > " > > > Does this assume both sources use the same SRTP key, or that the > >> receiving endpoint is aware which key to use for any given packet? > >> Are > >> either ever likely to be the case? > > > > [Rachel]: Either both sources use the same SRTP key, or the splicer > > decrypts and re-encrypts with a single key. > > " > > So maybe I should clarify it in the draft? > > >=20 > Given I keep asking the same question, others may do so also. So it's pro= bably a > good idea to clarify it. >=20 > Thanks! >=20 > Ben. From nobody Tue Feb 16 21:57:07 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7321B2C3C for ; Tue, 16 Feb 2016 21:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 37ScQNQtwKTa for ; Tue, 16 Feb 2016 21:57:04 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 022C41B2C2B for ; Tue, 16 Feb 2016 21:57:03 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 9so24184741iom.1 for ; Tue, 16 Feb 2016 21:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YdZxkQBXwFprMYH80QGJOD1OtuSylt57J7Y96fhz5Z0=; b=h9bP0akzjG896I8Nrsx49H4e+xB5disOYtThDEzW34O1pPrpGJis+AS1PQBp6w2klC sjuivmNEhKBAyFShHZ5qGkLQ+jsyS29mwjR092QgVL8rqUWH5EaIVrtHz/WSl3NtGWrG bNdnbnhraYFSutpZmLsBs84f8zfnV/MWmG5h7fu48LsqNNUhFvnOqYc7w2CcZy8sLFTF TgQ1HlqSnQtIleKRdHuJySuFAzh7+Y7onI0S2RmmCPXXWa6D7PR9yMzAOHvpi0LOQCA9 uYmw5ebfZo+UlOHmc9lCYHeS+pmSWRswjHjTT71/112fZrVMQaHG+eTemsJCxfGxp0Bb C20g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YdZxkQBXwFprMYH80QGJOD1OtuSylt57J7Y96fhz5Z0=; b=acSbBFEPnHuLwnaI8LUC3m0M8zoCuqP47pce/1BsFZK0EdhfiC8weBuclPa6QjE+Iy pc4mFOaxaNd3RzN8JVF3cu8NKCxS1ZFYYPzePYwcOAg4zd7JU2QrY1p91UNW4kXM64Oc 5UfTF49aZdwSASfqYOVanQzmRVcATzuthREShBMdCHTyAy8T4+0dj3zyMkAUP2ZobX/c ixgwxiqf6bbFNZ4AHS5/heTNtl88FG9IZNPPhFLGT19XtiauaLnNQIQ/FHT70x2jyATS XYvIDYvngeQrkZubehaKb9M3PKWSc8QDqJkw3z/YuDJ5xexSI76A1qp3LMc3zsZGl+lJ 76RA== X-Gm-Message-State: AG10YOS9rCtsgruQOXvhBJCnly7wblg4Kes7w+tJ8WRoAhVnGrdDwypyBEKCiwSLwsK0EARri29wAnfPQbFffB5G X-Received: by 10.60.58.103 with SMTP id p7mr20342655oeq.2.1455688623071; Tue, 16 Feb 2016 21:57:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.75 with HTTP; Tue, 16 Feb 2016 21:56:23 -0800 (PST) In-Reply-To: <56C38EFE.4030908@nostrum.com> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> <56C38EFE.4030908@nostrum.com> From: Peter Thatcher Date: Tue, 16 Feb 2016 21:56:23 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e0158adcc489710052bf0ebe3 Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 05:57:05 -0000 --089e0158adcc489710052bf0ebe3 Content-Type: text/plain; charset=UTF-8 This looks like a good compromise solution to me. I like how it allows the extra ID (Redundancy RID? RRID?) to be optional without wasting space. And I think it's improvement over using PTs. On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach wrote: > On 2/15/16 14:41, Colin Perkins wrote: > > Having read this a few times, I'm not sure I object, but I'm also not sure > I see much benefit over the original proposal. Further perpetuating the > link to payload type numbers seems architecturally problematic. And, while > I'm sympathetic to WebRTC API issues, using the PT and RID combination to > link streams seems more likely to expose non-orthogonal and hard to work > with information in the API, than exposing an additional identifier. > > > Okay, let me take another stab at this, then. > > Currently, RIDs are UTF8 identifiers, with a format like: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID=TBD | length | rid ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > What we're looking for is an optional way to identify individual redundant > streams associated with a source stream, while also having a single > identifier that includes source streams and all of their redundant streams. > > What if we had two variants of the RID format. If the field starts with > the bits "10", then the next six bits encode the identity of the redundancy > stream (scoped to the RID): > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID=TBD | length |1|0| sub-rid | rid ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > [Aside: the choice of "10" as the distinguishing bit pattern is based on > the fact that RID is a UTF8 encoded field, and no valid UTF8 string can > start with that pattern] > > But for all other bit patterns, the entire field is the RID value > (matching the current diagram in the document). This allows unique > identification of individual streams for applications that require it, > while imposing virtually nothing on those implementations that don't wish > to perform such identification -- and it gets us away from the admittedly > architecturally inelegant solution of using PT. > > The use of an escape bit sequence rather than a fixed field is > intentional; it prevents imposing a one-byte-per-RID overhead on > implementations that don't need to uniquely identify redundancy streams. > > Sound good? > > /a > --089e0158adcc489710052bf0ebe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks like a good compromise solution to me.
=

I like how it allows the extra ID (Redundancy RID?=C2=A0 RR= ID?) to be optional without wasting space.=C2=A0 And I think it's impro= vement over using PTs.

On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach <adam@nos= trum.com> wrote:
=20 =20 =20
On 2/15/16 14:41, Colin Perkins wrote:
=20
Having read this a few times, I'm not sure I object, but I'm also not sure I see much benefit over th= e original proposal. Further perpetuating the link to payload type numbers seems architecturally problematic. And, while I'm sympathetic to WebRTC API issues, using the PT and RID combination to link streams seems more likely to expose non-orthogonal and hard to work with information in the API, than exposing an additional identifier.

 Okay, let me take another stab at this, then.

Currently, RIDs are UTF8 identifiers, with a format like:

=20 
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=3DTBD  |     length    | rid                         ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What we're looking for is an optional way to identify individual redundant streams associated with a source stream, while also having a single identifier that includes source streams and all of their redundant streams.

What if we had two variants of the RID format. If the field starts with the bits "10", then the next six bits encode the identit= y of the redundancy stream (scoped to the RID):

=20 
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=3DTBD  |     length    |1|0|  sub-rid  | rid         ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    [Aside: the choice of=C2=A0 "10" as the distinguishing bit pa=
ttern is
    based on the fact that RID is a UTF8 encoded field, and no valid
    UTF8 string can start with that pattern]

    

    But for all other bit patterns, the entire field is the RID value
    (matching the current diagram in the document). This allows unique
    identification of individual streams for applications that require
    it, while imposing virtually nothing on those implementations that
    don't wish to perform such identification -- and it gets us away
    from the admittedly architecturally inelegant solution of using PT.

    

    The use of an escape bit sequence rather than a fixed field is
    intentional; it prevents imposing a one-byte-per-RID overhead on
    implementations that don't need to uniquely identify redundancy
    streams.

    

    Sound good?

    

    /a

--089e0158adcc489710052bf0ebe3-- From nobody Wed Feb 17 07:27:04 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46B61A21B3 for ; Wed, 17 Feb 2016 07:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 pfvbIGDDEDhh for ; Wed, 17 Feb 2016 07:26:59 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A331A21A6 for ; Wed, 17 Feb 2016 07:26:54 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1HFPf2m024297; Wed, 17 Feb 2016 10:26:45 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 214cqcre81-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Feb 2016 10:26:45 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 17 Feb 2016 09:26:43 -0600 From: Jonathan Lennox To: Google-Peter Thatcher Thread-Topic: [avtext] Source vs redundancy stream in RID Thread-Index: AQHRX5+AzAZbCnlqvkqRbe6m7gYqtp8c9DyAgAAtnQCAAGCpAIAAa7CAgBAZj4CAAZj8AIAAlHWAgACfYgA= Date: Wed, 17 Feb 2016 15:26:42 +0000 Message-ID: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> <56C38EFE.4030908@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_A81CAC9A2C1D4761B32A09D79C3A474Cvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-17_09:2016-02-17,2016-02-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602170253 Archived-At: Cc: "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 15:27:00 -0000 --_000_A81CAC9A2C1D4761B32A09D79C3A474Cvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KFNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwuKQ0KDQpXaGlsZSB0aGUgc3ludGF4IG9mIGhlYWRl ciBleHRlbnNpb25zIGlzIHByZXR0eSBmcmVlZm9ybSwgdGhpcyBpcyBhbHNvIG1lYW50IHRvIGJl IGFuIFNERVMgaXRlbSwgYW5kIHRoZXJl4oCZcyBiZWVuIGEgcmVhc29uYWJseSBzdHJvbmcgYXNz dW1wdGlvbiB0aGF0IFNERVMgaXRlbSBjb250ZW50cyBhcmUgdmFsaWQgVVRGLTguDQoNCkFub3Ro ZXIgcG9zc2liaWxpdHkgbWlnaHQgYmUgdG8gZGVmaW5lIHR3byBTREVTIGl0ZW0gdHlwZXMgKGFu ZCB0aHVzIGhlYWRlciBleHRlbnNpb25zKTogb25lIGZvciDigJx0aGlzIGlzIHRoZSBpZGVudGl0 eSBvZiB0aGUgc3RyZWFtIEkgYW3igJ0sIGFuZCBhbm90aGVyIGZvciDigJx0aGlzIGlzIHRoZSBp ZGVudGl0eSBvZiB0aGUgc3RyZWFtIGZvciB3aGljaCBJIGFtIGEgcmVkdW5kYW50IHN0cmVhbS7i gJ0gRm9yIG91ciBjdXJyZW50IHVzZSBjYXNlcywgYW55IGdpdmVuIHN0cmVhbSB3b3VsZCBvbmx5 IGV2ZXIgbmVlZCB0byBzZW5kIG9uZSBvciB0aGUgb3RoZXIsIGJ1dCB3ZSdkIGhhdmUgdGhlIGZs ZXhpYmlsaXR5IGluIHRoZSBmdXR1cmUgdG8gZ2VuZXJhbGl6ZSB0aGF0Lg0KDQooVGhpcyBpcyBy b3VnaGx5IFBldGVy4oCZcyBBUklEL1NSSUQgcHJvcG9zYWwsIEkgdGhpbms/KQ0KDQpDb21wYXJl ZCB0byB0aGUgY3VycmVudCBwcm9wb3NhbCwgdGhpcyB3b3VsZCB1c2UgdXAgYW4gYWRkaXRpb25h bCBTREVTIGl0ZW0gdHlwZSBJRCAobm90IGEgYmlnIGRlYWwpIGFuZCBhbHNvIHJlcXVpcmUgc2Vz c2lvbnMgdG8gYWxsb2NhdGUgYW4gYWRkaXRpb25hbCBoZWFkZXIgZXh0ZW5zaW9uIElEIChwb3Rl bnRpYWxseSBtb3JlIHByb2JsZW1hdGljIGlmIHlvdeKAmXJlIHVzaW5nIHRoZSA0KzQgc2hvcnQt Zm9ybSBoZWFkZXIgZXh0ZW5zaW9uIHN5bnRheD8pLCBidXQgZG9lc27igJl0IHJlc3VsdCBpbiBh bnkgbW9yZSBiaXRzIG9uIHRoZSB3aXJlLg0KDQpUaGlzIGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ug dGhhdCB3ZeKAmXJlIG5vdCBmb3JjaW5nIHRoZSBhc3N1bXB0aW9uIHRoYXQgcGF5bG9hZCB0eXBl cyBhbHdheXMgZGlzdGluZ3Vpc2ggZW5jb2RlZCBzdHJlYW1zIGZyb20gcmVkdW5kYW50IHN0cmVh bXMuICAoSSBjb3VsZCBpbWFnaW5lIHBheWxvYWQgZm9ybWF0cyB3aGVyZSB0aGlzIHdhc27igJl0 IHRydWUsIHNheSBpZiB5b3UgaGFkIHNvbWUgc29ydCBvZiBjb2RlYy1zcGVjaWZpYyByZWR1bmRh bmN5IGluZm9ybWF0aW9uIHdoaWNoIGNvdWxkIGJlIHNlbnQgd2l0aCB0aGUgc2FtZSBwYXlsb2Fk IHR5cGUgYXMgdGhlIHByaW1hcnkgc3RyZWFtLikNCg0KT24gRmViIDE3LCAyMDE2LCBhdCAxMjo1 NiBBTSwgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNo ZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpUaGlzIGxvb2tzIGxpa2UgYSBnb29kIGNvbXByb21p c2Ugc29sdXRpb24gdG8gbWUuDQoNCkkgbGlrZSBob3cgaXQgYWxsb3dzIHRoZSBleHRyYSBJRCAo UmVkdW5kYW5jeSBSSUQ/ICBSUklEPykgdG8gYmUgb3B0aW9uYWwgd2l0aG91dCB3YXN0aW5nIHNw YWNlLiAgQW5kIEkgdGhpbmsgaXQncyBpbXByb3ZlbWVudCBvdmVyIHVzaW5nIFBUcy4NCg0KT24g VHVlLCBGZWIgMTYsIDIwMTYgYXQgMTowNSBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KT24gMi8xNS8xNiAxNDo0MSwgQ29s aW4gUGVya2lucyB3cm90ZToNCkhhdmluZyByZWFkIHRoaXMgYSBmZXcgdGltZXMsIEknbSBub3Qg c3VyZSBJIG9iamVjdCwgYnV0IEknbSBhbHNvIG5vdCBzdXJlIEkgc2VlIG11Y2ggYmVuZWZpdCBv dmVyIHRoZSBvcmlnaW5hbCBwcm9wb3NhbC4gRnVydGhlciBwZXJwZXR1YXRpbmcgdGhlIGxpbmsg dG8gcGF5bG9hZCB0eXBlIG51bWJlcnMgc2VlbXMgYXJjaGl0ZWN0dXJhbGx5IHByb2JsZW1hdGlj LiBBbmQsIHdoaWxlIEknbSBzeW1wYXRoZXRpYyB0byBXZWJSVEMgQVBJIGlzc3VlcywgdXNpbmcg dGhlIFBUIGFuZCBSSUQgY29tYmluYXRpb24gdG8gbGluayBzdHJlYW1zIHNlZW1zIG1vcmUgbGlr ZWx5IHRvIGV4cG9zZSBub24tb3J0aG9nb25hbCBhbmQgaGFyZCB0byB3b3JrIHdpdGggaW5mb3Jt YXRpb24gaW4gdGhlIEFQSSwgdGhhbiBleHBvc2luZyBhbiBhZGRpdGlvbmFsIGlkZW50aWZpZXIu DQoNCk9rYXksIGxldCBtZSB0YWtlIGFub3RoZXIgc3RhYiBhdCB0aGlzLCB0aGVuLg0KDQpDdXJy ZW50bHksIFJJRHMgYXJlIFVURjggaWRlbnRpZmllcnMsIHdpdGggYSBmb3JtYXQgbGlrZToNCg0K DQogICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgIFJJRD1UQkQg IHwgICAgIGxlbmd0aCAgICB8IHJpZCAgICAgICAgICAgICAgICAgICAgICAgICAuLi4NCiAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KDQoNCg0KV2hhdCB3ZSdyZSBsb29raW5nIGZvciBpcyBhbiBvcHRpb25hbCB3 YXkgdG8gaWRlbnRpZnkgaW5kaXZpZHVhbCByZWR1bmRhbnQgc3RyZWFtcyBhc3NvY2lhdGVkIHdp dGggYSBzb3VyY2Ugc3RyZWFtLCB3aGlsZSBhbHNvIGhhdmluZyBhIHNpbmdsZSBpZGVudGlmaWVy IHRoYXQgaW5jbHVkZXMgc291cmNlIHN0cmVhbXMgYW5kIGFsbCBvZiB0aGVpciByZWR1bmRhbnQg c3RyZWFtcy4NCg0KV2hhdCBpZiB3ZSBoYWQgdHdvIHZhcmlhbnRzIG9mIHRoZSBSSUQgZm9ybWF0 LiBJZiB0aGUgZmllbGQgc3RhcnRzIHdpdGggdGhlIGJpdHMgIjEwIiwgdGhlbiB0aGUgbmV4dCBz aXggYml0cyBlbmNvZGUgdGhlIGlkZW50aXR5IG9mIHRoZSByZWR1bmRhbmN5IHN0cmVhbSAoc2Nv cGVkIHRvIHRoZSBSSUQpOg0KDQoNCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICB8ICAgICAgUklEPVRCRCAgfCAgICAgbGVuZ3RoICAgIHwxfDB8ICBzdWItcmlkICB8IHJp ZCAgICAgICAgIC4uLg0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCltBc2lkZTogdGhlIGNob2ljZSBvZiAg IjEwIiBhcyB0aGUgZGlzdGluZ3Vpc2hpbmcgYml0IHBhdHRlcm4gaXMgYmFzZWQgb24gdGhlIGZh Y3QgdGhhdCBSSUQgaXMgYSBVVEY4IGVuY29kZWQgZmllbGQsIGFuZCBubyB2YWxpZCBVVEY4IHN0 cmluZyBjYW4gc3RhcnQgd2l0aCB0aGF0IHBhdHRlcm5dDQoNCkJ1dCBmb3IgYWxsIG90aGVyIGJp dCBwYXR0ZXJucywgdGhlIGVudGlyZSBmaWVsZCBpcyB0aGUgUklEIHZhbHVlIChtYXRjaGluZyB0 aGUgY3VycmVudCBkaWFncmFtIGluIHRoZSBkb2N1bWVudCkuIFRoaXMgYWxsb3dzIHVuaXF1ZSBp ZGVudGlmaWNhdGlvbiBvZiBpbmRpdmlkdWFsIHN0cmVhbXMgZm9yIGFwcGxpY2F0aW9ucyB0aGF0 IHJlcXVpcmUgaXQsIHdoaWxlIGltcG9zaW5nIHZpcnR1YWxseSBub3RoaW5nIG9uIHRob3NlIGlt cGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IHdpc2ggdG8gcGVyZm9ybSBzdWNoIGlkZW50aWZpY2F0 aW9uIC0tIGFuZCBpdCBnZXRzIHVzIGF3YXkgZnJvbSB0aGUgYWRtaXR0ZWRseSBhcmNoaXRlY3R1 cmFsbHkgaW5lbGVnYW50IHNvbHV0aW9uIG9mIHVzaW5nIFBULg0KDQpUaGUgdXNlIG9mIGFuIGVz Y2FwZSBiaXQgc2VxdWVuY2UgcmF0aGVyIHRoYW4gYSBmaXhlZCBmaWVsZCBpcyBpbnRlbnRpb25h bDsgaXQgcHJldmVudHMgaW1wb3NpbmcgYSBvbmUtYnl0ZS1wZXItUklEIG92ZXJoZWFkIG9uIGlt cGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IG5lZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgcmVkdW5k YW5jeSBzdHJlYW1zLg0KDQpTb3VuZCBnb29kPw0KDQovYQ0KDQoNCg== --_000_A81CAC9A2C1D4761B32A09D79C3A474Cvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4oU3BlYWtp bmcgYXMgYW4gaW5kaXZpZHVhbC4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGlsZSB0aGUgc3ludGF4IG9mIGhlYWRlciBleHRlbnNp b25zIGlzIHByZXR0eSBmcmVlZm9ybSwgdGhpcyBpcyBhbHNvIG1lYW50IHRvIGJlIGFuIFNERVMg aXRlbSwgYW5kIHRoZXJl4oCZcyBiZWVuIGEgcmVhc29uYWJseSBzdHJvbmcgYXNzdW1wdGlvbiB0 aGF0IFNERVMgaXRlbSBjb250ZW50cyBhcmUgdmFsaWQgVVRGLTguPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Bbm90aGVyIHBvc3NpYmls aXR5IG1pZ2h0IGJlIHRvIGRlZmluZSB0d28gU0RFUyBpdGVtIHR5cGVzIChhbmQgdGh1cyBoZWFk ZXIgZXh0ZW5zaW9ucyk6IG9uZSBmb3Ig4oCcdGhpcyBpcyB0aGUgaWRlbnRpdHkgb2YgdGhlIHN0 cmVhbSBJIGFt4oCdLCBhbmQgYW5vdGhlciBmb3Ig4oCcdGhpcyBpcyB0aGUgaWRlbnRpdHkgb2Yg dGhlIHN0cmVhbSBmb3Igd2hpY2ggSSBhbSBhIHJlZHVuZGFudCBzdHJlYW0u4oCdIEZvciBvdXIg Y3VycmVudA0KIHVzZSBjYXNlcywgYW55IGdpdmVuIHN0cmVhbSB3b3VsZCBvbmx5IGV2ZXIgbmVl ZCB0byBzZW5kIG9uZSBvciB0aGUgb3RoZXIsIGJ1dCB3ZSdkIGhhdmUgdGhlIGZsZXhpYmlsaXR5 IGluIHRoZSBmdXR1cmUgdG8gZ2VuZXJhbGl6ZSB0aGF0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KFRoaXMgaXMgcm91Z2hseSBQZXRl cuKAmXMgQVJJRC9TUklEIHByb3Bvc2FsLCBJIHRoaW5rPyk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNvbXBhcmVkIHRvIHRoZSBjdXJy ZW50IHByb3Bvc2FsLCB0aGlzIHdvdWxkIHVzZSB1cCBhbiBhZGRpdGlvbmFsIFNERVMgaXRlbSB0 eXBlIElEIChub3QgYSBiaWcgZGVhbCkgYW5kIGFsc28gcmVxdWlyZSBzZXNzaW9ucyB0byBhbGxv Y2F0ZSBhbiBhZGRpdGlvbmFsIGhlYWRlciBleHRlbnNpb24gSUQgKHBvdGVudGlhbGx5IG1vcmUg cHJvYmxlbWF0aWMgaWYgeW914oCZcmUgdXNpbmcgdGhlIDQmIzQzOzQgc2hvcnQtZm9ybSBoZWFk ZXINCiBleHRlbnNpb24gc3ludGF4PyksIGJ1dCBkb2VzbuKAmXQgcmVzdWx0IGluIGFueSBtb3Jl IGJpdHMgb24gdGhlIHdpcmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGFsc28gaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCB3ZeKA mXJlIG5vdCBmb3JjaW5nIHRoZSBhc3N1bXB0aW9uIHRoYXQgcGF5bG9hZCB0eXBlcyBhbHdheXMg ZGlzdGluZ3Vpc2ggZW5jb2RlZCBzdHJlYW1zIGZyb20gcmVkdW5kYW50IHN0cmVhbXMuICZuYnNw OyhJIGNvdWxkIGltYWdpbmUgcGF5bG9hZCBmb3JtYXRzIHdoZXJlIHRoaXMgd2FzbuKAmXQgdHJ1 ZSwgc2F5IGlmIHlvdSBoYWQgc29tZSBzb3J0IG9mIGNvZGVjLXNwZWNpZmljDQogcmVkdW5kYW5j eSBpbmZvcm1hdGlvbiB3aGljaCBjb3VsZCBiZSBzZW50IHdpdGggdGhlIHNhbWUgcGF5bG9hZCB0 eXBlIGFzIHRoZSBwcmltYXJ5IHN0cmVhbS4pJm5ic3A7PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IEZlYiAxNywgMjAxNiwgYXQgMTI6NTYgQU0sIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJt YWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIGNsYXNzPSIiPnB0aGF0Y2hlckBnb29nbGUuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmIj5UaGlzIGxvb2tzIGxpa2UgYSBnb29kIGNvbXByb21pc2Ugc29sdXRpb24gdG8gbWUu PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmIj5JIGxpa2UgaG93IGl0IGFsbG93cyB0aGUgZXh0cmEgSUQgKFJlZHVuZGFuY3kgUklE PyZuYnNwOyBSUklEPykgdG8gYmUgb3B0aW9uYWwgd2l0aG91dCB3YXN0aW5nIHNwYWNlLiZuYnNw OyBBbmQgSSB0aGluayBpdCdzIGltcHJvdmVtZW50IG92ZXIgdXNpbmcgUFRzLjwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIEZlYiAxNiwgMjAxNiBhdCAx OjA1IFBNLCBBZGFtIFJvYWNoIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVm PSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFkYW1A bm9zdHJ1bS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2Jv cmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1j b2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBiZ2NvbG9yPSIj RkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gMi8xNS8xNiAxNDo0MSwgQ29saW4gUGVya2lucyB3cm90ZTo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5IYXZpbmcgcmVhZCB0aGlzIGEgZmV3IHRpbWVzLCBJJ20gbm90IHN1cmUgSSBvYmplY3QsIGJ1 dCBJJ20gYWxzbyBub3Qgc3VyZSBJIHNlZSBtdWNoIGJlbmVmaXQgb3ZlciB0aGUgb3JpZ2luYWwg cHJvcG9zYWwuIEZ1cnRoZXIgcGVycGV0dWF0aW5nIHRoZSBsaW5rIHRvIHBheWxvYWQgdHlwZSBu dW1iZXJzIHNlZW1zIGFyY2hpdGVjdHVyYWxseSBwcm9ibGVtYXRpYy4gQW5kLCB3aGlsZSBJJ20g c3ltcGF0aGV0aWMgdG8gV2ViUlRDDQogQVBJIGlzc3VlcywgdXNpbmcgdGhlIFBUIGFuZCBSSUQg Y29tYmluYXRpb24gdG8gbGluayBzdHJlYW1zIHNlZW1zIG1vcmUgbGlrZWx5IHRvIGV4cG9zZSBu b24tb3J0aG9nb25hbCBhbmQgaGFyZCB0byB3b3JrIHdpdGggaW5mb3JtYXRpb24gaW4gdGhlIEFQ SSwgdGhhbiBleHBvc2luZyBhbiBhZGRpdGlvbmFsIGlkZW50aWZpZXIuPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L3NwYW4+T2theSwgbGV0IG1lIHRha2UgYW5vdGhlciBz dGFiIGF0IHRoaXMsIHRoZW4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ3VycmVudGx5 LCBSSURzIGFyZSBVVEY4IGlkZW50aWZpZXJzLCB3aXRoIGEgZm9ybWF0IGxpa2U6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iIj4gICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAg ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7DQogICAgICAgfCAgICAgIFJJRD1UQkQgIHwgICAg IGxlbmd0aCAgICB8IHJpZCAgICAgICAgICAgICAgICAgICAgICAgICAuLi4NCiAgICAgICAmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOw0KDQo8L3ByZT4NCldoYXQgd2UncmUgbG9va2luZyBmb3Ig aXMgYW4gb3B0aW9uYWwgd2F5IHRvIGlkZW50aWZ5IGluZGl2aWR1YWwgcmVkdW5kYW50IHN0cmVh bXMgYXNzb2NpYXRlZCB3aXRoIGEgc291cmNlIHN0cmVhbSwgd2hpbGUgYWxzbyBoYXZpbmcgYSBz aW5nbGUgaWRlbnRpZmllciB0aGF0IGluY2x1ZGVzIHNvdXJjZSBzdHJlYW1zIGFuZCBhbGwgb2Yg dGhlaXIgcmVkdW5kYW50IHN0cmVhbXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hh dCBpZiB3ZSBoYWQgdHdvIHZhcmlhbnRzIG9mIHRoZSBSSUQgZm9ybWF0LiBJZiB0aGUgZmllbGQg c3RhcnRzIHdpdGggdGhlIGJpdHMgJnF1b3Q7MTAmcXVvdDssIHRoZW4gdGhlIG5leHQgc2l4IGJp dHMgZW5jb2RlIHRoZSBpZGVudGl0eSBvZiB0aGUgcmVkdW5kYW5jeSBzdHJlYW0gKHNjb3BlZCB0 byB0aGUgUklEKTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSIiPiAg ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxDQogICAgICAgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsNCiAgICAgICB8 ICAgICAgUklEPVRCRCAgfCAgICAgbGVuZ3RoICAgIHwxfDB8ICBzdWItcmlkICB8IHJpZCAgICAg ICAgIC4uLg0KICAgICAgICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9wcmU+DQo8YnIgY2xh c3M9IiI+DQpbQXNpZGU6IHRoZSBjaG9pY2Ugb2YmbmJzcDsgJnF1b3Q7MTAmcXVvdDsgYXMgdGhl IGRpc3Rpbmd1aXNoaW5nIGJpdCBwYXR0ZXJuIGlzIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgUklE IGlzIGEgVVRGOCBlbmNvZGVkIGZpZWxkLCBhbmQgbm8gdmFsaWQgVVRGOCBzdHJpbmcgY2FuIHN0 YXJ0IHdpdGggdGhhdCBwYXR0ZXJuXTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ1dCBm b3IgYWxsIG90aGVyIGJpdCBwYXR0ZXJucywgdGhlIGVudGlyZSBmaWVsZCBpcyB0aGUgUklEIHZh bHVlIChtYXRjaGluZyB0aGUgY3VycmVudCBkaWFncmFtIGluIHRoZSBkb2N1bWVudCkuIFRoaXMg YWxsb3dzIHVuaXF1ZSBpZGVudGlmaWNhdGlvbiBvZiBpbmRpdmlkdWFsIHN0cmVhbXMgZm9yIGFw cGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUgaXQsIHdoaWxlIGltcG9zaW5nIHZpcnR1YWxseSBub3Ro aW5nIG9uIHRob3NlIGltcGxlbWVudGF0aW9ucw0KIHRoYXQgZG9uJ3Qgd2lzaCB0byBwZXJmb3Jt IHN1Y2ggaWRlbnRpZmljYXRpb24gLS0gYW5kIGl0IGdldHMgdXMgYXdheSBmcm9tIHRoZSBhZG1p dHRlZGx5IGFyY2hpdGVjdHVyYWxseSBpbmVsZWdhbnQgc29sdXRpb24gb2YgdXNpbmcgUFQuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHVzZSBvZiBhbiBlc2NhcGUgYml0IHNlcXVl bmNlIHJhdGhlciB0aGFuIGEgZml4ZWQgZmllbGQgaXMgaW50ZW50aW9uYWw7IGl0IHByZXZlbnRz IGltcG9zaW5nIGEgb25lLWJ5dGUtcGVyLVJJRCBvdmVyaGVhZCBvbiBpbXBsZW1lbnRhdGlvbnMg dGhhdCBkb24ndCBuZWVkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHJlZHVuZGFuY3kgc3RyZWFtcy48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTb3VuZCBnb29kPzxzcGFuIGNsYXNzPSIiPjxm b250IGNvbG9yPSIjODg4ODg4IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQovYTxiciBjbGFzcz0iIj4NCjwvZm9udD48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A81CAC9A2C1D4761B32A09D79C3A474Cvidyocom_-- From nobody Wed Feb 17 07:37:00 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EB51A06E9 for ; Wed, 17 Feb 2016 07:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 gNGKvrK1ux9a for ; Wed, 17 Feb 2016 07:36:56 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 ADEC91A19F2 for ; Wed, 17 Feb 2016 07:36:56 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id gc3so19115589obb.3 for ; Wed, 17 Feb 2016 07:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZOMly6jzmkVMt1kEP81Kxxh2mevCKaF0cqOZ/m4EOiw=; b=CKsax8X5Y5VB4krRG0I4ibHSjdypb4u8rEwj13q8fPGiLoWe4m0PmFaHodM6ixJ3FC iEa/l0munqJU0yLnfR8+hONW/5RrTouDXNYY8j+LnV05ykjOBoDRq+DtS/pterrfy69B j5vGH26m+o70Bif74Qsk7jb9ngd11aqqKIqBz2eq8iCNNtZD1TO8cDCRQ70sSbPhVSJ5 dSjerMQOjYQiETitQ/GZ59zDbrJbwdvL2aCk1XCH9IspOHjzaN33P+5sl5nmPEeycf/O HDsxGQnlWrFTrjOa8RqTHPlEQC3vu+2TM3tq7Sbim/YDOUlxRiebgnwD2ZejlOyx+yau pClQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZOMly6jzmkVMt1kEP81Kxxh2mevCKaF0cqOZ/m4EOiw=; b=kD4agW2i3UggpCHFsrQjQZLGq6EF93VDWYiKJVY74eqGjqHRna/CUXsfQl5UtUnyYH hc1jRmCMZLqotqRAugmN03udj7b/4szn8/50rQulci7/atPlbsj9Lw580yQSSFOz1xFu 4Mp8g0IprSqiftFDb957t0KTlof921sNM5uWTTkJ487wPulzi4TcIXoKxu8tHqeW6eFf GtX7dJc9SuggZ1sDaPR3DDobUbWcX3ABr5PzexL0Tdcgwd6ajWgniVrx0BkIbN9GjZxK QzVDvXGMP8q5KftFwezTimCJLaDeB5qM9MaeL994E1+aj4NQWKucF1yBmmz3FXoMUbpj bPvw== X-Gm-Message-State: AG10YOQFnliBUaNsec61WXVftIEQHeDZh1wd8qt7q3sX4mdKfSM32myb2/+IVYhS64DlQTsa+WhU4bBTztBtmDck X-Received: by 10.182.226.165 with SMTP id rt5mr1668680obc.51.1455723415093; Wed, 17 Feb 2016 07:36:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.75 with HTTP; Wed, 17 Feb 2016 07:36:15 -0800 (PST) In-Reply-To: References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> <56C38EFE.4030908@nostrum.com> From: Peter Thatcher Date: Wed, 17 Feb 2016 07:36:15 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11c2eef20c9b98052bf905d5 Archived-At: Cc: "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 15:36:59 -0000 --001a11c2eef20c9b98052bf905d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd also be happy with this design as a compromise solution. It's just a question of whether we want to signal the support of two header extensions or want to do a remember to check two bits when we implement the reading of one. I'm fine either way. On Wed, Feb 17, 2016 at 7:26 AM, Jonathan Lennox wrote= : > (Speaking as an individual.) > > While the syntax of header extensions is pretty freeform, this is also > meant to be an SDES item, and there=E2=80=99s been a reasonably strong as= sumption > that SDES item contents are valid UTF-8. > > Another possibility might be to define two SDES item types (and thus > header extensions): one for =E2=80=9Cthis is the identity of the stream I= am=E2=80=9D, and > another for =E2=80=9Cthis is the identity of the stream for which I am a = redundant > stream.=E2=80=9D For our current use cases, any given stream would only e= ver need > to send one or the other, but we'd have the flexibility in the future to > generalize that. > > (This is roughly Peter=E2=80=99s ARID/SRID proposal, I think?) > > Compared to the current proposal, this would use up an additional SDES > item type ID (not a big deal) and also require sessions to allocate an > additional header extension ID (potentially more problematic if you=E2=80= =99re > using the 4+4 short-form header extension syntax?), but doesn=E2=80=99t r= esult in > any more bits on the wire. > > This also has the advantage that we=E2=80=99re not forcing the assumption= that > payload types always distinguish encoded streams from redundant streams. > (I could imagine payload formats where this wasn=E2=80=99t true, say if y= ou had > some sort of codec-specific redundancy information which could be sent wi= th > the same payload type as the primary stream.) > > On Feb 17, 2016, at 12:56 AM, Peter Thatcher pthatcher@google.com>> wrote: > > This looks like a good compromise solution to me. > > I like how it allows the extra ID (Redundancy RID? RRID?) to be optional > without wasting space. And I think it's improvement over using PTs. > > On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach adam@nostrum.com>> wrote: > On 2/15/16 14:41, Colin Perkins wrote: > Having read this a few times, I'm not sure I object, but I'm also not sur= e > I see much benefit over the original proposal. Further perpetuating the > link to payload type numbers seems architecturally problematic. And, whil= e > I'm sympathetic to WebRTC API issues, using the PT and RID combination to > link streams seems more likely to expose non-orthogonal and hard to work > with information in the API, than exposing an additional identifier. > > Okay, let me take another stab at this, then. > > Currently, RIDs are UTF8 identifiers, with a format like: > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID=3DTBD | length | rid ..= . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What we're looking for is an optional way to identify individual redundan= t > streams associated with a source stream, while also having a single > identifier that includes source streams and all of their redundant stream= s. > > What if we had two variants of the RID format. If the field starts with > the bits "10", then the next six bits encode the identity of the redundan= cy > stream (scoped to the RID): > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID=3DTBD | length |1|0| sub-rid | rid ..= . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [Aside: the choice of "10" as the distinguishing bit pattern is based on > the fact that RID is a UTF8 encoded field, and no valid UTF8 string can > start with that pattern] > > But for all other bit patterns, the entire field is the RID value > (matching the current diagram in the document). This allows unique > identification of individual streams for applications that require it, > while imposing virtually nothing on those implementations that don't wish > to perform such identification -- and it gets us away from the admittedly > architecturally inelegant solution of using PT. > > The use of an escape bit sequence rather than a fixed field is > intentional; it prevents imposing a one-byte-per-RID overhead on > implementations that don't need to uniquely identify redundancy streams. > > Sound good? > > /a > > > --001a11c2eef20c9b98052bf905d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd also be happy with this design as a compromise = solution.

It's just a question of whether we want = to signal the support of two header extensions or want to do a remember to = check two bits when we implement the reading of one.=C2=A0 I'm fine eit= her way.

On = Wed, Feb 17, 2016 at 7:26 AM, Jonathan Lennox <jonathan@vidyo.com>= wrote:
(Speaking as an individual= .)

While the syntax of header extensions is pretty freeform, this is also mean= t to be an SDES item, and there=E2=80=99s been a reasonably strong assumpti= on that SDES item contents are valid UTF-8.

Another possibility might be to define two SDES item types (and thus header= extensions): one for =E2=80=9Cthis is the identity of the stream I am=E2= =80=9D, and another for =E2=80=9Cthis is the identity of the stream for whi= ch I am a redundant stream.=E2=80=9D For our current use cases, any given s= tream would only ever need to send one or the other, but we'd have the = flexibility in the future to generalize that.

(This is roughly Peter=E2=80=99s ARID/SRID proposal, I think?)

Compared to the current proposal, this would use up an additional SDES item= type ID (not a big deal) and also require sessions to allocate an addition= al header extension ID (potentially more problematic if you=E2=80=99re usin= g the 4+4 short-form header extension syntax?), but doesn=E2=80=99t result = in any more bits on the wire.

This also has the advantage that we=E2=80=99re not forcing the assumption t= hat payload types always distinguish encoded streams from redundant streams= .=C2=A0 (I could imagine payload formats where this wasn=E2=80=99t true, sa= y if you had some sort of codec-specific redundancy information which could= be sent with the same payload type as the primary stream.)

On Feb 17, 2016, at 12:56 AM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

This looks like a good compromise solution to me.

I like how it allows the extra ID (Redundancy RID?=C2=A0 RRID?) to be optio= nal without wasting space.=C2=A0 And I think it's improvement over usin= g PTs.

On Tue, Feb 16, 2016 at 1:05= PM, Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>>= ; wrote:
On 2/15/16 14:41, Colin Perkins wrote:
Having read this a few times, I'm not sure I object, but I'm also n= ot sure I see much benefit over the original proposal. Further perpetuating= the link to payload type numbers seems architecturally problematic. And, w= hile I'm sympathetic to WebRTC API issues, using the PT and RID combina= tion to link streams seems more likely to expose non-orthogonal and hard to= work with information in the API, than exposing an additional identifier.<= br>
Okay, let me take another stab at this, then.

Currently, RIDs are UTF8 identifiers, with a format like:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 RID=3DTBD=C2=A0 |=C2=A0 = =C2=A0 =C2=A0length=C2=A0 =C2=A0 | rid=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+



What we're looking for is an optional way to identify individual redund= ant streams associated with a source stream, while also having a single ide= ntifier that includes source streams and all of their redundant streams.
What if we had two variants of the RID format. If the field starts with the= bits "10", then the next six bits encode the identity of the red= undancy stream (scoped to the RID):


=C2=A0 =C2=A0 =C2=A0 =C2=A0 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 RID=3DTBD=C2=A0 |=C2=A0 = =C2=A0 =C2=A0length=C2=A0 =C2=A0 |1|0|=C2=A0 sub-rid=C2=A0 | rid=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+

[Aside: the choice of=C2=A0 "10" as the distinguishing bit patter= n is based on the fact that RID is a UTF8 encoded field, and no valid UTF8 = string can start with that pattern]

But for all other bit patterns, the entire field is the RID value (matching= the current diagram in the document). This allows unique identification of= individual streams for applications that require it, while imposing virtua= lly nothing on those implementations that don't wish to perform such id= entification -- and it gets us away from the admittedly architecturally ine= legant solution of using PT.

The use of an escape bit sequence rather than a fixed field is intentional;= it prevents imposing a one-byte-per-RID overhead on implementations that d= on't need to uniquely identify redundancy streams.

Sound good?

/a



--001a11c2eef20c9b98052bf905d5-- From nobody Wed Feb 17 09:55:44 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B421B29DF for ; Wed, 17 Feb 2016 09:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 s47DwbV6LPtD for ; Wed, 17 Feb 2016 09:55:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6D87A1B29D4 for ; Wed, 17 Feb 2016 09:55:41 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1HHtT5j036616 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Feb 2016 11:55:30 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Jonathan Lennox , Google-Peter Thatcher References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> <56C38EFE.4030908@nostrum.com> From: Adam Roach Message-ID: <56C4B411.5040404@nostrum.com> Date: Wed, 17 Feb 2016 11:55:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090809090909060702030302" Archived-At: Cc: "avtext@ietf.org" , Colin Perkins Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:55:43 -0000 This is a multi-part message in MIME format. --------------090809090909060702030302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/17/16 09:26, Jonathan Lennox wrote: > While the syntax of header extensions is pretty freeform, this is also > meant to be an SDES item, and there’s been a reasonably strong > assumption that SDES item contents are valid UTF-8. Okay, that's reasonably compelling. > Another possibility might be to define two SDES item types (and thus > header extensions): one for “this is the identity of the stream I am”, > and another for “this is the identity of the stream for which I am a > redundant stream.” For our current use cases, any given stream would > only ever need to send one or the other, but we'd have the flexibility > in the future to generalize that. > > (This is roughly Peter’s ARID/SRID proposal, I think?) Well, sort of. You're slicing things a little differently. In Peter's description of things, for the normal case (i.e., don't need to distinguish repair streams from their source streams), you would only need to negotiate a single extension (what he calls SRID). The only time you'd need to negotiate for the additional identifier type (what he calls ARID) would be when you *do* need to make that distinction. And there's a reasonable argument to be made that the need to make such a distinction will be quite rare. > Compared to the current proposal, this would use up an additional SDES > item type ID (not a big deal) Agreed. > and also require sessions to allocate an additional header extension > ID (potentially more problematic if you’re using the 4+4 short-form > header extension syntax?), but doesn’t result in any more bits on the > wire. Well, if we divide things up more along the lines of how Peter proposes, then we only need to allocate a single ID in most cases. I'll put together some language and add it to the document after the milestone is added to the charter. /a --------------090809090909060702030302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/17/16 09:26, Jonathan Lennox wrote:
While the syntax of header extensions is pretty freeform, this is also meant to be an SDES item, and there’s been a reasonably strong assumption that SDES item contents are valid UTF-8.

Okay, that's reasonably compelling.

Another possibility might be to define two SDES item types (and thus header extensions): one for “this is the identity of the stream I am”, and another for “this is the identity of the stream for which I am a redundant stream.” For our current use cases, any given stream would only ever need to send one or the other, but we'd have the flexibility in the future to generalize that.

(This is roughly Peter’s ARID/SRID proposal, I think?)

Well, sort of. You're slicing things a little differently. In Peter's description of things, for the normal case (i.e., don't need to distinguish repair streams from their source streams), you would only need to negotiate a single extension (what he calls SRID). The only time you'd need to negotiate for the additional identifier type (what he calls ARID) would be when you *do* need to make that distinction. And there's a reasonable argument to be made that the need to make such a distinction will be quite rare.

Compared to the current proposal, this would use up an additional SDES item type ID (not a big deal)

Agreed.

and also require sessions to allocate an additional header extension ID (potentially more problematic if you’re using the 4+4 short-form header extension syntax?), but doesn’t result in any more bits on the wire.

Well, if we divide things up more along the lines of how Peter proposes, then we only need to allocate a single ID in most cases.

I'll put together some language and add it to the document after the milestone is added to the charter.

/a
--------------090809090909060702030302-- From nobody Wed Feb 17 10:52:51 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8031B2B4B for ; Wed, 17 Feb 2016 10:05:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217180519.16281.57107.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 10:05:19 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 10:52:49 -0800 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:05:19 -0000 Changed milestone "Submit Mechanism for Identifying Encoded and Dependent Streams for Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/avtext/charter/ From nobody Wed Feb 17 15:56:02 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497361A039F for ; Wed, 17 Feb 2016 15:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 sSaOL_c5yiuo for ; Wed, 17 Feb 2016 15:55:53 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8E51A6EFE for ; Wed, 17 Feb 2016 15:55:53 -0800 (PST) Received: from [81.187.2.149] (port=36436 helo=[192.168.0.86]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aWBwf-0002K2-Os; Wed, 17 Feb 2016 23:55:47 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_C4C1D87F-B4CA-4988-99FA-51FAB54800C0" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Wed, 17 Feb 2016 23:55:42 +0000 Message-Id: <794C501E-6DC6-41ED-BC8C-FC15A4D4CC18@csperkins.org> References: <9FDD6F2C-DEB0-441F-8E6A-028A70D1D375@vidyo.com> <23AEAEFA-9C61-4802-AEEB-167FBEFA2DD2@csperkins.org> <56B3D76F.3000606@nostrum.com> <3F8C777D-8FD1-49D8-B829-B3D2725740C9@csperkins.org> <944A7ADF-3551-4F33-8DEF-2F97871204CA@csperkins.org> <56B4B67F.9050102@nostrum.com> <4983C7E8-EB63-4018-BE3C-51C66B6E1804@csperkins.org> <56C38EFE.4030908@nostrum.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Source vs redundancy stream in RID X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 23:56:01 -0000 --Apple-Mail=_C4C1D87F-B4CA-4988-99FA-51FAB54800C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Feb 2016, at 15:26, Jonathan Lennox wrote: >=20 > (Speaking as an individual.) >=20 > While the syntax of header extensions is pretty freeform, this is also = meant to be an SDES item, and there=E2=80=99s been a reasonably strong = assumption that SDES item contents are valid UTF-8. Right. RFC 3550, section 6.5, says the text in SDES items =E2=80=9Cis = encoded according to the UTF-8 encoding=E2=80=9D. > Another possibility might be to define two SDES item types (and thus = header extensions): one for =E2=80=9Cthis is the identity of the stream = I am=E2=80=9D, and another for =E2=80=9Cthis is the identity of the = stream for which I am a redundant stream.=E2=80=9D For our current use = cases, any given stream would only ever need to send one or the other, = but we'd have the flexibility in the future to generalize that. >=20 > (This is roughly Peter=E2=80=99s ARID/SRID proposal, I think?) That seems reasonable, yes, provided there would be the option for the = redundant stream to include both SDES items, if there=E2=80=99s a need = to explicitly identify the redundant stream, as well as the original = stream for which it=E2=80=99s providing redundancy. Colin > Compared to the current proposal, this would use up an additional SDES = item type ID (not a big deal) and also require sessions to allocate an = additional header extension ID (potentially more problematic if you=E2=80=99= re using the 4+4 short-form header extension syntax?), but doesn=E2=80=99t= result in any more bits on the wire. >=20 > This also has the advantage that we=E2=80=99re not forcing the = assumption that payload types always distinguish encoded streams from = redundant streams. (I could imagine payload formats where this wasn=E2=80= =99t true, say if you had some sort of codec-specific redundancy = information which could be sent with the same payload type as the = primary stream.)=20 >=20 >> On Feb 17, 2016, at 12:56 AM, Peter Thatcher > wrote: >>=20 >> This looks like a good compromise solution to me. >>=20 >> I like how it allows the extra ID (Redundancy RID? RRID?) to be = optional without wasting space. And I think it's improvement over using = PTs. >>=20 >> On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach > wrote: >> On 2/15/16 14:41, Colin Perkins wrote: >>> Having read this a few times, I'm not sure I object, but I'm also = not sure I see much benefit over the original proposal. Further = perpetuating the link to payload type numbers seems architecturally = problematic. And, while I'm sympathetic to WebRTC API issues, using the = PT and RID combination to link streams seems more likely to expose = non-orthogonal and hard to work with information in the API, than = exposing an additional identifier. >>=20 >> Okay, let me take another stab at this, then. >>=20 >> Currently, RIDs are UTF8 identifiers, with a format like: >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | RID=3DTBD | length | rid = ... >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> What we're looking for is an optional way to identify individual = redundant streams associated with a source stream, while also having a = single identifier that includes source streams and all of their = redundant streams. >>=20 >> What if we had two variants of the RID format. If the field starts = with the bits "10", then the next six bits encode the identity of the = redundancy stream (scoped to the RID): >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | RID=3DTBD | length |1|0| sub-rid | rid = ... >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> [Aside: the choice of "10" as the distinguishing bit pattern is = based on the fact that RID is a UTF8 encoded field, and no valid UTF8 = string can start with that pattern] >>=20 >> But for all other bit patterns, the entire field is the RID value = (matching the current diagram in the document). This allows unique = identification of individual streams for applications that require it, = while imposing virtually nothing on those implementations that don't = wish to perform such identification -- and it gets us away from the = admittedly architecturally inelegant solution of using PT. >>=20 >> The use of an escape bit sequence rather than a fixed field is = intentional; it prevents imposing a one-byte-per-RID overhead on = implementations that don't need to uniquely identify redundancy streams. >>=20 >> Sound good? >>=20 >> /a >>=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_C4C1D87F-B4CA-4988-99FA-51FAB54800C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 17 Feb 2016, at 15:26, Jonathan Lennox <jonathan@vidyo.com> = wrote:

(Speaking as an individual.)

While the syntax of header extensions is pretty = freeform, this is also meant to be an SDES item, and there=E2=80=99s = been a reasonably strong assumption that SDES item contents are valid = UTF-8.

Right. = RFC 3550, section 6.5, says the text in SDES items =E2=80=9Cis encoded = according to the UTF-8 encoding=E2=80=9D.

Another possibility might be to define two SDES item = types (and thus header extensions): one for =E2=80=9Cthis is the = identity of the stream I am=E2=80=9D, and another for =E2=80=9Cthis is = the identity of the stream for which I am a redundant stream.=E2=80=9D = For our current use cases, any given stream would only ever need to send one or the = other, but we'd have the flexibility in the future to generalize = that.

(This is roughly Peter=E2=80=99s ARID/SRID proposal, I = think?)

That = seems reasonable, yes, provided there would be the option for the = redundant stream to include both SDES items, if there=E2=80=99s a need = to explicitly identify the redundant stream, as well as the original = stream for which it=E2=80=99s providing redundancy.

Colin



Compared to the current proposal, this would use up an = additional SDES item type ID (not a big deal) and also require sessions = to allocate an additional header extension ID (potentially more = problematic if you=E2=80=99re using the 4+4 short-form header extension syntax?), but doesn=E2=80=99t result in any more bits on the = wire.

This also has the advantage that we=E2=80=99re not = forcing the assumption that payload types always distinguish encoded = streams from redundant streams.  (I could imagine payload formats = where this wasn=E2=80=99t true, say if you had some sort of = codec-specific redundancy information which could be sent with the same payload type = as the primary stream.) 

On Feb 17, 2016, at 12:56 AM, Peter Thatcher <pthatcher@google.com> wrote:

This looks like a good = compromise solution to me.

I like how it allows = the extra ID (Redundancy RID?  RRID?) to be optional without = wasting space.  And I think it's improvement over using PTs.

On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach = <adam@nostrum.com> wrote:
On 2/15/16 14:41, Colin Perkins wrote:
Having read this a few times, I'm not sure I object, but = I'm also not sure I see much benefit over the original proposal. Further = perpetuating the link to payload type numbers seems architecturally = problematic. And, while I'm sympathetic to WebRTC API issues, using the PT and RID combination to link streams seems more = likely to expose non-orthogonal and hard to work with information in the = API, than exposing an additional identifier.

Okay, let me take another stab at this, then.

Currently, RIDs are UTF8 identifiers, with a format like:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=3DTBD  |     length    | rid                         =
...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What we're looking for is an optional way to identify individual = redundant streams associated with a source stream, while also having a = single identifier that includes source streams and all of their = redundant streams.

What if we had two variants of the RID format. If the field starts with = the bits "10", then the next six bits encode the identity of the = redundancy stream (scoped to the RID):

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=3DTBD  |     length    |1|0|  sub-rid  | rid         =
...
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Aside: the choice of  "10" as the distinguishing bit pattern is = based on the fact that RID is a UTF8 encoded field, and no valid UTF8 = string can start with that pattern]

But for all other bit patterns, the entire field is the RID value = (matching the current diagram in the document). This allows unique = identification of individual streams for applications that require it, = while imposing virtually nothing on those implementations that don't wish to perform such identification -- and it gets us away = from the admittedly architecturally inelegant solution of using PT.

The use of an escape bit sequence rather than a fixed field is = intentional; it prevents imposing a one-byte-per-RID overhead on = implementations that don't need to uniquely identify redundancy = streams.

Sound good?

/a


_______________________________________________
avtext = mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext



-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_C4C1D87F-B4CA-4988-99FA-51FAB54800C0-- From nobody Thu Feb 18 12:38:45 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190E51B2BFB; Thu, 18 Feb 2016 12:38:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218203837.12654.98641.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 12:38:37 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:38:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Stream Identifier (RID) Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-00.txt Pages : 6 Date : 2016-02-18 Abstract: This document defines and registers an RTCP SDES item, RID, for identification of RTP streams associated with Encoded Streams and Dependent Streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 18 13:06:34 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6150E1AC42A for ; Thu, 18 Feb 2016 13:06:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218210631.31676.62136.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 13:06:31 -0800 From: IETF Secretariat Archived-At: Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 21:06:31 -0000 Changed milestone "Submit Mechanism for Identifying Encoded and Dependent Streams for Proposed Standard", added draft-ietf-avtext-rid to milestone. URL: https://datatracker.ietf.org/wg/avtext/charter/ From nobody Fri Feb 19 14:50:09 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045281B3591 for ; Fri, 19 Feb 2016 14:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 HsnHUwFWINqt for ; Fri, 19 Feb 2016 14:50:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5E3E01B3593 for ; Fri, 19 Feb 2016 14:50:06 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1JMo102036909 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Feb 2016 16:50:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Bo Burman" Date: Fri, 19 Feb 2016 16:50:01 -0600 Message-ID: <4ACD5A4E-5A84-4455-A14E-3DDF7523C0EA@nostrum.com> In-Reply-To: References: <20160215161605.11552.75565.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:50:08 -0000 Hi, For the record, I think this version will be ready for working group last call as soon as people close on this issue. Thanks! Ben. On 15 Feb 2016, at 10:45, Bo Burman wrote: > This version addresses the AD evaluation comments on the security > section (6). > > The AD comments on starting an explicit IANA RTP header extension > sub-registry with urn:ietf:params:rtp-hdrext:sdes as root are still > open. The draft reserves a "sub-space" of the existing registry, but > establishes new rules for the new sub-space, which may not be so > obvious for anyone making additions to this "sub-space" unless this is > documented in IANA. > > Should the draft rather be explicit in requesting a new sub-registry, > registering...:sdes:cname, and moving the (existing) ...:sdes:mid into > this sub-registry? > > Further comments are welcome! > > /Bo B > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: den 15 februari 2016 17:16 >> To: i-d-announce@ietf.org >> Cc: avtext@ietf.org >> Subject: I-D Action: draft-ietf-avtext-sdes-hdr-ext-03.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Audio/Video Transport Extensions of >> the IETF. >> >> Title : RTP Header Extension for RTCP Source >> Description Items >> Authors : Magnus Westerlund >> Bo Burman >> Roni Even >> Mo Zanaty >> Filename : draft-ietf-avtext-sdes-hdr-ext-03.txt >> Pages : 15 >> Date : 2016-02-15 >> >> Abstract: >> Source Description (SDES) items are normally transported in RTP >> control protocol (RTCP). In some cases it can be beneficial to speed >> up the delivery of these items. Mainly when a new source (SSRC) >> joins an RTP session and the receivers needs this source's identity, >> relation to other sources, or its synchronization context, all of >> which may be fully or partially identified using SDES items. To >> enable this optimization, this document specifies a new RTP header >> extension that can carry SDES items. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are >> available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Feb 22 00:36:19 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 398411A7032; Mon, 22 Feb 2016 00:36:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> Date: Mon, 22 Feb 2016 00:36:18 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:36:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Header Extension for RTCP Source Description Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-04.txt Pages : 15 Date : 2016-02-22 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 00:44:27 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678A51B2A3E; Mon, 22 Feb 2016 00:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 Z4Gt7YG1u_7W; Mon, 22 Feb 2016 00:44:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8F41B2A6C; Mon, 22 Feb 2016 00:44:23 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-63-56caca658a3c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 43.B3.02707.56ACAC65; Mon, 22 Feb 2016 09:44:22 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.142]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 09:44:21 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt Thread-Index: AQHRbUwb3uk6Zivzrk2Loi3MEbwNqp83vbfw Date: Mon, 22 Feb 2016 08:44:21 +0000 Message-ID: References: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> In-Reply-To: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9RDft1Kkwg7sH2S0+3rvBajFjygFm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlXHs6naXgikjF8mdTGRsY+wS6GDk5JARMJL792sEC YYtJXLi3nq2LkYtDSOAwo8SUrglQzhJGiVUv7rOCVLEJaEjM33GXEcQWEVCXuDP9AhuIzSyQ KDH/Ty9YjbCAu8THHW1MEDUeEn96VgLVcADZRhJTZ6WBmCwCqhLzblqCVPAK+ErsvHCfGcQW EnCUeDmvCWw6p4CTxOeOu2C3MQrIStz/fo8FYpO4xK0n85kgbhaQWLLnPDOELSrx8vE/Vghb UeLq9OVMEPU6Egt2f4K6Ulti2cLXzBB7BSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjKLF qcVJuelGRnqpRZnJxcX5eXp5qSWbGIExc3DLb4MdjC+fOx5iFOBgVOLhNeA8FSbEmlhWXJl7 iFGCg1lJhHfrUaAQb0piZVVqUX58UWlOavEhRmkOFiVx3tXO68OEBNITS1KzU1MLUotgskwc nFINjNlX4ld8WV98bUaifiJr6e+JuxcnTq0XtF93c37G8ugHjKmusXPK757XsVi0MeJk/037 Nf1XFKZVP7azlItNMP3Ge7L9vo4gq2THzuc3pqycd7jsnJ3Tve0sL8RniHVOuWI7r/HBWZ/3 +bcWrFl1jLlY2kV/ZcnLV7trvi95tUVKXf3Rk03vM3iUWIozEg21mIuKEwG41Z82lQIAAA== Archived-At: Cc: "draft-ietf-avtext-sdes-hdr-ext.all@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:44:26 -0000 This update addresses the AD comment on explicitly requesting an IANA sub-r= egistry for the urn:ietf:params:rtp-hdrext:sdes sub-space, with the additio= nal RTCP SDES concerns described in this draft, compared to what is already= described for urn:ietf:params:rtp-hdrext. It also addresses the AD comment= on receiver actions for section 4.2.6, which was accidentally omitted from= the previous version. Cheers, /Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org > Sent: den 22 februari 2016 09:36 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions of the = IETF. >=20 > Title : RTP Header Extension for RTCP Source Descriptio= n Items > Authors : Magnus Westerlund > Bo Burman > Roni Even > Mo Zanaty > Filename : draft-ietf-avtext-sdes-hdr-ext-04.txt > Pages : 15 > Date : 2016-02-22 >=20 > Abstract: > Source Description (SDES) items are normally transported in RTP > control protocol (RTCP). In some cases it can be beneficial to speed > up the delivery of these items. Mainly when a new source (SSRC) > joins an RTP session and the receivers needs this source's identity, > relation to other sources, or its synchronization context, all of > which may be fully or partially identified using SDES items. To > enable this optimization, this document specifies a new RTP header > extension that can carry SDES items. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-sdes-hdr-ext-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Feb 29 13:05:58 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210721B3C1E; Mon, 29 Feb 2016 13:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 KZM6OJDe8Bwc; Mon, 29 Feb 2016 13:05:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3B7121B3C1C; Mon, 29 Feb 2016 13:05:54 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1TL5n1j046142 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Feb 2016 15:05:50 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Bo Burman" Date: Mon, 29 Feb 2016 15:05:48 -0600 Message-ID: In-Reply-To: References: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "draft-ietf-avtext-sdes-hdr-ext.all@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 21:05:56 -0000 Hi, I think this version is almost ready to progress, but I do have some minor comments about the new IANA section. Since the IETF last call prompts IANA to start their review and plan their updates, and it might be confusing to have IANA consideration updates while this is in progress, we probably need to resolve this before last call. -- 5.1, paragraph 5: The text says "IANA is requested to register the below in the RTP Compact Header Extensions: Extensions, and to create the corresponding sub-registry:" But nothing in the rest of the section appears to describe the creation of the sub-registry. Now, I think you've given most the information needed in 5.0, but that section reads like a summary rather than an actual request for action. I propose a slight rearrangement, along the lines of the following: 5.0: Summary 5.1: registration of the URN. 5.2: Creation of the sub registry. (The sub-registry probably needs a human-readable name in addition to the URN.) 5.3: -- 5.2, last paragraph The RFC editor does not move things in IANA registries. IANA does that. I suggest the following: OLD RFC-editor note: Please move the MID SDES item already registered in the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to the newly formed RTP SDES Compact Header Extensions. NEW IANA is also requested to move the MID SDES item already registered in the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to the newly formed RTP SDES Compact Header Extensions. On 22 Feb 2016, at 2:44, Bo Burman wrote: > This update addresses the AD comment on explicitly requesting an IANA > sub-registry for the urn:ietf:params:rtp-hdrext:sdes sub-space, with > the additional RTCP SDES concerns described in this draft, compared to > what is already described for urn:ietf:params:rtp-hdrext. It also > addresses the AD comment on receiver actions for section 4.2.6, which > was accidentally omitted from the previous version. > > Cheers, > /Bo > >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: den 22 februari 2016 09:36 >> To: i-d-announce@ietf.org >> Cc: avtext@ietf.org >> Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Audio/Video Transport Extensions of >> the IETF. >> >> Title : RTP Header Extension for RTCP Source >> Description Items >> Authors : Magnus Westerlund >> Bo Burman >> Roni Even >> Mo Zanaty >> Filename : draft-ietf-avtext-sdes-hdr-ext-04.txt >> Pages : 15 >> Date : 2016-02-22 >> >> Abstract: >> Source Description (SDES) items are normally transported in RTP >> control protocol (RTCP). In some cases it can be beneficial to >> speed >> up the delivery of these items. Mainly when a new source (SSRC) >> joins an RTP session and the receivers needs this source's >> identity, >> relation to other sources, or its synchronization context, all of >> which may be fully or partially identified using SDES items. To >> enable this optimization, this document specifies a new RTP header >> extension that can carry SDES items. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are >> available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Feb 29 18:09:19 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19E1A8A08 for ; Mon, 29 Feb 2016 18:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 obQsPzIBxw9w for ; Mon, 29 Feb 2016 18:09:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B36AA1A8A01 for ; Mon, 29 Feb 2016 18:09:15 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u21298JS079798 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Feb 2016 20:09:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Mon, 29 Feb 2016 20:09:07 -0600 Message-ID: <65662848-DB29-48EE-8F88-C574B3A692A8@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 02:09:17 -0000 Hi, The last call is complete. The only feedback I saw (I might have missed something) was from the IANA review. Have the authors responded to that? Do you plan an update before the IESG evaluation? Thanks! Ben. On 16 Feb 2016, at 22:27, Huangyihong (Rachel) wrote: > All right. I'll do it together with other comments that may be > produced in the IETF last call. > > BR, > Rachel > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, February 17, 2016 12:18 PM >> To: Huangyihong (Rachel) >> Cc: avtext@ietf.org >> Subject: Re: [avtext] New Version Notification for >> draft-ietf-avtext-splicing-notification-04.txt >> >> On 16 Feb 2016, at 21:50, Huangyihong (Rachel) wrote: >> >>> Inline, please. >>> >>> BR, >>> Rachel >>> >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Wednesday, February 17, 2016 11:42 AM >>>> To: Huangyihong (Rachel) >>>> Cc: avtext@ietf.org >>>> Subject: Re: [avtext] New Version Notification for >>>> draft-ietf-avtext-splicing-notification-04.txt >>>> >>>> On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: >>>> >>>>> -7, first paragraph: "The splicer MUST either be a mixer or a >>>>> translator..." >>>>>> >>>>>> Is the MUST really a requirement, or a statement of fact? >>>>> >>>>> >>>>> [Rachel]: RTP protocol considers intermediate boxes at the RTP >>>>> level >>>>> either as mixers or translators. So here it's a statement of fact. >>>>> But >>>>> I think that we may not need such a RFC2119 terminology in this >>>>> case. >>>>> Maybe change to "can"? >>>> >>>> "can" works for me. >>>> >>>>> >>>>>> >>>>>> -- third paragraph: >>>>>> >>>>>> Can you clarify the assumptions about the SRTP security >>>>>> association(s)? >>>>>> I assume it's not end to end between the original source and the >>>>>> receiver, since splicing would seem to violate integrity >>>>>> protection. >>>>>> In particular, what assumptions allow the insertion to occur >>>>>> without violating integrity protection, and do not assume the >>>>>> splicer has access to the keys? >>>>> >>>>> >>>>> [Rachel]: When splicer works as a translator, it doesn't have a >>>>> SSRC, so it just switches the RTP packets between main stream and >>>>> substitutive stream when splicing time comes and ends. In that a >>>>> case, the splicer does not have to access to the keys, it just >>>>> works >>>>> like a transport translator. But when splicer works as a mixer >>>>> like >>>>> RFC >>>>> FC6828 suggests, to have the splicer SSRC so it will prevent to >>>>> take >>>>> out the ads based on SSRC. It need to have the keying information >>>>> and decrypt and encrypt the payload. >>>>> >>>>> Does the clarification makes sense to you? >>>> >>>> In the translator case, the receiver starts out receiving packets >>>> from the original source. It has the key for those packets through >>>> some mechanism (e.g. >>>> dtls-srtp or security descriptions). Then the splicer switches to >>>> the >>>> substitutive source. Presumably, these packets use different keys, >>>> since they come from a different source. How does the receiver >>>> learn >>>> of this? Or do we assume the original source and the substitutive >>>> source share keys? >>> >>> [Rachel]: Yes, they share the keys. I answered it once in the >>> previous >>> comments. I copy it here: >> >> Yes, you did :-) >> >>> >>> " >>>> Does this assume both sources use the same SRTP key, or that the >>>> receiving endpoint is aware which key to use for any given packet? >>>> Are >>>> either ever likely to be the case? >>> >>> [Rachel]: Either both sources use the same SRTP key, or the splicer >>> decrypts and re-encrypts with a single key. >>> " >>> So maybe I should clarify it in the draft? >>> >> >> Given I keep asking the same question, others may do so also. So it's >> probably a >> good idea to clarify it. >> >> Thanks! >> >> Ben. From nobody Mon Feb 29 18:27:51 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0041A8A98 for ; Mon, 29 Feb 2016 18:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 Y96i1MvONH2D for ; Mon, 29 Feb 2016 18:27:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBDB1A8A96 for ; Mon, 29 Feb 2016 18:27:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJI71395; Tue, 01 Mar 2016 02:27:44 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Mar 2016 02:27:43 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 1 Mar 2016 10:27:35 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt Thread-Index: AQHRZd0jdgkvVSCpd0uA0RVEQhcYDZ8veK1Q//+frQCAAIc6oP//gvcAgACH2+CAE8JvgIAAh1Pw Date: Tue, 1 Mar 2016 02:27:34 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E8BBBE@nkgeml513-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> <65662848-DB29-48EE-8F88-C574B3A692A8@nostrum.com> In-Reply-To: <65662848-DB29-48EE-8F88-C574B3A692A8@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56D4FE20.007F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cdca2a1f3385c4ef27928c1b9eb4f618 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 02:27:50 -0000 Hi Ben, We author did receive IANA review. But there's no comments in that review. = It was just to confirm the actions that need IANA to complete. And I think = it requires us to respond only when any action they are going to take is no= t accurate.=20 They also said these actions need to be evaluated by experts reviews via a = separate request. However, we haven't seen any expert review comments from = then on. Maybe they forgot to copy us or maybe there's no comments at all. = We're not sure about it. It's okay for us to bring an update one before the IESG evaluation to addre= ss the further issues you raised before. What do you think? BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, March 01, 2016 10:09 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-04.txt >=20 > Hi, >=20 > The last call is complete. The only feedback I saw (I might have missed > something) was from the IANA review. Have the authors responded to that? > Do you plan an update before the IESG evaluation? >=20 > Thanks! >=20 > Ben. >=20 > On 16 Feb 2016, at 22:27, Huangyihong (Rachel) wrote: >=20 > > All right. I'll do it together with other comments that may be > > produced in the IETF last call. > > > > BR, > > Rachel > > > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: Wednesday, February 17, 2016 12:18 PM > >> To: Huangyihong (Rachel) > >> Cc: avtext@ietf.org > >> Subject: Re: [avtext] New Version Notification for > >> draft-ietf-avtext-splicing-notification-04.txt > >> > >> On 16 Feb 2016, at 21:50, Huangyihong (Rachel) wrote: > >> > >>> Inline, please. > >>> > >>> BR, > >>> Rachel > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ben Campbell [mailto:ben@nostrum.com] > >>>> Sent: Wednesday, February 17, 2016 11:42 AM > >>>> To: Huangyihong (Rachel) > >>>> Cc: avtext@ietf.org > >>>> Subject: Re: [avtext] New Version Notification for > >>>> draft-ietf-avtext-splicing-notification-04.txt > >>>> > >>>> On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote: > >>>> > >>>>> -7, first paragraph: "The splicer MUST either be a mixer or a > >>>>> translator..." > >>>>>> > >>>>>> Is the MUST really a requirement, or a statement of fact? > >>>>> > >>>>> > >>>>> [Rachel]: RTP protocol considers intermediate boxes at the RTP > >>>>> level either as mixers or translators. So here it's a statement of > >>>>> fact. > >>>>> But > >>>>> I think that we may not need such a RFC2119 terminology in this > >>>>> case. > >>>>> Maybe change to "can"? > >>>> > >>>> "can" works for me. > >>>> > >>>>> > >>>>>> > >>>>>> -- third paragraph: > >>>>>> > >>>>>> Can you clarify the assumptions about the SRTP security > >>>>>> association(s)? > >>>>>> I assume it's not end to end between the original source and the > >>>>>> receiver, since splicing would seem to violate integrity > >>>>>> protection. > >>>>>> In particular, what assumptions allow the insertion to occur > >>>>>> without violating integrity protection, and do not assume the > >>>>>> splicer has access to the keys? > >>>>> > >>>>> > >>>>> [Rachel]: When splicer works as a translator, it doesn't have a > >>>>> SSRC, so it just switches the RTP packets between main stream and > >>>>> substitutive stream when splicing time comes and ends. In that a > >>>>> case, the splicer does not have to access to the keys, it just > >>>>> works like a transport translator. But when splicer works as a > >>>>> mixer like RFC > >>>>> FC6828 suggests, to have the splicer SSRC so it will prevent to > >>>>> take out the ads based on SSRC. It need to have the keying > >>>>> information and decrypt and encrypt the payload. > >>>>> > >>>>> Does the clarification makes sense to you? > >>>> > >>>> In the translator case, the receiver starts out receiving packets > >>>> from the original source. It has the key for those packets through > >>>> some mechanism (e.g. > >>>> dtls-srtp or security descriptions). Then the splicer switches to > >>>> the substitutive source. Presumably, these packets use different > >>>> keys, since they come from a different source. How does the > >>>> receiver learn of this? Or do we assume the original source and the > >>>> substitutive source share keys? > >>> > >>> [Rachel]: Yes, they share the keys. I answered it once in the > >>> previous comments. I copy it here: > >> > >> Yes, you did :-) > >> > >>> > >>> " > >>>> Does this assume both sources use the same SRTP key, or that the > >>>> receiving endpoint is aware which key to use for any given packet? > >>>> Are > >>>> either ever likely to be the case? > >>> > >>> [Rachel]: Either both sources use the same SRTP key, or the splicer > >>> decrypts and re-encrypts with a single key. > >>> " > >>> So maybe I should clarify it in the draft? > >>> > >> > >> Given I keep asking the same question, others may do so also. So it's > >> probably a good idea to clarify it. > >> > >> Thanks! > >> > >> Ben.