From nobody Mon Dec 5 03:28:33 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CACF129451; Mon, 5 Dec 2016 03:28:27 -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.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148093730763.3394.9362354927102641695.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2016 03:28:27 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-vc2hq-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 11:28:28 -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 Payloads of the IETF. Title : RTP Payload Format for VC-2 HQ Profile Video Author : James P. Weaver Filename : draft-ietf-payload-rtp-vc2hq-01.txt Pages : 17 Date : 2016-12-05 Abstract: This memo describes an RTP Payload format for the High Quality (HQ) profile of SMPTE Standard ST 2042-1 known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video. The HQ profile of VC-2 is intended for low latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-vc2hq-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-vc2hq-01 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 Dec 5 03:30:08 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172741299F7 for ; Mon, 5 Dec 2016 03:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CZ9iCs7k6kAT for ; Mon, 5 Dec 2016 03:30:05 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C62129705 for ; Mon, 5 Dec 2016 03:30:04 -0800 (PST) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout0.telhc.bbc.co.uk (8.15.2/8.14.3) with ESMTP id uB5BU31F008596 for ; Mon, 5 Dec 2016 11:30:03 GMT Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.03.0319.002; Mon, 5 Dec 2016 11:30:02 +0000 From: James Barrett To: "payload@ietf.org" Thread-Topic: draft-ietf-payload-rtp-vc2hq-01 Thread-Index: AQHSTurrFEtSfacCfkaQ8G5iupt+Uw== Date: Mon, 5 Dec 2016 11:30:02 +0000 Message-ID: <995401F5-0759-436F-B94B-0AB0870C0DF3@bbc.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.48.249] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22742.006 x-tm-as-result: No--11.708500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <88836A0A2EBA5541BDFEEC6770C6BA0C@bbc.co.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [payload] draft-ietf-payload-rtp-vc2hq-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 11:30:07 -0000 SSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4gVGhpcyB0 aWRpZXMgdXAgdGhlIHdvcmRpbmcgaW4gb25lIHNlY3Rpb24sIG1ha2luZyBpdCBleHBsaWNpdCB0 aGF0IHRoZSBQaWN0dXJlIE51bWJlciBzaG91bGQgbm90IGJlIGluY2x1ZGVkIHR3aWNlIGluIHRo ZSB0cmFuc2Zvcm0gcGFyYW1ldGVycyBwYWNrZXRzLiBUaGFua3MgdG8gQmFyY28gZm9yIHNwb3R0 aW5nIHRoaXMgaXNzdWUuDQoNCi0tDQpKYW1lcyBQLiBXZWF2ZXIgKG7DqSBCYXJyZXR0KQ0KUmVz ZWFyY2ggRW5naW5lZXINCkJCQyBSJkQgTm9ydGggTGFiLA0KRmxvb3IgNSBEb2NrIEhvdXNlLCBN ZWRpYUNpdHksDQpNNTAgMkxIDQpUZWw6ICs0NCgwKTMwIDMwNDAtOTUyMQ0KZS1tYWlsOiBqYW1l cy5iYXJyZXR0QGJiYy5jby51aw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykg aXMgY29uZmlkZW50aWFsIGFuZA0KbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJl IG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJCQyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4NCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluDQplcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUNCmluZm9ybWF0aW9u IGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5k ZXINCmltbWVkaWF0ZWx5Lg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFp bHMNCnNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5 IHlvdXIgY29uc2VudCB0bw0KdGhpcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Tue Dec 6 16:30:43 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755F212961A for ; Tue, 6 Dec 2016 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 Mgms0YCsagbL for ; Tue, 6 Dec 2016 16:30:39 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F49C129617 for ; Tue, 6 Dec 2016 16:30:39 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.15.2/8.15.2) with ESMTP id uB70UarZ091469 for ; Tue, 6 Dec 2016 16:30:37 -0800 (PST) (envelope-from finlayson@live555.com) X-Authentication-Warning: ns.live555.com: Host localhost.live555.com [127.0.0.1] claimed to be [127.0.0.1] From: Ross Finlayson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 7 Dec 2016 13:30:36 +1300 References: <004b01d244bf$0087fc80$0197f580$@gmail.com> To: payload@ietf.org In-Reply-To: <004b01d244bf$0087fc80$0197f580$@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3251) Archived-At: Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 00:30:41 -0000 > This is a call to adopt draft-wei-payload-has-over-rtp-01 as a Payload = WG document and create a milestone for this=20 >=20 > There was already support to adopt it in the payload session at = IETF97 That=E2=80=99s not quite the impression I got. At the Payload session = in Seoul (and also in Berlin), there seemed to be quite a bit of = scepticism - in particular, about whether RTP is the right protocol for = them to be using (for multicast delivery of video segments). The basic problem is that, right now, the proposed payload format makes = little real use of the features of RTP - basically, the only part of the = RTP header that is used in any meaningful fashion is the RTP sequence = number (for identifying and reordering out-of-order network packets). = However, in order to be used effectively (on multicast networks with = non-negligible packet loss), video segments will need to be delivered = reliably (i.e., in their entirety). There *are* mechanisms available = within the overall RTP architecture that could help provide reliable = delivery - e.g., Flexible FEC; the RTP/AVPF profile - but these are not = mandated (or even mentioned, except very briefly in section 6.1) in the = current Internet Draft. > and this email is to verify the support > =20 > Please provide any view to the list by December 7th In short: I'd support adopting this as a WG document *only if* the = authors: 1/ Better justify their choice of RTP as the transport protocol = for multicast delivery of video segments, and 2/ Describe specifically how they=E2=80=99re going to achieve = *reliable* multicast delivery of video segments (or else note explicitly = that their approach is intended only for multicast networks in which = packet loss is very low). Fortunately, the problem that this draft purports to solve is real and = well-described - so it seems that a solution is needed. Section 3.2 of = the draft does, in fact, describe an existing solution - = =E2=80=9Cmulticast-ABR=E2=80=9D - that does include a (NORM-based) = protocol for reliable delivery. The draft makes three arguments against = using this existing solution, but only the first of these arguments (the = lack of a =E2=80=98fast channel switching=E2=80=99 mechanism (e.g., RFC = 6285)) seems strong. The other two arguments seem rather weak, = specifically: - "some telecom operators only have IPTV multicast platform, = which may not support NORM protocol=E2=80=9D True, but providing reliable delivery using a RTP-based = solution will likely also require a more extensive use of the RTP = protocol than IPTV platforms already provide - so some extra = implementation would be required in either case. - "NORM is not aware of the media timing in a way that RTP is as = RTP is nature to handle multimedia=E2=80=9D I=E2=80=99m not quite sure what this means, but I note = that the proposed RTP payload doesn=E2=80=99t have much =E2=80=98awareness= =E2=80=99 of media timing either. In particular, the draft proposes = using the same RTP timestamp for all RTP packets that make up a single = media segment. (I can=E2=80=99t help but wonder if there might be some unstated = =E2=80=98hidden agenda=E2=80=99 for not wanting to use the = =E2=80=9Cmulticast-ABR=E2=80=9D mechanism...) Some additional quick comments: - Section 4: "HAS Over RTP Use Scenarios=E2=80=9D This section notes that =E2=80=9CWith the introduction of HAS payload = for RTP, network operators can reuse the existing [IPTV] = infrastructure=E2=80=9D. Once again, this argument seems to discount = the fact that - to guarantee reliable delivery - existing IPTV networks = will require some extra implementation. - Section 6.3: "Manifest file and Initial Information Consideration=E2=80=9D= This section seems very vague about whether or not the =E2=80=98manifest = files=E2=80=99 are needed to be delivered, and, if so, how they would be = delivered (=E2=80=98out of band=E2=80=99). If this draft were to be = adopted as a Working Group item, then it would (IMHO) need to be a lot = clearer about exactly what would need to be implemented here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ From nobody Wed Dec 7 01:02:17 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992AF127A90 for ; Wed, 7 Dec 2016 01:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YYboAZN7VyEK for ; Wed, 7 Dec 2016 01:02:08 -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 1B9C412896F for ; Wed, 7 Dec 2016 01:02:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCC37154; Wed, 07 Dec 2016 09:02:05 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 7 Dec 2016 09:02:03 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 7 Dec 2016 17:01:57 +0800 From: "Huangyihong (Rachel)" To: Ross Finlayson , "payload@ietf.org" Thread-Topic: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document Thread-Index: AdJEvv+T14loY4UrRdqX5JTuukyVXgLHxL8AABsnWcA= Date: Wed, 7 Dec 2016 09:01:57 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB870949C6@nkgeml513-mbx.china.huawei.com> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.7.219] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5847D00E.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 680fd78bb1f66d890a82ec9761852317 Archived-At: Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 09:02:16 -0000 SGkgUm9zcywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZS4N Cg0KQlIsDQpSYWNoZWwNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBwYXls b2FkIFttYWlsdG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9zcyBGaW5sYXlz b24NCuWPkemAgeaXtumXtDogMjAxNuW5tDEy5pyIN+aXpSA4OjMxDQrmlLbku7bkuro6IHBheWxv YWRAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtwYXlsb2FkXSBjYWxsIHRvIGFkb3B0IGRyYWZ0LXdl aS1wYXlsb2FkLWhhcy1vdmVyLXJ0cC0wMSBhcyBhIHBheWxvYWQgV0cgZG9jdW1lbnQNCg0KPiBU aGlzIGlzIGEgY2FsbCB0byBhZG9wdCBkcmFmdC13ZWktcGF5bG9hZC1oYXMtb3Zlci1ydHAtMDEg YXMgYSBQYXlsb2FkIFdHIGRvY3VtZW50IGFuZCBjcmVhdGUgYSBtaWxlc3RvbmUgZm9yIHRoaXMg DQo+IA0KPiBUaGVyZSB3YXMgYWxyZWFkeSBzdXBwb3J0IHRvIGFkb3B0IGl0IGluICB0aGUgcGF5 bG9hZCBzZXNzaW9uIGF0IElFVEY5Nw0KDQpUaGF04oCZcyBub3QgcXVpdGUgdGhlIGltcHJlc3Np b24gSSBnb3QuICBBdCB0aGUgUGF5bG9hZCBzZXNzaW9uIGluIFNlb3VsIChhbmQgYWxzbyBpbiBC ZXJsaW4pLCB0aGVyZSBzZWVtZWQgdG8gYmUgcXVpdGUgYSBiaXQgb2Ygc2NlcHRpY2lzbSAtIGlu IHBhcnRpY3VsYXIsIGFib3V0IHdoZXRoZXIgUlRQIGlzIHRoZSByaWdodCBwcm90b2NvbCBmb3Ig dGhlbSB0byBiZSB1c2luZyAoZm9yIG11bHRpY2FzdCBkZWxpdmVyeSBvZiB2aWRlbyBzZWdtZW50 cykuDQoNClRoZSBiYXNpYyBwcm9ibGVtIGlzIHRoYXQsIHJpZ2h0IG5vdywgdGhlIHByb3Bvc2Vk IHBheWxvYWQgZm9ybWF0IG1ha2VzIGxpdHRsZSByZWFsIHVzZSBvZiB0aGUgZmVhdHVyZXMgb2Yg UlRQIC0gYmFzaWNhbGx5LCB0aGUgb25seSBwYXJ0IG9mIHRoZSBSVFAgaGVhZGVyIHRoYXQgaXMg dXNlZCBpbiBhbnkgbWVhbmluZ2Z1bCBmYXNoaW9uIGlzIHRoZSBSVFAgc2VxdWVuY2UgbnVtYmVy IChmb3IgaWRlbnRpZnlpbmcgYW5kIHJlb3JkZXJpbmcgb3V0LW9mLW9yZGVyIG5ldHdvcmsgcGFj a2V0cykuICBIb3dldmVyLCBpbiBvcmRlciB0byBiZSB1c2VkIGVmZmVjdGl2ZWx5IChvbiBtdWx0 aWNhc3QgbmV0d29ya3Mgd2l0aCBub24tbmVnbGlnaWJsZSBwYWNrZXQgbG9zcyksIHZpZGVvIHNl Z21lbnRzIHdpbGwgbmVlZCB0byBiZSBkZWxpdmVyZWQgcmVsaWFibHkgKGkuZS4sIGluIHRoZWly IGVudGlyZXR5KS4gIFRoZXJlICphcmUqIG1lY2hhbmlzbXMgYXZhaWxhYmxlIHdpdGhpbiB0aGUg b3ZlcmFsbCBSVFAgYXJjaGl0ZWN0dXJlIHRoYXQgY291bGQgaGVscCBwcm92aWRlIHJlbGlhYmxl IGRlbGl2ZXJ5IC0gZS5nLiwgRmxleGlibGUgRkVDOyB0aGUgUlRQL0FWUEYgcHJvZmlsZSAtIGJ1 dCB0aGVzZSBhcmUgbm90IG1hbmRhdGVkIChvciBldmVuIG1lbnRpb25lZCwgZXhjZXB0IHZlcnkg YnJpZWZseSBpbiBzZWN0aW9uIDYuMSkgaW4gdGhlIGN1cnJlbnQgSW50ZXJuZXQgRHJhZnQuDQoN CltSYWNoZWxdOiBXZSBhcmUgdGFyZ2V0aW5nIHRoZSBzY2VuYXJpbyB0aGF0IHZpZGVvIGRvZXNu J3QgaGF2ZSB0byBiZSBkZWxpdmVyZWQgcmVsaWFibHkuIElmIHlvdSB3YW50IHZpZGVvIHRvIGJl IHJlbGlhYmxlLCBSVFAgbWF5IG5vdCBiZSB0aGUgZ29vZCBjaG9pY2UuIEJ1dCB2aWRlbyB0cmFu c3BvcnQgZG9lc24ndCBoYXZlIHRvICBiZSBzbyByZWxpYWJsZT8gVmlkZW8gaXMgcmVsaWFibGUg b25seSBiZWNhdXNlIHZpZGVvIGlzIHRyYW5zcG9ydGVkIGJ5IEhUVFAgdG8gdGhlIGVuZCB1c2Vy LCBub3QgYmVjYXVzZSB2aWRlbyB0cmFuc3BvcnQgcmVxdWlyZXMgMTAwIHBlcmNlbnQgcmVsaWFi aWxpdHkuIEFuZCBhbHNvIGl0J3MgbGl2ZSB2aWRlbywgZGVsYXkgaXMgbW9yZSBjcml0aWNhbCB0 aGFuIHJlbGlhYmlsaXR5LiBTbyBpbiB0aGlzIGRyYWZ0LCB0aGUgc2NlbmFyaW9zIGlzIHZlcnkg Y2xlYXIsIHRoYXQgdmlkZW8gaXMgdHJhbnNwb3J0ZWQgYnkgbXVsdGljYXN0IHRvIHRoZSBlbmQg dXNlcnMgd2hvIGFyZSBhYmxlIHRvIGRpcmVjdGx5IGpvaW4gdGhlIG11bHRpY2FzdCBncm91cCwg ZS5nLiwgU1RCLCBvciB0aGUgZW5kIHVzZXJzIHdobyBhcmUgY2FwYWJsZSBvZiBwYXJzaW5nIHRo ZSBSVFAgcHJvdG9jb2wgYW5kIHRoZSBwYXlsb2FkLCBlLmcuLCBhbiBBUFAgaW4gbW9iaWxlIHBo b25lLiBXZSdyZSBub3QgdGFyZ2V0aW5nIHRoZSBlbmQgdXNlcnMgdGhhdCB1c2luZyBIVFRQIHRv IHJlY2VpdmUgdGhlIGxpdmUgdmlkZW8sIHNvIEkgdGhpbmsgcmVsaWFiaWxpdHkgaXMgbm90IG1h bmRhdGVkLiBPZiBjb3Vyc2UsIGlmIHNvbWUgcGFja2V0cyBhcmUgdmVyeSBpbXBvcnRhbnQsIGUu Zy4sIHRoZSBwYWNrZXQgY29udGFpbmluZyBJIGZyYW1lLCB0aGV5IGNhbiBiZSByZXRyYW5zbWl0 dGVkIGJ5IHRoZSBtZXRob2RzIHNwZWNpZmllZCBpbiBjdXJyZW50IFJUUCB0ZWNobm9sb2dpZXMg bGlrZSBGRUMgb3IgcmV0cmFuc21pc3Npb24uIEl0IG1ha2VzIHNlbnNlIHRvIHNhY3JpZmljZSBz b21lIHJlbGlhYmlsaXR5IHRvIHJlZHVjZSB0aGUgZGVsYXkgYW5kIGluY3JlYXNlIHRoZSB0aHJv dWdocHV0Lg0KDQo+ICBhbmQgdGhpcyBlbWFpbCBpcyB0byB2ZXJpZnkgdGhlIHN1cHBvcnQNCj4g IA0KPiBQbGVhc2UgcHJvdmlkZSBhbnkgdmlldyB0byB0aGUgbGlzdCBieSBEZWNlbWJlciA3dGgN Cg0KSW4gc2hvcnQ6IEknZCBzdXBwb3J0IGFkb3B0aW5nIHRoaXMgYXMgYSBXRyBkb2N1bWVudCAq b25seSBpZiogdGhlIGF1dGhvcnM6DQoJMS8gQmV0dGVyIGp1c3RpZnkgdGhlaXIgY2hvaWNlIG9m IFJUUCBhcyB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGZvciBtdWx0aWNhc3QgZGVsaXZlcnkgb2Yg dmlkZW8gc2VnbWVudHMsIGFuZA0KCTIvIERlc2NyaWJlIHNwZWNpZmljYWxseSBob3cgdGhleeKA mXJlIGdvaW5nIHRvIGFjaGlldmUgKnJlbGlhYmxlKiBtdWx0aWNhc3QgZGVsaXZlcnkgb2Ygdmlk ZW8gc2VnbWVudHMgKG9yIGVsc2Ugbm90ZSBleHBsaWNpdGx5IHRoYXQgdGhlaXIgYXBwcm9hY2gg aXMgaW50ZW5kZWQgb25seSBmb3IgbXVsdGljYXN0IG5ldHdvcmtzIGluIHdoaWNoIHBhY2tldCBs b3NzIGlzIHZlcnkgbG93KS4NCg0KRm9ydHVuYXRlbHksIHRoZSBwcm9ibGVtIHRoYXQgdGhpcyBk cmFmdCBwdXJwb3J0cyB0byBzb2x2ZSBpcyByZWFsIGFuZCB3ZWxsLWRlc2NyaWJlZCAtIHNvIGl0 IHNlZW1zIHRoYXQgYSBzb2x1dGlvbiBpcyBuZWVkZWQuICBTZWN0aW9uIDMuMiBvZiB0aGUgZHJh ZnQgZG9lcywgaW4gZmFjdCwgZGVzY3JpYmUgYW4gZXhpc3Rpbmcgc29sdXRpb24gLSDigJxtdWx0 aWNhc3QtQUJS4oCdIC0gdGhhdCBkb2VzIGluY2x1ZGUgYSAoTk9STS1iYXNlZCkgcHJvdG9jb2wg Zm9yIHJlbGlhYmxlIGRlbGl2ZXJ5LiAgVGhlIGRyYWZ0IG1ha2VzIHRocmVlIGFyZ3VtZW50cyBh Z2FpbnN0IHVzaW5nIHRoaXMgZXhpc3Rpbmcgc29sdXRpb24sIGJ1dCBvbmx5IHRoZSBmaXJzdCBv ZiB0aGVzZSBhcmd1bWVudHMgKHRoZSBsYWNrIG9mIGEg4oCYZmFzdCBjaGFubmVsIHN3aXRjaGlu Z+KAmSBtZWNoYW5pc20gKGUuZy4sIFJGQyA2Mjg1KSkgc2VlbXMgc3Ryb25nLiAgVGhlIG90aGVy IHR3byBhcmd1bWVudHMgc2VlbSByYXRoZXIgd2Vhaywgc3BlY2lmaWNhbGx5Og0KCS0gInNvbWUg dGVsZWNvbSBvcGVyYXRvcnMgb25seSBoYXZlIElQVFYgbXVsdGljYXN0IHBsYXRmb3JtLCB3aGlj aCBtYXkgbm90IHN1cHBvcnQgTk9STSBwcm90b2NvbOKAnQ0KCQlUcnVlLCBidXQgcHJvdmlkaW5n IHJlbGlhYmxlIGRlbGl2ZXJ5IHVzaW5nIGEgUlRQLWJhc2VkIHNvbHV0aW9uIHdpbGwgbGlrZWx5 IGFsc28gcmVxdWlyZSBhIG1vcmUgZXh0ZW5zaXZlIHVzZSBvZiB0aGUgUlRQIHByb3RvY29sIHRo YW4gSVBUViBwbGF0Zm9ybXMgYWxyZWFkeSBwcm92aWRlIC0gc28gc29tZSBleHRyYSBpbXBsZW1l bnRhdGlvbiB3b3VsZCBiZSByZXF1aXJlZCBpbiBlaXRoZXIgY2FzZS4NCg0KW1JhY2hlbF06IEN1 cnJlbnQgSVBUViBwcm92aWRlcnMgYWxyZWFkeSBpbXBsZW1lbnQgdGhlIG1lY2hhbmlzbXMgbGlr ZSByZXRyYW5zbWlzc2lvbiBvciBGRUMgdG8gcHJvdGVjdCBpbXBvcnRhbnQgcGFja2V0cy4gVGhl eSBhcmUgZXhpc3RpbmcgdGVjaG5vbG9naWVzIHRoYXQgYXJlIGJlaW5nIHVzZWQuIA0KDQoJLSAi Tk9STSBpcyBub3QgYXdhcmUgb2YgdGhlIG1lZGlhIHRpbWluZyBpbiBhIHdheSB0aGF0IFJUUCBp cyBhcyBSVFAgaXMgbmF0dXJlIHRvIGhhbmRsZSBtdWx0aW1lZGlh4oCdDQoJCUnigJltIG5vdCBx dWl0ZSBzdXJlIHdoYXQgdGhpcyBtZWFucywgYnV0IEkgbm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBS VFAgcGF5bG9hZCBkb2VzbuKAmXQgaGF2ZSBtdWNoIOKAmGF3YXJlbmVzc+KAmSBvZiBtZWRpYSB0 aW1pbmcgZWl0aGVyLiAgSW4gcGFydGljdWxhciwgdGhlIGRyYWZ0IHByb3Bvc2VzIHVzaW5nIHRo ZSBzYW1lIFJUUCB0aW1lc3RhbXAgZm9yIGFsbCBSVFAgcGFja2V0cyB0aGF0IG1ha2UgdXAgYSBz aW5nbGUgbWVkaWEgc2VnbWVudC4NCihJIGNhbuKAmXQgaGVscCBidXQgd29uZGVyIGlmIHRoZXJl IG1pZ2h0IGJlIHNvbWUgdW5zdGF0ZWQg4oCYaGlkZGVuIGFnZW5kYeKAmSBmb3Igbm90IHdhbnRp bmcgdG8gdXNlIHRoZSDigJxtdWx0aWNhc3QtQUJS4oCdIG1lY2hhbmlzbS4uLikNCg0KW1JhY2hl bF06IFRoaXMgY2FuIGJlIGRpc2N1c3NlZC4gSSdtIG5vdCBzYXlpbmcgdGhhdCBjdXJyZW50IFJU UCB0aW1lc3RhbXAgaW4gdGhpcyBkcmFmdCBpcyB0aGUgbW9zdCByZWFzb25hYmxlIHNldHRpbmcu IFBlb3BsZSBjYW4gY2VydGFpbmx5IGhhdmUgYmV0dGVyIGlkZWFzLiBXaGF0IHdlIHdlcmUgc2F5 aW5nIGlzIHRoYXQgUlRQIGlzIGJvcm4gdG8gaGFuZGxlIG11bHRpbWVkaWEgdGhpbmdzLiBJdCBo YXMgYSBsb3Qgb2YgZmVhdHVyZXMgdGhhdCBhcmUgc3VpdGFibGUgZm9yIGRlbGl2ZXJpbmcgbWVk aWEuIFdoaWxlLCBOT1JNIGlzIGRlc2lnbmVkIGZvciBkZWxpdmVyaW5nIGZpbGVzLCBhbmQgY2Fu bm90IGJlIHdlbGwgc3VwcG9ydGVkIGJ5IGVuZCB1c2Vycy4gSXQgbmVlZHMgc29tZXRoaW5nIHRv IGNvbnZlcnQgdGhlIG11bHRpY2FzdCBOT1JNIHRvIHVuaWNhc3QgSFRUUCwgd2hpY2ggbWVhbnMg dGhlIE0yVSBkZXZpY2VzIGFjdCBhcyBib3RoIHRoZSBtdWx0aWNhc3QgY2xpZW50IGFuZCBIVFRQ IHByb3h5LiBGb3IgcmVhbCBpbXBsZW1lbnRhdGlvbiwgdGhlIE0yVSwgd2hpY2ggY2FuIGJlIGEg T05UIG9yIE9MVCwgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggYW5kIGJlIGRpZmZpY3VsdCB0byBzZXJ2 ZSBhcyBtYW55IGFzIHBvc3NpYmxlIGNoYW5uZWxzIGFuZCBlbmQgdXNlcnMgZHVlIHRvIHRoZSBs aW1pdGVkIHN0b3JhZ2UgYW5kIENQVSBjYXBhYmlsaXRpZXMuDQoNCiANClNvbWUgYWRkaXRpb25h bCBxdWljayBjb21tZW50czoNCg0KLSBTZWN0aW9uIDQ6ICJIQVMgT3ZlciBSVFAgVXNlIFNjZW5h cmlvc+KAnQ0KVGhpcyBzZWN0aW9uIG5vdGVzIHRoYXQg4oCcV2l0aCB0aGUgaW50cm9kdWN0aW9u IG9mIEhBUyBwYXlsb2FkIGZvciBSVFAsIG5ldHdvcmsgb3BlcmF0b3JzIGNhbiByZXVzZSB0aGUg ZXhpc3RpbmcgW0lQVFZdIGluZnJhc3RydWN0dXJl4oCdLiAgT25jZSBhZ2FpbiwgdGhpcyBhcmd1 bWVudCBzZWVtcyB0byBkaXNjb3VudCB0aGUgZmFjdCB0aGF0IC0gdG8gZ3VhcmFudGVlIHJlbGlh YmxlIGRlbGl2ZXJ5IC0gZXhpc3RpbmcgSVBUViBuZXR3b3JrcyB3aWxsIHJlcXVpcmUgc29tZSBl eHRyYSBpbXBsZW1lbnRhdGlvbi4NCg0KW1JhY2hlbF06IFNlZSBhYm92ZS4NCg0KLSBTZWN0aW9u IDYuMzogIk1hbmlmZXN0IGZpbGUgYW5kIEluaXRpYWwgSW5mb3JtYXRpb24gQ29uc2lkZXJhdGlv buKAnQ0KVGhpcyBzZWN0aW9uIHNlZW1zIHZlcnkgdmFndWUgYWJvdXQgd2hldGhlciBvciBub3Qg dGhlIOKAmG1hbmlmZXN0IGZpbGVz4oCZIGFyZSBuZWVkZWQgdG8gYmUgZGVsaXZlcmVkLCBhbmQs IGlmIHNvLCBob3cgdGhleSB3b3VsZCBiZSBkZWxpdmVyZWQgKOKAmG91dCBvZiBiYW5k4oCZKS4g IElmIHRoaXMgZHJhZnQgd2VyZSB0byBiZSBhZG9wdGVkIGFzIGEgV29ya2luZyBHcm91cCBpdGVt LCB0aGVuIGl0IHdvdWxkIChJTUhPKSBuZWVkIHRvIGJlIGEgbG90IGNsZWFyZXIgYWJvdXQgZXhh Y3RseSB3aGF0IHdvdWxkIG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQgaGVyZS4NCg0KW1JhY2hlbF06 IEluIGhhcyBvdmVyIFJUUCwgaXQncyBhIFBVU0ggbW9kZSBpbnN0ZWFkIG9mIHRoZSBQVVNIIG1v ZGUgdGhhdCBIVFRQIHN0cmVhbWluZyBpcyB1c2luZy4gTWVkaWEgaXMgcHVzaCBmcm9tIHRoZSBz ZXJ2ZXIgdG8gdGhlIHJlY2VpdmVyIGFuZCB0aGUgcmVjZWl2ZXIgd2lsbCBub3QgYXNrIGZvciBl YWNoIHNlZ21lbnRzLCB3aGljaCBtZWFucyB0aGUgcmVjZWl2ZXJzIGRvbid0IHJlbHkgc28gbXVj aCBvbiB0aGUgbWFuaWZlc3QgZmlsZXMgYXMgdGhlIEhBUyBkb2VzLiBTbyBtYW5pZmVzdCBmaWxl cyBhcmUgbm90IGRlbGl2ZXJlZCBpbiB0aGUgbWVkaWEgcGF0aCwgaW5zdGVhZCwgaXQgY2FuIGJl IHNpZ25hbGVkIGJ5IEhUVFAgb3IgU0RQLCBvciBldmVuIG5vdCByZXF1aXJlZC4NCg0KUm9zcyBG aW5sYXlzb24NCkxpdmUgTmV0d29ya3MsIEluYy4NCmh0dHA6Ly93d3cubGl2ZTU1NS5jb20vDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXlsb2Fk IG1haWxpbmcgbGlzdA0KcGF5bG9hZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXlsb2FkDQo= From nobody Wed Dec 7 02:32:25 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C7112983F for ; Wed, 7 Dec 2016 02:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7kuTrdMWP2Ka for ; Wed, 7 Dec 2016 02:32:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6F91297E8 for ; Wed, 7 Dec 2016 02:32:21 -0800 (PST) X-AuditID: c1b4fb30-037da980000054c8-d6-5847e53413c2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id AD.F4.21704.435E7485; Wed, 7 Dec 2016 11:32:20 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Wed, 7 Dec 2016 11:32:15 +0100 To: Roni Even , References: <004b01d244bf$0087fc80$0197f580$@gmail.com> From: Magnus Westerlund Message-ID: <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> Date: Wed, 7 Dec 2016 11:32:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <004b01d244bf$0087fc80$0197f580$@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM2K7t67JU/cIg3OrhCxWXG5mtrh08SyT xd92Zgdmj52z7rJ7LFnykymAKYrLJiU1J7MstUjfLoEr49uP9ywFW6QrZm2YyNrA2CzWxcjB ISFgIjGtj7GLkYtDSGAdo8Txv23MXYycQM4yRomLk5RBbGGBRIlZnzYxgtgiAlYSM34eZISo MZd4tXoxE4jNLKAmsfvEfjYQm03AQuLmj0Ywm1fAXmL31c3sILtYBFQkLn1NAgmLCsRILDk+ jwWiRFDi5MwnYDYnUGvz1gOMIOXMQK0PtpZBTJcHCs+GukxboqGpg3UCo8AsJN2zEDpmIelY wMi8ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwLA9u+W2wg/Hlc8dDjAIcjEo8vAWX3CKE WBPLiitzDzFKcDArifDmP3GPEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZq akFqEUyWiYNTqoFxsuijtWyBtxf+u9Mh3SoSs8t7RVlOUs2TncJ2L8Ja1AVnfP9W1Mnyukkx 75vXLANxvkNhn0KvL/D/3zs3M0mn7emmd/L3ilq+hJTINHHVP1t7IGyy/HMHbhN/CbHbrUcm 6Ht+P+9203tN7b/0iqgFvTsPvhPbIPJlieoHtlvVvUKX9vwrKV2hxFKckWioxVxUnAgAzLtl 7UcCAAA= Archived-At: Cc: "Ali C. Begen" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 10:32:24 -0000 Hi, I have reviewed the updated draft and think this call for adoption should be postponed a bit until the scope of the work has been clarified. I find several significant uncertainties in the description in the draft making the use and thus scope of the solution unclear. First, what are the actual intended usage, and especially what termination points are intended? Section 5 discusses both direct multicast RTP consumers of the media content. I would guess that includes existing Set top boxes (STB). The other set of receivers appears to be unicast devices in a LAN behind a gateway, for example the operators Customer Premise Equipment (CPE). But still deliver RTP to the unicast receiver. I don't quite see how these purpose matches the proposed format. So the media content for HAS has different formats, but the HTTP retrieved media segments are to my understanding predominately either MPEG Transport Stream formats, or an ISO Base Media File Format based file format. The MPEG TS is something that the IPTV STB commonly already handles, assuming the right set of codecs in the TS. The ISOBMFF file fragment i don't see how that is suitable to include over RTP at all towards RTP receivers. If the use case is to use the IPTV RTP multicast transport as a way to get the data to the CPE, and then re-assembly the file and serve from the CPE to unicast device over HTTP then it makes some sense. Except that RTP may not be the most efficient file transport protocol, considering its intention to rather handle losses gracefully. So from my perspective the proposed format seems a poor match to meet the goals that has been expressed. Thus, I would like to request that the use cases and goals of the work is clarified before we start work on a solution in this WG. I also have to remark that I find it strange that the proposed solution with a payload has a parameter that indicate the format of the MPD, i.e. HLS or DASH, rather than indicate the actual media format, i.e. MPEG TS or what type of ISOBMFF, that is included in the payloads. I would also note that the security requirements of this solution needs to be discussed. It appears that integrity and source authentication are important, and I would at least raise the question if one needs to have some secured indication of source origin of the media content in some way to prove the actual origin of the media content? The congestion control section also looks contradicting the earlier section on multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt to the long term capacity of the network path, where TCP performs congestion control and probes for the current throughput. In a multicast network, where this text appear to indicate that congestion control is not needed because of known resource, what is the role of having multiple bit-rates made available? Can we please have these issues resolved before adopting the draft? Cheers 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 Wed Dec 7 09:15:08 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B041296DB for ; Wed, 7 Dec 2016 09:15:06 -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 autolearn_force=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 cDNvLCPoiwka for ; Wed, 7 Dec 2016 09:15:05 -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 B607E1296C3 for ; Wed, 7 Dec 2016 09:14:28 -0800 (PST) Received: from [2001:630:40:70e0::107] (port=49320) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cEfnW-0002rr-HP; Wed, 07 Dec 2016 17:14:27 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> Date: Wed, 7 Dec 2016 17:14:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <677F9EDC-0822-4FAB-95C6-5C2E31C9080F@csperkins.org> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Cc: "Ali C. Begen" , payload@ietf.org Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 17:15:07 -0000 Hi, > On 7 Dec 2016, at 10:32, Magnus Westerlund = wrote: >=20 > I have reviewed the updated draft and think this call for adoption = should be postponed a bit until the scope of the work has been = clarified. I find several significant uncertainties in the description = in the draft making the use and thus scope of the solution unclear. >=20 > First, what are the actual intended usage, and especially what = termination points are intended? Section 5 discusses both direct = multicast RTP consumers of the media content. I would guess that = includes existing Set top boxes (STB). The other set of receivers = appears to be unicast devices in a LAN behind a gateway, for example the = operators Customer Premise Equipment (CPE). But still deliver RTP to the = unicast receiver. My impression is that this only makes sense if RTP is being delivered to = the receiver. If you want to gateway HTTP to multicast and back to HTTP, = then some form of reliable multicast is needed. > I don't quite see how these purpose matches the proposed format. So = the media content for HAS has different formats, but the HTTP retrieved = media segments are to my understanding predominately either MPEG = Transport Stream formats, or an ISO Base Media File Format based file = format. The MPEG TS is something that the IPTV STB commonly already = handles, assuming the right set of codecs in the TS. Fragmenting an MPEG TS into RTP packets clearly makes sense. Whether it = makes sense to use this new format, or convert to the existing MPEG = payload format is an open question.=20 > The ISOBMFF file fragment i don't see how that is suitable to include = over RTP at all towards RTP receivers. If the use case is to use the = IPTV RTP multicast transport as a way to get the data to the CPE, and = then re-assembly the file and serve from the CPE to unicast device over = HTTP then it makes some sense. Except that RTP may not be the most = efficient file transport protocol, considering its intention to rather = handle losses gracefully. Particular profiles of the ISO file format could make sense, presumably, = if fragmented carefully into RTP packets, and if the receiver were aware = that some data might be lost. The draft should certainly discuss this = further. Indeed, my biggest concerns with this draft are getting the = scope correct, so it=92s clear what type of HTTP adaptive streaming = content can be delivered over RTP, and what are the implications of = unreliable delivery of that content. It would be good if the draft could = walk through the details of how to packetise the content, at least in = outline, to show that it can be done in a manner that allows receivers = to make use of the received packets, even if there is loss (i.e., the = usual ALF argument). > So from my perspective the proposed format seems a poor match to meet = the goals that has been expressed. Thus, I would like to request that = the use cases and goals of the work is clarified before we start work on = a solution in this WG. >=20 > I also have to remark that I find it strange that the proposed = solution with a payload has a parameter that indicate the format of the = MPD, i.e. HLS or DASH, rather than indicate the actual media format, = i.e. MPEG TS or what type of ISOBMFF, that is included in the payloads. The media format should certainly be signalled, although it can likely = go into SDP. Is the MPD format (and URL) needed in case the receiver = wants to use HTTP to replace lost RTP packets on the multicast group?=20 > I would also note that the security requirements of this solution = needs to be discussed. It appears that integrity and source = authentication are important, Yes, but presumably no more than for any other RTP payload format = specification? > and I would at least raise the question if one needs to have some = secured indication of source origin of the media content in some way to = prove the actual origin of the media content? Seems worth discussing. > The congestion control section also looks contradicting the earlier = section on multicast ABR. In HTTP adaptive streaming the ABR part is = there to adopt to the long term capacity of the network path, where TCP = performs congestion control and probes for the current throughput. In a = multicast network, where this text appear to indicate that congestion = control is not needed because of known resource, what is the role of = having multiple bit-rates made available? The gateway would presumably fetch multiple quality levels, and send = each on a different multicast group, allowing the receivers to choose an = appropriate level. This should be discussed, I agree. > Can we please have these issues resolved before adopting the draft? >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Wed Dec 7 12:56:27 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09A1294C2 for ; Wed, 7 Dec 2016 12:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpgvP93PNrsQ for ; Wed, 7 Dec 2016 12:56:24 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 8CA3E129B3A for ; Wed, 7 Dec 2016 12:56:09 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id g23so187383977wme.1 for ; Wed, 07 Dec 2016 12:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=sMhSORe5Cxlbib7NYEC5pf80xGZRQiyAgt2rYqbdsi8=; b=IoPFhMeKJbE4yO/e0v5uIrGT8YgOn1YstNLqHUBOVFOIFZLLgARpi9ohcfguMLv8px yQMenQnF5bZTrvxSshJvx1RwBioT62hSYdaWzQWxXFr+8q3Ln3wkr/UiieY83oWApzfD c+urPnsv55ckP+qX7993YkxKSdAWWHr/sCSQZFIHvwYeB3FYFK9+oIjnRYJFOR7XV2aL fo8PDCcECwtW3c1yUGcaWTZNkAY8jRCBHXi7e8mo/DuIvAyoXWY7B8hkV+ueSSVaQANq XEY3knHyTkKuGZdbQA27SgGB0zDVufO5gZ2PPyONvgArzc0B289gsXlTKjsPzBGXM8aJ oYkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=sMhSORe5Cxlbib7NYEC5pf80xGZRQiyAgt2rYqbdsi8=; b=SEa5PTz+x3HZVhYv548RccZJQb77CeC9ks8CoCmzCktZ00maRVilb+OzVNJIhK5h1+ STVD1hf2SEL7n3ZmbpYml/6+Vjf5WoPV/XtpCFsYKbUP7nk8ZqX54SKE3j6z/j8hG1Jd 5bD7lFxY/5oM6sGsg1YOf9LshX6mYmkkhiDmcPQxflroB7ACWByDz8745HkkRceCrMmy koTt4zhJ5cHeQ5iDo1D9nSOyflBhjwiCxk+wv3q7mh94FZurrYKsLaUIQtCKGNSe7sWT zBIoX2v0JIRGash/JNaigf8i1luyO+zFyQ7Dy8a3PiOECFA5qwmI2i6IzFsq/9YZJvuK DA0g== X-Gm-Message-State: AKaTC00etyVW+hue9LM5fcKv356MIpboUIR/TsQvHj87tcJTzOQgAIMZ2m6urvbSNWxRNQ== X-Received: by 10.28.170.202 with SMTP id t193mr4193278wme.10.1481144168001; Wed, 07 Dec 2016 12:56:08 -0800 (PST) Received: from RoniPC (bzq-109-67-123-33.red.bezeqint.net. [109.67.123.33]) by smtp.gmail.com with ESMTPSA id d85sm11591049wmd.17.2016.12.07.12.56.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Dec 2016 12:56:06 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> In-Reply-To: <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> Date: Wed, 7 Dec 2016 22:56:04 +0200 Message-ID: <018001d250cc$53cdea80$fb69bf80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJ5AxI5NQBNFzha2c6AbKTeSCCQiwHlVcA+n6BijeA= Content-Language: he Archived-At: Cc: "'Ali C. Begen'" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 20:56:26 -0000 Hi Magnus, I think that the motivation for this payload is the case for real time streaming. There are two different types of applications in the = streaming world. The first one is using prerecorded content and users are = accessing it in a non-synchronize way, this may look more like file access on a = server . The second is an event that is happing now viewed by multiple users all = of them watching the same content at the same time, this is more a = real-time broadcast type of content delivery. This payload and solution is for = this second case where it make more sense to push the content to the = receivers and use multicast (single source multicast) to deliver the content using less network resources. My understanding that using RTP here to carry = the content that can also be available with HTTP provides better scaling for delivering this content to a large number of concurrent users. Better = having STB supporting multicast. Using RTP allows also for fast channel switch, like switching from one football game to another played at the same time (UEFA Champions League) The issue of reliability need to be discussed but as the motivation is = for a service that cost money, the first reliability point will be by = allocation of network resources to allow for better QoS, still other means defined = for RTP (retransmission (maybe with fast synchronize) and FEC) is needed = (you do not want to miss a goal in a football match). Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, December 07, 2016 12:32 PM > To: Roni Even; payload@ietf.org > Cc: Ali C. Begen > Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 = as a > payload WG document >=20 > Hi, >=20 > I have reviewed the updated draft and think this call for adoption = should be > postponed a bit until the scope of the work has been clarified. I find several > significant uncertainties in the description in the draft making the = use and > thus scope of the solution unclear. >=20 > First, what are the actual intended usage, and especially what = termination > points are intended? Section 5 discusses both direct multicast RTP consumers > of the media content. I would guess that includes existing Set top = boxes > (STB). The other set of receivers appears to be unicast devices in a = LAN > behind a gateway, for example the operators Customer Premise Equipment > (CPE). But still deliver RTP to the unicast receiver. >=20 > I don't quite see how these purpose matches the proposed format. So = the > media content for HAS has different formats, but the HTTP retrieved = media > segments are to my understanding predominately either MPEG Transport > Stream formats, or an ISO Base Media File Format based file format. = The > MPEG TS is something that the IPTV STB commonly already handles, > assuming the right set of codecs in the TS. The ISOBMFF file fragment = i don't > see how that is suitable to include over RTP at all towards RTP = receivers. If > the use case is to use the IPTV RTP multicast transport as a way to = get the > data to the CPE, and then re-assembly the file and serve from the CPE = to > unicast device over HTTP then it makes some sense. Except that RTP may = not > be the most efficient file transport protocol, considering its = intention to > rather handle losses gracefully. >=20 > So from my perspective the proposed format seems a poor match to meet > the goals that has been expressed. Thus, I would like to request that = the use > cases and goals of the work is clarified before we start work on a solution in > this WG. >=20 > I also have to remark that I find it strange that the proposed = solution with a > payload has a parameter that indicate the format of the MPD, i.e. > HLS or DASH, rather than indicate the actual media format, i.e. MPEG = TS or > what type of ISOBMFF, that is included in the payloads. >=20 > I would also note that the security requirements of this solution = needs to be > discussed. It appears that integrity and source authentication are important, > and I would at least raise the question if one needs to have some = secured > indication of source origin of the media content in some way to prove = the > actual origin of the media content? >=20 > The congestion control section also looks contradicting the earlier section on > multicast ABR. In HTTP adaptive streaming the ABR part is there to = adopt to > the long term capacity of the network path, where TCP performs = congestion > control and probes for the current throughput. In a multicast network, where > this text appear to indicate that congestion control is not needed = because of > known resource, what is the role of having multiple bit-rates made available? >=20 > Can we please have these issues resolved before adopting the draft? >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Thu Dec 8 01:18:17 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7751296B2 for ; Thu, 8 Dec 2016 01:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 97c8eRqGjMnR for ; Thu, 8 Dec 2016 01:18:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5430C1293E4 for ; Thu, 8 Dec 2016 01:18:13 -0800 (PST) X-AuditID: c1b4fb30-037da980000054c8-0c-58492553699b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 8F.AD.21704.35529485; Thu, 8 Dec 2016 10:18:11 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.319.2; Thu, 8 Dec 2016 10:17:59 +0100 To: Roni Even , References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> <018001d250cc$53cdea80$fb69bf80$@gmail.com> From: Magnus Westerlund Message-ID: Date: Thu, 8 Dec 2016 10:17:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <018001d250cc$53cdea80$fb69bf80$@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7vW6wqmeEwcPN+hYrLjczW1y6eJbJ 4m87swOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV8XlLC2vBF4uKTbO6WBoYz+t2MXJy SAiYSPx8/Jy1i5GLQ0hgHaPE9UNP2CCcZYwSnbevsoNUCQskSsz6tIkRxBYRsJKY8fMgI0TR bEaJdQdWsYEkmAU0JO5umw1mswlYSNz80Qhm8wrYS+y40gzWzCKgIjFt632wuKhAjMSS4/NY IGoEJU7OfAJmcwL1Nj7oAFrMATTTXuLB1jKI8fISzVtnM4PYQgLaEg1NHawTGAVmIemehdAx C0nHAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB4Xlwy2+DHYwvnzseYhTgYFTi4f2g 7BEhxJpYVlyZe4hRgoNZSYRXTcUzQog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6Ykl qdmpqQWpRTBZJg5OqQZGh9riNUceVD+aXWQYURm4v2xd6NeHwaYs321371Oo4nuhuirje8JJ 9gPf+jZpXrVdxew7ab6s9yz//Q6rOHZwfZi9wGTG9ImyITniUnP+dFgd3cGwqnNWUuj1ln3T VobNnWr6kOuPgIP966l38o8lLzhibN1+tKdTpq0pI3XungmKMxezrX1YpcRSnJFoqMVcVJwI ANlklABLAgAA Archived-At: Cc: "'Ali C. Begen'" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 09:18:15 -0000 Hi, Yes, I do understand that the main use case for this format is for Live broad casts that has many simultaneous viewers. What I think the draft fails at currently is to make clear which are the main use cases and what are the assumptions of the receiver capabilities. Because I think the real devil here is in the media formats used in the media fragments the adaptive HTTP streaming service uses. There is both multiple formats and multiple codecs. There are also varying parameterizations of the encoding. Regarding the fast channel switch, so the intention here is to use a RAMS type functionality, and then have the HAS RTP stream be sufficiently marked to indicate where the IRAP's in the video are so that the RAMS sender can burst from that position? I note that the possibility for the HAS RTP gateway to perform this is depending on the meta data in the media fragment if the content is DRM protected. I really want the main use cases and assumptions to be clearly specified in the draft, before the decision of WG adoption is taken. I do see some potential in this area, but I do want it to be clearer what is intended to be done before supporting it. Cheers Magnus Den 2016-12-07 kl. 21:56, skrev Roni Even: > Hi Magnus, > I think that the motivation for this payload is the case for real time > streaming. There are two different types of applications in the streaming > world. The first one is using prerecorded content and users are accessing it > in a non-synchronize way, this may look more like file access on a server . > The second is an event that is happing now viewed by multiple users all of > them watching the same content at the same time, this is more a real-time > broadcast type of content delivery. This payload and solution is for this > second case where it make more sense to push the content to the receivers > and use multicast (single source multicast) to deliver the content using > less network resources. My understanding that using RTP here to carry the > content that can also be available with HTTP provides better scaling for > delivering this content to a large number of concurrent users. Better having > STB supporting multicast. Using RTP allows also for fast channel switch, > like switching from one football game to another played at the same time > (UEFA Champions League) > The issue of reliability need to be discussed but as the motivation is for a > service that cost money, the first reliability point will be by allocation > of network resources to allow for better QoS, still other means defined for > RTP (retransmission (maybe with fast synchronize) and FEC) is needed (you do > not want to miss a goal in a football match). > > Roni > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, December 07, 2016 12:32 PM >> To: Roni Even; payload@ietf.org >> Cc: Ali C. Begen >> Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as > a >> payload WG document >> >> Hi, >> >> I have reviewed the updated draft and think this call for adoption should > be >> postponed a bit until the scope of the work has been clarified. I find > several >> significant uncertainties in the description in the draft making the use > and >> thus scope of the solution unclear. >> >> First, what are the actual intended usage, and especially what termination >> points are intended? Section 5 discusses both direct multicast RTP > consumers >> of the media content. I would guess that includes existing Set top boxes >> (STB). The other set of receivers appears to be unicast devices in a LAN >> behind a gateway, for example the operators Customer Premise Equipment >> (CPE). But still deliver RTP to the unicast receiver. >> >> I don't quite see how these purpose matches the proposed format. So the >> media content for HAS has different formats, but the HTTP retrieved media >> segments are to my understanding predominately either MPEG Transport >> Stream formats, or an ISO Base Media File Format based file format. The >> MPEG TS is something that the IPTV STB commonly already handles, >> assuming the right set of codecs in the TS. The ISOBMFF file fragment i > don't >> see how that is suitable to include over RTP at all towards RTP receivers. > If >> the use case is to use the IPTV RTP multicast transport as a way to get > the >> data to the CPE, and then re-assembly the file and serve from the CPE to >> unicast device over HTTP then it makes some sense. Except that RTP may not >> be the most efficient file transport protocol, considering its intention > to >> rather handle losses gracefully. >> >> So from my perspective the proposed format seems a poor match to meet >> the goals that has been expressed. Thus, I would like to request that the > use >> cases and goals of the work is clarified before we start work on a > solution in >> this WG. >> >> I also have to remark that I find it strange that the proposed solution > with a >> payload has a parameter that indicate the format of the MPD, i.e. >> HLS or DASH, rather than indicate the actual media format, i.e. MPEG TS or >> what type of ISOBMFF, that is included in the payloads. >> >> I would also note that the security requirements of this solution needs to > be >> discussed. It appears that integrity and source authentication are > important, >> and I would at least raise the question if one needs to have some secured >> indication of source origin of the media content in some way to prove the >> actual origin of the media content? >> >> The congestion control section also looks contradicting the earlier > section on >> multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt > to >> the long term capacity of the network path, where TCP performs congestion >> control and probes for the current throughput. In a multicast network, > where >> this text appear to indicate that congestion control is not needed because > of >> known resource, what is the role of having multiple bit-rates made > available? >> >> Can we please have these issues resolved before adopting the draft? >> >> Cheers >> >> 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 >> ---------------------------------------------------------------------- > > -- 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 Thu Dec 8 01:30:32 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D7129CB0 for ; Thu, 8 Dec 2016 01:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3DtdqpHzqfGP for ; Thu, 8 Dec 2016 01:30:27 -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 B493F128DF6 for ; Thu, 8 Dec 2016 01:30:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCE31863; Thu, 08 Dec 2016 09:30:24 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 8 Dec 2016 09:30:10 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 8 Dec 2016 17:30:00 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins , Magnus Westerlund Thread-Topic: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document Thread-Index: AdJEvv+T14loY4UrRdqX5JTuukyVXgLcx8QAAA4LgYAAMc/jQA== Date: Thu, 8 Dec 2016 09:30:01 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB87098F10@nkgeml513-mbx.china.huawei.com> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> <677F9EDC-0822-4FAB-95C6-5C2E31C9080F@csperkins.org> In-Reply-To: <677F9EDC-0822-4FAB-95C6-5C2E31C9080F@csperkins.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.221] Content-Type: text/plain; charset="iso-8859-1" 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.58492830.0379, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bc2fce5ab4dca3bdc30948ae9e19f385 Archived-At: Cc: "Ali C. Begen" , "payload@ietf.org" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 09:30:30 -0000 Hi, BR, Rachel > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkin= s > Sent: Thursday, December 08, 2016 1:14 AM > To: Magnus Westerlund > Cc: Ali C. Begen; payload@ietf.org > Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as= a > payload WG document >=20 > Hi, >=20 > > On 7 Dec 2016, at 10:32, Magnus Westerlund > wrote: > > > > I have reviewed the updated draft and think this call for adoption shou= ld be > postponed a bit until the scope of the work has been clarified. I find se= veral > significant uncertainties in the description in the draft making the use = and thus > scope of the solution unclear. > > > > First, what are the actual intended usage, and especially what terminat= ion > points are intended? Section 5 discusses both direct multicast RTP consum= ers > of the media content. I would guess that includes existing Set top boxes = (STB). > The other set of receivers appears to be unicast devices in a LAN behind = a > gateway, for example the operators Customer Premise Equipment (CPE). But > still deliver RTP to the unicast receiver. >=20 > My impression is that this only makes sense if RTP is being delivered to = the > receiver. If you want to gateway HTTP to multicast and back to HTTP, then > some form of reliable multicast is needed. [Rachel]: Yes. The traditional way is to convert multicast to unicast in HT= TP. However, we're targeting the live HTTP streaming services. It's really = difficult to implement in CPE devices considering current capability and re= sources of such devices. It's better to be a server rather than a network d= evice to do such kind of work. And if supporting 4K live or future VR live,= the issue could be severe. But if unicast to end users by RTP, things coul= d be very simple, M2U could be just a RTP translator which doesn't require = too much processing. >=20 > > I don't quite see how these purpose matches the proposed format. So the > media content for HAS has different formats, but the HTTP retrieved media > segments are to my understanding predominately either MPEG Transport > Stream formats, or an ISO Base Media File Format based file format. The M= PEG > TS is something that the IPTV STB commonly already handles, assuming the > right set of codecs in the TS. >=20 > Fragmenting an MPEG TS into RTP packets clearly makes sense. Whether it > makes sense to use this new format, or convert to the existing MPEG paylo= ad > format is an open question. >=20 > > The ISOBMFF file fragment i don't see how that is suitable to include o= ver RTP > at all towards RTP receivers. If the use case is to use the IPTV RTP mult= icast > transport as a way to get the data to the CPE, and then re-assembly the f= ile > and serve from the CPE to unicast device over HTTP then it makes some sen= se. > Except that RTP may not be the most efficient file transport protocol, > considering its intention to rather handle losses gracefully. >=20 > Particular profiles of the ISO file format could make sense, presumably, = if > fragmented carefully into RTP packets, and if the receiver were aware tha= t > some data might be lost. The draft should certainly discuss this further.= Indeed, > my biggest concerns with this draft are getting the scope correct, so it'= s clear > what type of HTTP adaptive streaming content can be delivered over RTP, a= nd > what are the implications of unreliable delivery of that content. It woul= d be > good if the draft could walk through the details of how to packetise the = content, > at least in outline, to show that it can be done in a manner that allows > receivers to make use of the received packets, even if there is loss (i.e= ., the > usual ALF argument). [Rachel]: Okay, I think we do lack such discussion in current draft. >=20 > > So from my perspective the proposed format seems a poor match to meet > the goals that has been expressed. Thus, I would like to request that the= use > cases and goals of the work is clarified before we start work on a soluti= on in > this WG. > > > > I also have to remark that I find it strange that the proposed solution= with a > payload has a parameter that indicate the format of the MPD, i.e. HLS or = DASH, > rather than indicate the actual media format, i.e. MPEG TS or what type o= f > ISOBMFF, that is included in the payloads. [Rachel]: The consideration is to let multicast gateway as simple as possib= le. Instead of analyzing the media segment to convert to different payload = format, it's more simple to just encapsulate in a common format and won't b= reak the end to end encryption mechanism. >=20 > The media format should certainly be signalled, although it can likely go= into > SDP. Is the MPD format (and URL) needed in case the receiver wants to use > HTTP to replace lost RTP packets on the multicast group? [Rachel]: I think so. But MPD files could be transported in out of band way= s. >=20 > > I would also note that the security requirements of this solution needs= to be > discussed. It appears that integrity and source authentication are import= ant, >=20 > Yes, but presumably no more than for any other RTP payload format > specification? >=20 > > and I would at least raise the question if one needs to have some secur= ed > indication of source origin of the media content in some way to prove the= actual > origin of the media content? >=20 > Seems worth discussing. >=20 > > The congestion control section also looks contradicting the earlier sec= tion on > multicast ABR. In HTTP adaptive streaming the ABR part is there to adopt = to > the long term capacity of the network path, where TCP performs congestion > control and probes for the current throughput. In a multicast network, wh= ere > this text appear to indicate that congestion control is not needed becaus= e of > known resource, what is the role of having multiple bit-rates made availa= ble? >=20 > The gateway would presumably fetch multiple quality levels, and send each= on > a different multicast group, allowing the receivers to choose an appropri= ate > level. This should be discussed, I agree. [Rachel]: Exactly. It's quite different from DASH. The scenario is that whe= n M2U serving multiple devices, e.g., mobile phone, and TV. The TV could re= quest the 4K live content, while the mobile phone could just request the 72= 0p resolution. >=20 > > Can we please have these issues resolved before adopting the draft? > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Thu Dec 8 11:24:21 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E596129565 for ; Thu, 8 Dec 2016 11:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AlyUw60h681 for ; Thu, 8 Dec 2016 11:24:17 -0800 (PST) Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E893129545 for ; Thu, 8 Dec 2016 11:24:17 -0800 (PST) Received: from pps.filterd (m0087373.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB8J038Q004201; Thu, 8 Dec 2016 11:14:59 -0800 Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) by mx0b-00195501.pphosted.com with ESMTP id 276whj0rsw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2016 11:14:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OXhDnso0+uLmV2PuXXzKzuvR4b0qxPE0ykU6TGBf9o8=; b=c1ZKXwDCpj9CMh1A61yqXpmdauqCEBzeDuvBLwaLh5sKJdm3VqOJEffbnrrRqeuaku9rALh92Yjxn+I2fE5CwLlrOszdr0g7PU5bXhuuvGbeRW7Dus68AdAC6PUWXk34g4xKPYQBXil/nwTxIMOJa7R8GQohsucdkDnfqiQ8/fo= Received: from CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) by CY4PR05MB3110.namprd05.prod.outlook.com (10.172.157.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Thu, 8 Dec 2016 19:23:59 +0000 Received: from CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) by CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) with mapi id 15.01.0771.008; Thu, 8 Dec 2016 19:23:58 +0000 From: Thomas Edwards To: "Huangyihong (Rachel)" , Colin Perkins , Magnus Westerlund Thread-Topic: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document Thread-Index: AdJEvv+T14loY4UrRdqX5JTuukyVXgLti00AAA4LgYAAIhLXgAAD+xcA Date: Thu, 8 Dec 2016 19:23:58 +0000 Message-ID: <7E548B88-B805-4BFC-BE11-842D2AFBCB60@fox.com> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <77eb312a-36c7-6f7f-f70d-6668cb91c307@ericsson.com> <677F9EDC-0822-4FAB-95C6-5C2E31C9080F@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB87098F10@nkgeml513-mbx.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB87098F10@nkgeml513-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [204.128.192.100] x-ms-office365-filtering-correlation-id: 2d1a5715-f875-4960-51cc-08d41f9fc283 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3110; x-microsoft-exchange-diagnostics: 1; CY4PR05MB3110; 7:YcipHpgupCD+LL2qmBkyl4jH488ZgmT7smCoTh08XfNX+FgvFYaF1Pg5jJTKFaxWOUgLugANEA0PsIpG0dwpeDibbPUhUquY+bAY1bspLUfV0rTxhmhY4I0sxHXhH3eUHcDpRCzsvSadpA8ffpjyHtYzbOWO2TKRGzafG/mIS0I9ej5ZQuDuBoSvZ0GgIUqVy2wag6AOe0aY/PIBdn4EV7otUycg46U/hWmdMNkR2B/L94s6DFRyo/1xXF9BUFQY5KkZrNmwLafGwrsdIdS6cOOX96F2uK+0ZllNeKOYzq18hEiERRl026gwKBpBUaIhqBy/BINsggXBFhOCgFUzS5bpzYZkoSBqIN81+yOhJ7NBkQEM2Cc/VqUJgzvPuN0X7vbYWko1ud6Z22VndVaDmBu50ymWWJ5g32UQFybgdbcXi69PvZFPJNScTg8kQwQEfl1N0tP1aedMkk8QNn2i1Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(177823376758907); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR05MB3110; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3110; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39850400002)(39840400002)(39410400002)(39860400002)(39450400003)(189002)(199003)(24454002)(377454003)(2906002)(54356999)(82746002)(86362001)(2900100001)(4326007)(92566002)(3660700001)(106356001)(102836003)(6116002)(66066001)(6506006)(6512006)(3846002)(83716003)(305945005)(7846002)(8936002)(101416001)(6436002)(76176999)(3280700002)(83506001)(5660300001)(50986999)(8676002)(229853002)(39060400001)(2950100002)(81166006)(230783001)(38730400001)(81156014)(7736002)(122556002)(33656002)(36756003)(105586002)(6486002)(68736007)(97736004)(99286002)(93886004)(77096006)(189998001)(5001770100001)(4001350100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3110; H:CY4PR05MB3109.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <188F8235C2AB234D85D551725E9454A6@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 19:23:58.6977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3110 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-08_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612080277 Archived-At: Cc: "Ali C. Begen" , "payload@ietf.org" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 19:24:20 -0000 T24gMTIvOC8xNiwgMTozMCBBTSwgInBheWxvYWQgb24gYmVoYWxmIG9mIEh1YW5neWlob25nIChS YWNoZWwpIiA8cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByYWNoZWwuaHVh bmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj4gIFtSYWNoZWxdOiBZZXMuIFRoZSB0cmFkaXRpb25h bCB3YXkgaXMgdG8gY29udmVydCBtdWx0aWNhc3QgdG8gdW5pY2FzdCBpbiBIVFRQLiBIb3dldmVy LCB3ZSdyZSB0YXJnZXRpbmcgdGhlIGxpdmUgSFRUUCBzdHJlYW1pbmcgc2VydmljZXMuIEl0J3Mg cmVhbGx5IGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgaW4gQ1BFIGRldmljZXMgY29uc2lkZXJpbmcg Y3VycmVudA0KPiBjYXBhYmlsaXR5IGFuZCByZXNvdXJjZXMgb2Ygc3VjaCBkZXZpY2VzLg0KDQpJ dCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgRHlsZSBNb2JpbGUgVFYgc2VydmljZSBpbiB0aGUg VVMgZGV2ZWxvcGVkIGEgc29sdXRpb24gdGhhdCByYW4gb24gaVBob25lcyB0byB0YWtlIG11bHRp Y2FzdCBSVFAgcGFja2V0cyAoZnJvbSBhIG1vYmlsZSBEVFYgcmVjZWl2ZXIgZG9uZ2xlKSwgYW5k IHRoZW4gaW4gc29mdHdhcmUgb24gdGhlIGlQaG9uZSBjb252ZXJ0ZWQgdGhvc2UgbXVsdGljYXN0 IFJUUCBwYWNrZXRzIGludG8gdW5pY2FzdCBIVFRQIGRlbGl2ZXJlZCBITFMgZm9yIHBsYXliYWNr IHZpYSB0aGUgaU9TIEhMUyBBUEkuICANCg0KLVRob21hcw0KDQotLSANClRob21hcyBFZHdhcmRz IA0KVlAgRW5naW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KRk9YIE5ldHdvcmtzIEVuZ2luZWVyaW5n IGFuZCBPcGVyYXRpb25zDQp0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQpQaG9uZTogKzEuMzEwLjM2 OS42Njk2DQoxMDIwMSBXZXN0IFBpY28gQmx2ZC4NCkxvcyBBbmdlbGVzLCBDQSA5MDAzNQ0KDQog DQoNCiANCg0K From nobody Thu Dec 8 12:44:23 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07D129699 for ; Thu, 8 Dec 2016 12:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 6VoXujXx4kuf for ; Thu, 8 Dec 2016 12:44:20 -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 6CE7B129555 for ; Thu, 8 Dec 2016 12:44:20 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uB8KiHs5074597 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 8 Dec 2016 14:44:18 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Roni Even" Date: Thu, 08 Dec 2016 14:44:18 -0600 Message-ID: <8DE67D6B-8BAC-4EE1-BEFC-39EBD68524BF@nostrum.com> In-Reply-To: <004b01d244bf$0087fc80$0197f580$@gmail.com> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_F1054E6D-A5CC-4B9F-9142-C0A3DFA0BEBF_=" Embedded-HTML: [{"HTML":[881, 2203], "plain":[468, 357], "uuid":"062031AB-17B0-495A-8868-B12F68BA0A39"}] X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: "Ali C. Begen" , payload@ietf.org Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 20:44:22 -0000 --=_MailMate_F1054E6D-A5CC-4B9F-9142-C0A3DFA0BEBF_= Content-Type: text/plain; format=flowed Out of curiosity, has there been any discussion between the authors of this draft and the people interested in GGIE (Glass-to-Glass Internet Ecosystem) at W3C, and as was discussed at the DISPATCH meeting in Berlin? I recognize this is talking about live content, and so far GGIE has mainly talked about stored content. But it still might be interesting to see if there are intersections in the use cases. Thanks! Ben. On 22 Nov 2016, at 6:50, Roni Even wrote: > Hi, > > This is a call to adopt draft-wei-payload-has-over-rtp-01 as a Payload > WG > document and create a milestone for this > > There was already support to adopt it in the payload session at > IETF97 and > this email is to verify the support > > > > Please provide any view to the list by December 7th > > > > > > Thanks > > Roni Even > > Payload co-chair > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=_MailMate_F1054E6D-A5CC-4B9F-9142-C0A3DFA0BEBF_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Out of curiosity, has there been any discussion between th= e authors of this draft and the people interested in GGIE (Glass-to-Glass= Internet Ecosystem) at W3C, and as was discussed at the DISPATCH meeting= in Berlin?

I recognize this is talking about live content, and so fa= r GGIE has mainly talked about stored content. But it still might be inte= resting to see if there are intersections in the use cases.

Thanks!

Ben.

On 22 Nov 2016, at 6:50, Roni Even wrote:

=C2=A0

Hi= ,

This is a call to adopt draft-wei-payload= -has-over-rtp-01 as a Payload WG document and create a milestone for this=

There was already support to adopt= it in=C2=A0 the payload session at IETF97 and this email is to verify th= e support

=C2=A0

Please provide any view to the list by= December 7th

=C2=A0

=C2=A0

Thanks=

Roni Even

=C2=A0

____________________________________________= ___
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

--=_MailMate_F1054E6D-A5CC-4B9F-9142-C0A3DFA0BEBF_=-- From nobody Fri Dec 9 00:39:41 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AF112A1F9 for ; Fri, 9 Dec 2016 00:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q9XppStA6fkW for ; Fri, 9 Dec 2016 00:39:38 -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 156EF12A1F3 for ; Fri, 9 Dec 2016 00:39:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWU71212; Fri, 09 Dec 2016 08:39:11 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 9 Dec 2016 08:39:01 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 9 Dec 2016 16:38:57 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell , Roni Even Thread-Topic: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document Thread-Index: AdJEvv+T14loY4UrRdqX5JTuukyVXgMkcqwAAB9lStA= Date: Fri, 9 Dec 2016 08:38:56 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8709B76E@nkgeml513-mbx.china.huawei.com> References: <004b01d244bf$0087fc80$0197f580$@gmail.com> <8DE67D6B-8BAC-4EE1-BEFC-39EBD68524BF@nostrum.com> In-Reply-To: <8DE67D6B-8BAC-4EE1-BEFC-39EBD68524BF@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.78.221] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB8709B76Enkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.584A6DB0.0226, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4c5acdba58e50e19583f12f7ebe2de2e Archived-At: Cc: "Ali C. Begen" , "payload@ietf.org" Subject: Re: [payload] call to adopt draft-wei-payload-has-over-rtp-01 as a payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:39:41 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB8709B76Enkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJ4oCZdmUgdGFsa2VkIHRvIHRoZW0uIEkgdGhpbmsgR0dJRSBpcyBraW5kIGxpa2UgSUNO IGV4Y2VwdCB0aGV5IHdhbnQgdG8gdXNlIElQdjYgYWRkcmVzcyB0byBuYW1lIHRoZSBjb250ZW50 LiBUaGUgYmVuZWZpdCBpcyB0aGF0IGl0IGNhbiBzdGlsbCB1c2UgY3VycmVudCBuZXR3b3JrIHJv dXRpbmcgbWVjaGFuaXNtcy4gQW5kIHdlIHNoYXJlIHRoZSBzYW1lIHZpZXcgdGhhdCB2aWRlbyBp cyBkb21pbmF0aW5nIHRoZSBuZXR3b3JrIGFuZCBjb3VsZCBiZSBhIGJpZyBwcm9ibGVtIGluIHRo ZSBmdXR1cmUgd2hlbiA0SyBvciA4SyB2aWRlbyBpcyBwcmV2YWxlbnQuIEdHSUUgYW5kIG91ciBo YXMgb3ZlciBSVFAgZ28gZm9yIHR3byBkaWZmZXJlbnQgZGlyZWN0aW9ucy4gR0dJRSB3YW50cyB0 byB1c2UgbmV3IGNvbnRlbnQgZGlzdHJpYnV0aW9uIG1ldGhvZC4gSGFzIG92ZXIgUlRQIGludGVu ZHMgdG8gdXNlIG11bHRpY2FzdCB0byBzb2x2ZSB0aGUgZXhwbG9zaW9uIG9mIHRoZSBsaXZlIHZp ZGVvIHRyYWZmaWMuDQoNCkJSLA0KUmFjaGVsDQoNCkZyb206IHBheWxvYWQgW21haWx0bzpwYXls b2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gQ2FtcGJlbGwNClNlbnQ6IEZy aWRheSwgRGVjZW1iZXIgMDksIDIwMTYgNDo0NCBBTQ0KVG86IFJvbmkgRXZlbg0KQ2M6IEFsaSBD LiBCZWdlbjsgcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwYXlsb2FkXSBjYWxsIHRv IGFkb3B0IGRyYWZ0LXdlaS1wYXlsb2FkLWhhcy1vdmVyLXJ0cC0wMSBhcyBhIHBheWxvYWQgV0cg ZG9jdW1lbnQNCg0KDQpPdXQgb2YgY3VyaW9zaXR5LCBoYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vz c2lvbiBiZXR3ZWVuIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgYW5kIHRoZSBwZW9wbGUgaW50 ZXJlc3RlZCBpbiBHR0lFIChHbGFzcy10by1HbGFzcyBJbnRlcm5ldCBFY29zeXN0ZW0pIGF0IFcz QywgYW5kIGFzIHdhcyBkaXNjdXNzZWQgYXQgdGhlIERJU1BBVENIIG1lZXRpbmcgaW4gQmVybGlu Pw0KDQpJIHJlY29nbml6ZSB0aGlzIGlzIHRhbGtpbmcgYWJvdXQgbGl2ZSBjb250ZW50LCBhbmQg c28gZmFyIEdHSUUgaGFzIG1haW5seSB0YWxrZWQgYWJvdXQgc3RvcmVkIGNvbnRlbnQuIEJ1dCBp dCBzdGlsbCBtaWdodCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgYXJlIGludGVyc2Vj dGlvbnMgaW4gdGhlIHVzZSBjYXNlcy4NCg0KVGhhbmtzIQ0KDQpCZW4uDQoNCk9uIDIyIE5vdiAy MDE2LCBhdCA2OjUwLCBSb25pIEV2ZW4gd3JvdGU6DQoNCg0KDQpIaSwNCg0KVGhpcyBpcyBhIGNh bGwgdG8gYWRvcHQgZHJhZnQtd2VpLXBheWxvYWQtaGFzLW92ZXItcnRwLTAxIGFzIGEgUGF5bG9h ZCBXRyBkb2N1bWVudCBhbmQgY3JlYXRlIGEgbWlsZXN0b25lIGZvciB0aGlzDQoNClRoZXJlIHdh cyBhbHJlYWR5IHN1cHBvcnQgdG8gYWRvcHQgaXQgaW4gIHRoZSBwYXlsb2FkIHNlc3Npb24gYXQg SUVURjk3IGFuZCB0aGlzIGVtYWlsIGlzIHRvIHZlcmlmeSB0aGUgc3VwcG9ydA0KDQoNCg0KUGxl YXNlIHByb3ZpZGUgYW55IHZpZXcgdG8gdGhlIGxpc3QgYnkgRGVjZW1iZXIgN3RoDQoNCg0KDQoN Cg0KVGhhbmtzDQoNClJvbmkgRXZlbg0KDQpQYXlsb2FkIGNvLWNoYWlyDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF5bG9hZCBtYWlsaW5n IGxpc3QNCnBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BheWxvYWQNCg== --_000_51E6A56BD6A85142B9D172C87FC3ABBB8709B76Enkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlllcywgSeKAmXZlIHRhbGtlZCB0byB0aGVtLiBJIHRoaW5rIEdHSUUgaXMga2lu ZCBsaWtlIElDTiBleGNlcHQgdGhleSB3YW50IHRvIHVzZSBJUHY2IGFkZHJlc3MgdG8gbmFtZSB0 aGUgY29udGVudC4gVGhlIGJlbmVmaXQgaXMgdGhhdCBpdCBjYW4gc3RpbGwNCiB1c2UgY3VycmVu dCBuZXR3b3JrIHJvdXRpbmcgbWVjaGFuaXNtcy4gQW5kIHdlIHNoYXJlIHRoZSBzYW1lIHZpZXcg dGhhdCB2aWRlbyBpcyBkb21pbmF0aW5nIHRoZSBuZXR3b3JrIGFuZCBjb3VsZCBiZSBhIGJpZyBw cm9ibGVtIGluIHRoZSBmdXR1cmUgd2hlbiA0SyBvciA4SyB2aWRlbyBpcyBwcmV2YWxlbnQuIEdH SUUgYW5kIG91ciBoYXMgb3ZlciBSVFAgZ28gZm9yIHR3byBkaWZmZXJlbnQgZGlyZWN0aW9ucy4g R0dJRSB3YW50cyB0byB1c2UNCiBuZXcgY29udGVudCBkaXN0cmlidXRpb24gbWV0aG9kLiBIYXMg b3ZlciBSVFAgaW50ZW5kcyB0byB1c2UgbXVsdGljYXN0IHRvIHNvbHZlIHRoZSBleHBsb3Npb24g b2YgdGhlIGxpdmUgdmlkZW8gdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmFjaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGF5bG9hZCBbbWFpbHRv OnBheWxvYWQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMDksIDIwMTYgNDo0NCBBTTxi cj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuPGJyPg0KPGI+Q2M6PC9iPiBBbGkgQy4gQmVnZW47IHBh eWxvYWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXlsb2FkXSBjYWxsIHRv IGFkb3B0IGRyYWZ0LXdlaS1wYXlsb2FkLWhhcy1vdmVyLXJ0cC0wMSBhcyBhIHBheWxvYWQgV0cg ZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PdXQgb2YgY3VyaW9z aXR5LCBoYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBhdXRob3JzIG9m IHRoaXMgZHJhZnQgYW5kIHRoZSBwZW9wbGUgaW50ZXJlc3RlZCBpbiBHR0lFIChHbGFzcy10by1H bGFzcyBJbnRlcm5ldCBFY29zeXN0ZW0pIGF0IFczQywgYW5kIGFzIHdhcyBkaXNjdXNzZWQgYXQg dGhlIERJU1BBVENIDQogbWVldGluZyBpbiBCZXJsaW4/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHJlY29nbml6ZSB0aGlzIGlzIHRhbGtpbmcgYWJv dXQgbGl2ZSBjb250ZW50LCBhbmQgc28gZmFyIEdHSUUgaGFzIG1haW5seSB0YWxrZWQgYWJvdXQg c3RvcmVkIGNvbnRlbnQuIEJ1dCBpdCBzdGlsbCBtaWdodCBiZSBpbnRlcmVzdGluZyB0byBzZWUg aWYgdGhlcmUgYXJlIGludGVyc2VjdGlvbnMgaW4gdGhlIHVzZSBjYXNlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIDIyIE5vdiAyMDE2LCBhdCA2OjUw LCBSb25pIEV2ZW4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxkaXYgaWQ9IjA2MjAzMUFCLTE3QjAtNDk1QS04ODY4 LUIxMkY2OEJBMEEzOSI+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM3Nzc3NzciPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjE1Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjBjbTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izc3Nzc3NyI+VGhpcyBpcyBh IGNhbGwgdG8gYWRvcHQgZHJhZnQtd2VpLXBheWxvYWQtaGFzLW92ZXItcnRwLTAxIGFzIGEgUGF5 bG9hZCBXRyBkb2N1bWVudCBhbmQgY3JlYXRlIGEgbWlsZXN0b25lIGZvciB0aGlzDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhlcmUgd2FzIGFscmVhZHkgc3VwcG9ydCB0byBhZG9wdCBpdCBp biZuYnNwOyB0aGUgcGF5bG9hZCBzZXNzaW9uIGF0IElFVEY5NyBhbmQgdGhpcyBlbWFpbCBpcyB0 byB2ZXJpZnkgdGhlIHN1cHBvcnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izc3 Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBwcm92aWRlIGFueSB2aWV3IHRv IHRoZSBsaXN0IGJ5IERlY2VtYmVyIDc8c3VwPnRoPC9zdXA+DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1i b3R0b206LjAwMDFwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Um9uaSBFdmVuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGF5bG9h ZCBjby1jaGFpcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpwYXlsb2FkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpwYXlsb2FkQGlldGYu b3JnIj5wYXlsb2FkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF5bG9hZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzOTgzQzQi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF5bG9hZDwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_51E6A56BD6A85142B9D172C87FC3ABBB8709B76Enkgeml513mbxchi_-- From nobody Tue Dec 13 14:02:51 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7412946A; Tue, 13 Dec 2016 14:02:47 -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.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148166656776.10847.15219419686545173243.idtracker@ietfa.amsl.com> Date: Tue, 13 Dec 2016 14:02:47 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:02:48 -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 Payloads of the IETF. Title : RTP Payload Format for MELPe Codec Authors : Victor Demjanenko David Satterlee Filename : draft-ietf-payload-melpe-04.txt Pages : 28 Date : 2016-12-13 Abstract: This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe CodecDecember 13, 2016 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-melpe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-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 Tue Dec 13 14:07:59 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACFE129B62 for ; Tue, 13 Dec 2016 14:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 pqlNuyecyN4c for ; Tue, 13 Dec 2016 14:07:57 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0B71297C4 for ; Tue, 13 Dec 2016 14:07:57 -0800 (PST) X-ASG-Debug-ID: 1481666875-092fd3323d36000001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id BsJCnHSlwbyGvP0f (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Dec 2016 17:07:55 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 95CADB40FB6; Tue, 13 Dec 2016 17:07:55 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" References: <148166656776.10847.15219419686545173243.idtracker@ietfa.amsl.com> In-Reply-To: <148166656776.10847.15219419686545173243.idtracker@ietfa.amsl.com> Date: Tue, 13 Dec 2016 17:07:48 -0500 X-ASG-Orig-Subj: RE: [payload] I-D Action: draft-ietf-payload-melpe-04.txt Message-ID: <09ee01d2558d$575f0380$061d0a80$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJVjMjP2ffWG+63SXukvl5B2s6JPQAAEfAQ Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1481666875 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35146 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: "'Ali C. Begen'" , payload@ietf.org, "'Dave Satterlee \(Vocal\)'" Subject: Re: [payload] I-D Action: draft-ietf-payload-melpe-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:07:59 -0000 Hi Roni, We have addressed the nits and your suggestions for this draft. Let us know if anything else needs to be done. Thanks, Victor -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, December 13, 2016 5:03 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-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 Payloads of the IETF. Title : RTP Payload Format for MELPe Codec Authors : Victor Demjanenko David Satterlee Filename : draft-ietf-payload-melpe-04.txt Pages : 28 Date : 2016-12-13 Abstract: This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe CodecDecember 13, 2016 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-melpe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-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/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Mon Dec 19 07:59:08 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01D129BA2; Mon, 19 Dec 2016 07:59:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148216314410.12854.3537469606399566244.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 07:59:04 -0800 Archived-At: Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure Nokia Technologies Oy's Statement about IPR related to RFC 6190 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:59:04 -0000 Dear Thomas Schierl, Alex Eleftheriadis, Stephan Wenger, Ye-Kui Wang: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format for Scalable Video Coding" (RFC6190) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2925/). The title of the IPR disclosure is "Nokia Technologies Oy's Statement about IPR related to RFC 6190" Thank you IETF Secretariat From nobody Wed Dec 21 14:49:56 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06F129627; Wed, 21 Dec 2016 14:49:51 -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.40.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148236059102.12585.1910883780304092680.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2016 14:49:51 -0800 Archived-At: Cc: payload-chairs@ietf.org, draft-ietf-payload-melpe@ietf.org, payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for MELPe Codec) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 22:49:51 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for MELPe Codec' 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 2017-01-13. 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 This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe CodecDecember 13, 2016 The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2387/ From nobody Sun Dec 25 18:12:42 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7149F129521; Sun, 25 Dec 2016 18:12:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148271835146.28347.7596373310873834703.idtracker@ietfa.amsl.com> Date: Sun, 25 Dec 2016 18:12:31 -0800 Archived-At: Cc: draft-ietf-payload-melpe.all@ietf.org, iesg@ietf.org, payload@ietf.org Subject: [payload] Review of draft-ietf-payload-melpe-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 02:12:31 -0000 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This document is mostly ready but has some potential issues: 1. Normative statements -- there are a number of "recommended" and "shall" among "RECOMMENDED" and "SHALL". It would not hurt to revise and confirm the normative level of each of these. Specifically, a couple of these relate to one operational aspect of Default values: E.g.: Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. Should thouse be normative / uppercase as per its operational implications? 2. References It is not entirely clear to me that the references are adequately split in Normative vs. Informative. I understand these three for example are not produced by the IETF; but are they necessary to understand the spec? [MELP] Department of Defense Telecommunications Standard, "Analog-to- Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Linear Prediction (MELP)", MIL-STD-3005, December 1999. [MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S, 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice Coder", STANAG No. 4591, January 2006. [SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210, December 2007. Also, sure, a google search can find them (I believe), but is there an authoritative pointer (URI) where these can be normatively found? Thanks, -- Carlos. From nobody Sun Dec 25 19:02:57 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0107012957E; Sun, 25 Dec 2016 19:02:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148272136799.28234.15989368384638455485.idtracker@ietfa.amsl.com> Date: Sun, 25 Dec 2016 19:02:47 -0800 Archived-At: Cc: draft-ietf-payload-melpe.all@ietf.org, ietf@ietf.org, payload@ietf.org, brian.e.carpenter@gmail.com Subject: [payload] Review of draft-ietf-payload-melpe-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 03:02:48 -0000 Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-6tisch-minimal-17 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-payload-melpe-04.txt Reviewer: Brian Carpenter Review Date: 2016-12-26 IETF LC End Date: 2017-01-13 IESG Telechat date: Summary: Ready with minor issues -------- Major Issues: None ------------- Minor issues: ------------- > 3.1 MELPe Bitstream Definition > > The total number of bits used to describe one frame of 2400 bps > speech is 54, which fits in 7 octets (with two unused bits). For the > 1200 bps speech the total number of bits used is 81, which fits in 11 > octets (with seven unused bits). For the 600 bps speech the total > number of bits used is 54, which fits in 7 octets (with two unused > bits). Unused bits are coded as described in 3.3 in support of > dynamic bit-rate switching. It would help the reader if the last sentence said something like: Unused bits, shown below as RSVA, RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate switching. > 3.3 Multiple MELPe frames in a RTP packet ... > When dynamic bit-rate switching is used and more than one frame is > contained in a RTP packet, it is recommended to inspect the coder > rate bits contained in the last octet. If the coder bit rate > indicates a Comfort Noise frame, then inspect the third last octet > for the coder bit rate. All MELPe speech frames in the RTP packet > will be of this same coder bit rate. I agree with the AD review that this should be RECOMMENDED. > 4.2 Mapping to SDP ... > Alternative encoding name types, > "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey > fixed bit-rate configurations. I think that should be MAY. If you really want to discourage this usage, you would need to say SHOULD NOT. Lower-case "may" is unclear in this case. > 6 Packet Loss Concealment The "may" and "recommended" in this section are unclear - should they be MAY and RECOMMENDED? According to the writeup "There are existing implementations." It's a shame that there is no Implementation Status section (RFC 6982). Nits: ----- "declaritive" should be "declarative" (twice) > 3.4 Congestion Control Considerations > > The target bitrate of MELPe can be adjusted at any point in time, > thus allowing efficient congestion control. Furthermore, the amount I would rephrase "efficient congestion control", because at present the word "efficient" isn't really justified by the text. How about "thus allowing straightforward congestion management"? > of encoded speech or audio data encoded in a single packet can be > used for congestion control, since the transmission rate is inversely > proportional to the packet duration. Make that "the packet rate", because "transmission rate" could refer to the bit rate or the packet rate. At the moment the reader might miss that until the following sentence. From nobody Mon Dec 26 22:10:41 2016 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05409129495; Mon, 26 Dec 2016 22:10:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148281903901.6270.245993854180496707.idtracker@ietfa.amsl.com> Date: Mon, 26 Dec 2016 22:10:39 -0800 Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org Subject: [payload] payload - New Meeting Session Request for IETF 98 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 06:10:39 -0000 A new meeting session request has just been submitted by Roni Even, a Chair of the payload working group. --------------------------------------------------------- Working Group Name: Audio/Video Transport Payloads Area Name: Applications and Real-Time Area Session Requester: Roni Even Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 70 Conflicts to Avoid: First Priority: tsvwg rmcat xrblock rtcweb avtcore mmusic dispatch avtext netvc perc quic Second Priority: tram sipcore lmap stir Third Priority: tls Special Requests: will be good directly after avtcore ---------------------------------------------------------