From nobody Fri Jun 3 23:54: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 AF53E12B042; Fri, 3 Jun 2016 23:54:55 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160604065455.19197.21984.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 23:54:55 -0700 Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org Subject: [payload] payload - Not having a session at IETF 96 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: Sat, 04 Jun 2016 06:54:56 -0000 Ali Begen, a chair of the payload working group, indicated that the payload working group does not plan to hold a session at IETF 96. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Jun 9 03:23:12 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 D836512B078 for ; Thu, 9 Jun 2016 03:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 Gh7Rjf9SgJqR for ; Thu, 9 Jun 2016 03:23:09 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADCE12B02D for ; Thu, 9 Jun 2016 03:23:09 -0700 (PDT) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u59AN7pO017519 for ; Thu, 9 Jun 2016 11:23:07 +0100 (BST) Received: from BGB01XI1016.national.core.bbc.co.uk (10.161.14.79) by BGB01XI1005.national.core.bbc.co.uk (10.184.50.55) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Jun 2016 11:23:07 +0100 Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1016.national.core.bbc.co.uk ([10.161.14.79]) with mapi id 14.03.0195.001; Thu, 9 Jun 2016 11:23:06 +0100 From: James Barrett To: "payload@ietf.org" Thread-Topic: Update to draft-weaver-payload-rtp-vc2hq-02 Thread-Index: AQHRwjjp5F95qLZpg0GJiXydYCkFIQ== Date: Thu, 9 Jun 2016 10:23:06 +0000 Message-ID: <017FD773-56C5-4AC6-86CE-B9A88CC832DB@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-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22380.006 X-TM-AS-Result: No--10.375500-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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 X-EXCLAIMER-MD-CONFIG: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Archived-At: Subject: [payload] Update to draft-weaver-payload-rtp-vc2hq-02 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, 09 Jun 2016 10:23:11 -0000 77u/TXkgZHJhZnQgZHJhZnQtd2VhdmVyLXBheWxvYWQtcnRwLXZjMmhxLTAxIGhhcyBub3cgYmVl biB1cGRhdGVkIHdpdGggYSBuZXcgdmVyc2lvbiBkcmFmdC13ZWF2ZXItcGF5bG9hZC1ydHAtdmMy aHEtMDIuIFRoZSBvbmx5IGNoYW5nZSBpcyBhIGNvcnJlY3Rpb24gb2YgYSB0eXBvZ3JhcGhpY2Fs IGVycm9yIGluIHNlY3Rpb24gNC40ICh0aGFua3MgdG8gVGhvbWFzIEVkd2FyZHMgZm9yIHNwb3R0 aW5nIGl0KS4NCg0KLS0NCkphbWVzIFAuIFdlYXZlciAobsOpIEJhcnJldHQpDQpSZXNlYXJjaCBF bmdpbmVlcg0KQkJDIFImRCBOb3J0aCBMYWIsDQpGbG9vciA1IERvY2sgSG91c2UsIE1lZGlhQ2l0 eSwNCk01MCAyTEgNClRlbDogKzQ0KDApMzAgMzA0MC05NTIxDQplLW1haWw6IGphbWVzLmJhcnJl dHRAYmJjLmNvLnVrDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaHR0cDov L3d3dy5iYmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25m aWRlbnRpYWwgYW5kIA0KbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0 aGUgdmlld3Mgb2YgdGhlIEJCQyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIGl0IGluIA0KZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5 c3RlbS4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIA0KaW5mb3JtYXRpb24gaW4g YW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciAN CmltbWVkaWF0ZWx5Lg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFpbHMg DQpzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5 b3VyIGNvbnNlbnQgdG8gDQp0aGlzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0= From nobody Thu Jun 9 03:31:05 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 6D7FA12B02D for ; Thu, 9 Jun 2016 03:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 8_1eb0XvHWXt for ; Thu, 9 Jun 2016 03:31:01 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EA112D5B9 for ; Thu, 9 Jun 2016 03:31:00 -0700 (PDT) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u59AUxRi006930 for ; Thu, 9 Jun 2016 11:30:59 +0100 (BST) Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0195.001; Thu, 9 Jun 2016 11:30:59 +0100 From: James Barrett To: "payload@ietf.org" Thread-Topic: [payload] Update to draft-weaver-payload-rtp-vc2hq-02 Thread-Index: AQHRwjjpw3aJqo25+Eeszn8AQ2zBKp/g3tAA Date: Thu, 9 Jun 2016 10:30:58 +0000 Message-ID: References: <017FD773-56C5-4AC6-86CE-B9A88CC832DB@bbc.co.uk> In-Reply-To: <017FD773-56C5-4AC6-86CE-B9A88CC832DB@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: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22380.006 x-tm-as-result: No--50.273800-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: <217605C7BD606A4D88B146F7A89CA36D@bbc.co.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [payload] Update to draft-weaver-payload-rtp-vc2hq-02 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, 09 Jun 2016 10:31:04 -0000 U29ycnksIHRoYW5rcyBzaG91bGQgYmUgdG8gVGhvbWFzIFZvbGtlcnQsIG5vdCBUaG9tYXMgRWR3 YXJkcy4NCg0KLS0NCkphbWVzIFAuIFdlYXZlciAobsOpIEJhcnJldHQpDQpSZXNlYXJjaCBFbmdp bmVlcg0KQkJDIFImRCBOb3J0aCBMYWIsDQpGbG9vciA1IERvY2sgSG91c2UsIE1lZGlhQ2l0eSwN Ck01MCAyTEgNClRlbDogKzQ0KDApMzAgMzA0MC05NTIxDQplLW1haWw6IGphbWVzLmJhcnJldHRA YmJjLmNvLnVrDQoNCj4gT24gOSBKdW4gMjAxNiwgYXQgMTE6MjMsIEphbWVzIEJhcnJldHQgPEph bWVzLkJhcnJldHRAYmJjLmNvLnVrPiB3cm90ZToNCj4gDQo+IE15IGRyYWZ0IGRyYWZ0LXdlYXZl ci1wYXlsb2FkLXJ0cC12YzJocS0wMSBoYXMgbm93IGJlZW4gdXBkYXRlZCB3aXRoIGEgbmV3IHZl cnNpb24gZHJhZnQtd2VhdmVyLXBheWxvYWQtcnRwLXZjMmhxLTAyLiBUaGUgb25seSBjaGFuZ2Ug aXMgYSBjb3JyZWN0aW9uIG9mIGEgdHlwb2dyYXBoaWNhbCBlcnJvciBpbiBzZWN0aW9uIDQuNCAo dGhhbmtzIHRvIFRob21hcyBFZHdhcmRzIGZvciBzcG90dGluZyBpdCkuDQo+IA0KPiAtLQ0KPiBK YW1lcyBQLiBXZWF2ZXIgKG7DqSBCYXJyZXR0KQ0KPiBSZXNlYXJjaCBFbmdpbmVlcg0KPiBCQkMg UiZEIE5vcnRoIExhYiwNCj4gRmxvb3IgNSBEb2NrIEhvdXNlLCBNZWRpYUNpdHksDQo+IE01MCAy TEgNCj4gVGVsOiArNDQoMCkzMCAzMDQwLTk1MjENCj4gZS1tYWlsOiBqYW1lcy5iYXJyZXR0QGJi Yy5jby51aw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBo dHRwOi8vd3d3LmJiYy5jby51aw0KPiBUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykg aXMgY29uZmlkZW50aWFsIGFuZCANCj4gbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2gg YXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJCQyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4N Cj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gDQo+IGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0uDQo+IERvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIA0K PiBpbmZvcm1hdGlvbiBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5v dGlmeSB0aGUgc2VuZGVyIA0KPiBpbW1lZGlhdGVseS4NCj4gUGxlYXNlIG5vdGUgdGhhdCB0aGUg QkJDIG1vbml0b3JzIGUtbWFpbHMgDQo+IHNlbnQgb3IgcmVjZWl2ZWQuDQo+IEZ1cnRoZXIgY29t bXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkgeW91ciBjb25zZW50IHRvIA0KPiB0aGlzLg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBwYXlsb2FkIG1haWxpbmcgbGlzdA0KPiBwYXlsb2FkQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF5bG9hZA0K DQo= From nobody Thu Jun 9 07:21:33 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 08F7712D578 for ; Thu, 9 Jun 2016 07:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDMvuNI3FG83 for ; Thu, 9 Jun 2016 07:21:30 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBA412D559 for ; Thu, 9 Jun 2016 07:21:30 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id p204so65337975oih.3 for ; Thu, 09 Jun 2016 07:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0IvmC5Qx5UlFyPOUm2PTff8F5d4lqVZHT1SBOVK/zD0=; b=fZRW1VLPEJXGZkKyZ/Ft6um1H4qS+UEFZEsHSGjNFIcAyXWvb5hfeIsZr/sXxETt0M H+qV1sQ1vBjRNEcG9bU6mpn+50zdkxW/w6DElbOc0j/ylggPoh6WIJWmFxobEWavLIbE U9VGnfFlnusoEnOy38bBcYW/RwfAwgMmzUb+64TSbykzzK0eSw7cQBibkfn/w3DJKwcF 4PhrPhFEVC+iqcW7MdDcnczMPyFXPvWlyzXnPBWYzgLrVHrVLxJ0EkXY/nwUxqcegCyz RVS03+s9pycwEfR4qVfziQWyLulKvQyUCKhjEUaiLkq5mr8LYt5Myyl7sVmVaZh+lHNw YNhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0IvmC5Qx5UlFyPOUm2PTff8F5d4lqVZHT1SBOVK/zD0=; b=ErEwecmuBfoKiACCPreBFzkJGHdoNHCTSzJM8CyXKiD3v155HB2jpU/7Uuji9YCbGW jhbUg4rthqUumFRy2fJsr1aTJZdQ/s2J6++X1YliVEmicq/+ETFSLiz31wr7Mc8TYi5d c4GjTzd5Emqv9vPp5Os7DJf9MQJ3QNnqrcOY7jR+N6tS85d7QUEkq6d7XwIhsw7pow3M wic2IPX7NN3m3IaLBZh7K9NeXH5ufdOUvInJARdvEnZwm4K349+Ie1InYpVUY/tCpqvV VGqBXmmACWVQ6m7F5gxUx5KvvJeEWtgEmJcM67KZiDfaF8gazMsgd1xvPz7xsur1H68q 0h8Q== X-Gm-Message-State: ALyK8tJlRVNIl4MKrkVg+tMc7ES+mqVK/VOLYAlZ+hD8s7c/7/fKNDF3In5zGEvErjbJXN5LCXube8Tiq2xrtA== X-Received: by 10.157.33.132 with SMTP id s4mr5381255otb.61.1465482089486; Thu, 09 Jun 2016 07:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.180.2 with HTTP; Thu, 9 Jun 2016 07:21:28 -0700 (PDT) In-Reply-To: References: From: "Ali C. Begen" Date: Thu, 9 Jun 2016 17:21:28 +0300 Message-ID: To: James Barrett Content-Type: multipart/alternative; boundary=001a114709ae5e5fb50534d9230b Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] Call for adoption (was Re: draft-weaver-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: Thu, 09 Jun 2016 14:21:32 -0000 --001a114709ae5e5fb50534d9230b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks like there was a good support for this draft and no objection. James, please go ahead and submit the WG version of the draft. -acbegen On Thu, May 26, 2016 at 8:44 PM, Ali C. Begen wrote: > Hi everyone > > Please have a look at the draft and let the list know whether you support > the adoption by the Payload WG or not. There has been support from two > individual so far, but let's see what the rest of the working group think= s. > Please respond by Friday June 3rd. > > https://tools.ietf.org/html/draft-weaver-payload-rtp-vc2hq-01 > > -acbegen > > On Wed, May 25, 2016 at 4:29 PM, James Barrett > wrote: > >> What would be the best way to start going about getting a call for >> adoption for draft-weaver-payload-rtp-vc2hq-01? The draft hasn=E2=80=99t= spawned >> much commentary on the list at this point, and no direct issues in need = of >> addressing that I=E2=80=99m aware of. It might be useful to get it (or a= subsequent >> version) put on the agenda for the July meeting. >> >> -- >> James P. Weaver (n=C3=A9 Barrett) >> Research Engineer >> BBC R&D North Lab, >> Floor 5 Dock House, MediaCity, >> M50 2LH >> Tel: +44(0)30 3040-9521 >> e-mail: james.barrett@bbc.co.uk >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > --001a114709ae5e5fb50534d9230b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like there was a good support for this draft and no = objection.

James, please go ahead and submit the WG vers= ion of the draft.

-acbegen

On Thu, May 26, 2016 at 8:4= 4 PM, Ali C. Begen <acbegen@gmail.com> wrote:
Hi everyone=

Pleas= e have a look at the draft and let the list know whether you support the ad= option by the Payload WG or not. There has been support from two individual= so far, but let's see what the rest of the working group thinks. Pleas= e respond by Friday June 3rd.

https://tools.ietf.org/html/draft-= weaver-payload-rtp-vc2hq-01

-acbegen

=
On Wed, May 25, 2016 at 4:29 PM, James Barrett <= span dir=3D"ltr"><James.Barrett@bbc.co.uk> wrote:
= What would be the best way to start going about getting a call for adoption= for draft-weaver-payload-rtp-vc2hq-01? The draft hasn=E2=80=99t spawned mu= ch commentary on the list at this point, and no direct issues in need of ad= dressing that I=E2=80=99m aware of. It might be useful to get it (or a subs= equent version) put on the agenda for the July meeting.

--
James P. Weaver (n=C3=A9 Barrett)
Research Engineer
BBC R&D North Lab,
Floor 5 Dock House, MediaCity,
M50 2LH
Tel: +44(0)30 3040-9521
e-mail: james.= barrett@bbc.co.uk

_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload


--001a114709ae5e5fb50534d9230b-- From nobody Thu Jun 9 07:37:48 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 4131C12D5B6; Thu, 9 Jun 2016 07:37:43 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609143743.16730.49648.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 07:37:43 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-vc2hq-00.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: Thu, 09 Jun 2016 14:37:45 -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-00.txt Pages : 17 Date : 2016-06-09 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 15 20:34:12 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 16B0212D5DE for ; Wed, 15 Jun 2016 20:34:11 -0700 (PDT) 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 XEgtS5IvhtVN for ; Wed, 15 Jun 2016 20:34:09 -0700 (PDT) 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 13D2612D0E5 for ; Wed, 15 Jun 2016 20:34:08 -0700 (PDT) Received: from pps.filterd (m0087372.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5G3XZHE016404 for ; Wed, 15 Jun 2016 20:34:07 -0700 Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by mx0b-00195501.pphosted.com with ESMTP id 23gewvbh9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Jun 2016 20:34:07 -0700 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=BNf7sbxI7GGuF4A/6rog+aJukSytrpIUZjB+mPy3xQg=; b=ZdiJGM2nvpaPKz6t42XeTC+hIZwiHTZ3tNe6VSU5JNZ5e1n6hp3fWHgJRdvBVNGXKzTfLNzdjG3sjF/xxyJzthGjiEPzvGcxeudyQoJOXISs37FHdL+8ASPfdVwbIhiXD1P+A9/gsSLrKWaPJepN/Xde5y6rU5c6uKL1EYniVSs= Received: from SN2PR05MB2448.namprd05.prod.outlook.com (10.166.212.155) by SN2PR05MB2445.namprd05.prod.outlook.com (10.166.212.152) with Microsoft SMTP Server (TLS) id 15.1.517.8; Thu, 16 Jun 2016 03:34:05 +0000 Received: from SN2PR05MB2448.namprd05.prod.outlook.com ([10.166.212.155]) by SN2PR05MB2448.namprd05.prod.outlook.com ([10.166.212.155]) with mapi id 15.01.0517.014; Thu, 16 Jun 2016 03:34:05 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: WGLC comments on draft-ietf-payload-rtp-ancillary-03 Thread-Index: AQHRx3/uP6cFF+UXtU2B8/WPt/p3Jg== Date: Thu, 16 Jun 2016 03:34:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [23.242.16.197] x-ms-office365-filtering-correlation-id: 6b51b4dc-0958-4307-3ca3-08d39597119d x-microsoft-exchange-diagnostics: 1; SN2PR05MB2445; 6:C38+dhHvqdPwlqpJt2Z1OV/pBXyjv9DYDNGpjtWbBsfCbDrJchLtzEXYnAm2FP8ZNgHM1kYjdD76vi8EGZP4WacNv8sphHJ45G8dUm1QKAVtm37i6Xxssjlz09YPkA8zfMH0Ig44zbsbP95A4Ja3sBMSR7p5wHC9HQ0mVgamCrPeRTvbAyGbM9AdKcy5AEUBBSHh1yQC+BvBI03kF2giYXu7K6iWi4HTIuUEuYnc1y3mCU1OV4q0PfD9ErwCyME1q89BY57lbznC0uKNsH3Ynqe9M3zaYt7nQGcZTLXxhNPbT0IvYy5jW6mm+HsGwTtJ; 5:o8xquPKkv3kFL5f/FoK21cB2aPfWPRV/WchZzgfMk0TiNC8CHfETk2pdysX5TVIteEoc6YepN7SAL4Bke7kznAGY5LfBLp8UqPPqGj/pl8OhNhu9R624QaNjGMwcQi3gKoWlZYN6XYjXHZ9ajw8CSA==; 24:kS7EwXMXyRmd0gXIvKEyD+WS6ABEr+PCn1mSsfaHHe5ShmGvMUDQGeSYziXqbKDGR9mT84y1F3HlPIYPnAc8KHLr1hpbeGe3PDWycb8ecZ0=; 7:Tiy+XvqBt3dVFN0MRJ+gm3PUHyLGcUNevC78hevOH8wlcF0CA8ylr1TQ5ftuXSGj2ZwV+Fof4vk4lfF7It84qHOXfkZgNIFr7+HJqH+xPi4XkDVHcl9lKNJ3XMIV1hgGY4VjdqwDpYhldnfthDj5kq/mDAD9sOlgROq1sJowJBVUdcy+V/ipAW6LRJalBimyPH0eVgqe4n9OTR1IMlaxRg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(95692535739014)(127952516941037)(177823376758907); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2445; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2445; x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51444003)(189002)(199003)(83506001)(5640700001)(2906002)(4001350100001)(189998001)(450100001)(97736004)(105586002)(36756003)(99286002)(81166006)(81156014)(1730700003)(122556002)(50986999)(54356999)(5002640100001)(101416001)(8676002)(107886002)(110136002)(8936002)(5004730100002)(10400500002)(2501003)(5008740100001)(6116002)(102836003)(3846002)(92566002)(106116001)(586003)(2351001)(229853001)(68736007)(106356001)(230783001)(15975445007)(77096005)(11100500001)(66066001)(86362001)(19580395003)(19580405001)(3280700002)(87936001)(2900100001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR05MB2445; H:SN2PR05MB2448.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2016 03:34:05.4156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2445 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-16_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606160042 Archived-At: Subject: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03 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, 16 Jun 2016 03:34:11 -0000 Dear Payload WG, I have looked at the WGLC comments on draft-ietf-payload-rtp-ancillary-03. I believe that I have responses to these comments (although I am still working on some offer/answer issues based on SDP Directorate comments). If the group is OK with these, I can edit the I-D and issue a new version. =20 =20 Commenter: Jonathan Lennox Mon, 18 April 2016 15:59 UTC Comment: "No mechanism is given to associate the video/smpte291 streams with their associated video/raw or video/jpeg2000 streams. In complicated scenarios (multiple video streams, e.g.) some SDP grouping might be necessary to provide this association." Response: How about if the I-D is amended with an example SDP file with "a=3Dgroup:LS" to show lip sync grouping as per RFC 5888 between say RFC 4175 video and ANC? Comment: "The RTP clock rate isn=B9t specified. Presumably it should be th= e same as the associated video streams; i.e., normally 90000, but variable for JPEG2000." Response: In the description of the timestamp, the I-D states "A 90-kHz timestamp SHOULD be used". Based on industry input, I believe this is the proper level of specificity. Commenter: James P. Weaver Tue, 19 April 2016 13:11 UTC Comment: "I think that the mime-type should probably not be video/smpte291, but rather application/smpte291. The data carried here isn=B9t video data, so it seems incorrect to use video as the type." Response: We did discus this at the WG F2F in Dallas, and my impression is that the group was OK with video/smpte291 although there were some dissenters. My argument is that SMPTE ST 291 Ancillary Data format only makes sense within a video environment, and frankly it is probably not the optimal way to carry some of this metadata in a more generic case. The broadcast industry appears OK with a video type as far as I have seen through the Video Services Forum Technical Recommendation TR-03 and the SMPTE ST 2110 processes which reference the I-D. Harald Alvestrand Thu, 12 May 2016 07:42 UTC pointed out "If one wishes to multiplex the video and these packets on the same SDP-negotiated RTP session without using BUNDLE, the top level mime-type has to be "video"." So I'd prefer to keep it video/smpte291 unless there is a strong consensus in the group against that. >From the SDP Directorate: Commenter: Dan Wing Thu, 21 Apr 2016 14:42:10 -0700 Comment: "I see the text in 3.1 partially defines the SDP syntax, but is in a section titled "Media Type Definition". Much of that is very specific to SDP (especially the text describing location of comma, use of "{}", suchlike), and should be in section 3.2, "Mapping to SDP"." Response: I can move the SDP-specific info in section 3.1 into section 3.2 Comment: "The text needs to if both DID and SDID are required, because I notice at http://www.smpte-ra.org/smpte-ancillary-data-smpte-st-291, some DIDs SDIDs, such as 0xa0 ("Audio data in HANC space"). Are such DIDs without SDIDs illegal to use with SDP, illegal to use with this RTP Ancillary payload, or anything like that? The I-D should say something about DIDs that don't have SDIDs, and how they are expressed in the SDP. For example is it possible for SMPTE to register a new DID next year which have no SDID, and how do we want that signaled in SDP? This may be solved with a simple, "All DIDs using this RTP Ancillary Payload format will always have SDIDs registered with them by SMPTE.", which may well exist somewhere in the document already and I missed it." Response: It is true that DID 0x80 (deletion) has no required SDID. Some of the audio ANC packets are "Type 1" ANC packets that have Data Block Numbers (DBN) in place of where "Type 2" ANC packets have SDIDs. In either case, one would want to filter based on just the DID. I can make this clear is section 3.2. Comment: "I'd like to see an ABNF syntax of the fmtp parameters, including things like how long the hex values can be, and whether they can have both lower and upper case." Response: I can add the ABNF. -Thomas --=20 Thomas Edwards=09 VP Engineering & Development FOX Networks Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 From nobody Sun Jun 19 08:06: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 5D05512D0FC; Fri, 17 Jun 2016 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 nw28scFq5gM1; Fri, 17 Jun 2016 07:30:04 -0700 (PDT) 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 D039412D5AB; Fri, 17 Jun 2016 07:30:04 -0700 (PDT) Received: from [10.0.1.4] (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 u5HETk5l049371 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2016 09:29:46 -0500 (CDT) (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.4] From: "Ben Campbell" To: payload@ietf.org, "Roni Even" , yekuiwang@huawei.com, tom.kristensen@tandberg.com, rjesup@wgate.com, payload-chairs@ietf.org Date: Fri, 17 Jun 2016 09:29:46 -0500 Message-ID: In-Reply-To: <20160617105301.2A9CBB80D66@rfc-editor.org> References: <20160617105301.2A9CBB80D66@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Sun, 19 Jun 2016 08:06:06 -0700 Cc: ibc@aliax.net, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [payload] [Technical Errata Reported] RFC6184 (4713) 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, 17 Jun 2016 14:30:07 -0000 RFC6184 Authors + other payload WG participants: What do you think of this errata? Thanks! Ben. On 17 Jun 2016, at 5:53, RFC Errata System wrote: > The following errata report has been submitted for RFC6184, > "RTP Payload Format for H.264 Video". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4713 > > -------------------------------------- > Type: Technical > Reported by: Iñaki Baz Castillo > > Section: 8.1 > > Original Text > ------------- > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter > > Corrected Text > -------------- > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > six bytes in the sequence parameter > > Notes > ----- > profile-level-id is composed of three 2-byte length fields. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) > -------------------------------------- > Title : RTP Payload Format for H.264 Video > Publication Date : May 2011 > Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Sun Jun 19 08:06:10 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 3ED3912D5D7; Fri, 17 Jun 2016 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 L6cNOeUMOPDt; Fri, 17 Jun 2016 07:36:29 -0700 (PDT) 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 B332912D52B; Fri, 17 Jun 2016 07:36:29 -0700 (PDT) Received: from [10.0.1.4] (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 u5HEaDv4049962 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2016 09:36:13 -0500 (CDT) (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.4] From: "Ben Campbell" To: payload@ietf.org, "Roni Even" , yekuiwang@huawei.com, tom.kristensen@tandberg.com, rjesup@wgate.com, payload-chairs@ietf.org Date: Fri, 17 Jun 2016 09:36:14 -0500 Message-ID: <396066C1-4679-46B1-9867-C4A1BE1F1A59@nostrum.com> In-Reply-To: References: <20160617105301.2A9CBB80D66@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Sun, 19 Jun 2016 08:06:06 -0700 Cc: ibc@aliax.net, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [payload] [Technical Errata Reported] RFC6184 (4713) 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, 17 Jun 2016 14:36:31 -0000 Also this one: (Normally I would prefer to make changes to 2119 language in an update, not an errata. But if this is purely an error in the text. we can consider it.) Thanks! Ben. > The following errata report has been submitted for RFC6184, > "RTP Payload Format for H.264 Video". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4714 > > -------------------------------------- > Type: Technical > Reported by: Iñaki Baz Castillo > > Section: 8.2.2 > > Original Text > ------------- > To simplify the handling and matching of these configurations, the > same RTP payload type number used in the offer SHOULD also be used > in the answer, as specified in [8] > > [8] points to RFC 3264 "An Offer/Answer Model with the Session > Description Protocol (SDP)" > > Corrected Text > -------------- > > > Notes > ----- > The above statement is wrong. RFC 3264 does not mandate the same > payload > type in both the offer and the answer. In fact, RFC 3264 section 5.1 > states: > > For sendonly RTP streams, the payload type > numbers indicate the value of the payload type field in RTP packets > the offerer is planning to send for that codec. For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to > send. > > However, for sendonly and sendrecv streams, the answer might > indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the > answer. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) > -------------------------------------- > Title : RTP Payload Format for H.264 Video > Publication Date : May 2011 > Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG On 17 Jun 2016, at 9:29, Ben Campbell wrote: > RFC6184 Authors + other payload WG participants: > > What do you think of this errata? > > Thanks! > > Ben. > > On 17 Jun 2016, at 5:53, RFC Errata System wrote: > >> The following errata report has been submitted for RFC6184, >> "RTP Payload Format for H.264 Video". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4713 >> >> -------------------------------------- >> Type: Technical >> Reported by: Iñaki Baz Castillo >> >> Section: 8.1 >> >> Original Text >> ------------- >> profile-level-id: >> A base16 [7] (hexadecimal) representation of the following >> three bytes in the sequence parameter >> >> Corrected Text >> -------------- >> profile-level-id: >> A base16 [7] (hexadecimal) representation of the following >> six bytes in the sequence parameter >> >> Notes >> ----- >> profile-level-id is composed of three 2-byte length fields. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) >> -------------------------------------- >> Title : RTP Payload Format for H.264 Video >> Publication Date : May 2011 >> Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG From nobody Mon Jun 20 07:08:47 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 DA8A1127058; Mon, 20 Jun 2016 07:04:31 -0700 (PDT) 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 zu0gV-noIVi0; Mon, 20 Jun 2016 07:04:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94D712D0CD; Mon, 20 Jun 2016 07:04:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ba-5767f7eb9223 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.A1.18043.BE7F7675; Mon, 20 Jun 2016 16:04:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.294.0; Mon, 20 Jun 2016 16:04:26 +0200 To: , , , , , , , , References: <20160617111801.D0598B80D8D@rfc-editor.org> From: Magnus Westerlund Message-ID: <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> Date: Mon, 20 Jun 2016 16:04:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160617111801.D0598B80D8D@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdTPf19/RwgymzZC32vz/EZDH9zF9G i5c9K9kt5neeZrd49foKq8XTxrOMFpcunmWymNo7m8niScsPZotPnZoWi0/VOXB7tD7by+rx 5clLJo+dpw6webQcecvqsWTJTyaPHZsfsHrM2vmExWPhkXPMHmsnbGcO4IzisklJzcksSy3S t0vgyuhuW8pY8FSiYsLlf8wNjPuEuxg5OSQETCQ2TZ3MAmGLSVy4t56ti5GLQ0jgCKPEtSW7 WUESQgLLGSXO3VEEsYUFHCUWrZnOClIkIvCOUeLqn+fMEEXmEt/nN4BNYhawlLh3ZSMjiM0m YCFx80cjG4jNK2Av8fDAArAaFgFViTdzVoH1igrESDTePswOUSMocXLmE7AaTqDeNd+bgHo5 gGbaSzzYWgYxXl6ieetsqLXaEg1NHawTGAVnIemehdAxC0nHAkbmVYyixanFxbnpRkZ6qUWZ ycXF+Xl6eaklmxiBkXRwy2+rHYwHnzseYhTgYFTi4V1wNy1ciDWxrLgy9xCjBAezkgiv/rf0 cCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M1moyU8/8 UXIKbNVJjlw4kytPoDnIY+renmBFbvk93skBTZNvtDVd/cuQHBz4fUXtrsC9R1+38v5nru8J 6pBXPHDE4se9kBMMjhfuGD44MVlj0VldHkcVr1YxcyMbj2t+b9aesnwp8efwunNbFDqE71R7 WbDFOE+KE6qQdpA5UMGokcum4q3EUpyRaKjFXFScCAClKS4poAIAAA== Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 07:08:45 -0700 Cc: avt@ietf.org, "payload@ietf.org" Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 20 Jun 2016 14:04:32 -0000 Hi, This errata should be handled by the PAYLOAD WG. Please send any feedback to them rather than AVTCORE WG. Cheers Magnus Den 2016-06-17 kl. 13:18, skrev RFC Errata System: > The following errata report has been submitted for RFC6184, > "RTP Payload Format for H.264 Video". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4714 > > -------------------------------------- > Type: Technical > Reported by: Iñaki Baz Castillo > > Section: 8.2.2 > > Original Text > ------------- > To simplify the handling and matching of these configurations, the > same RTP payload type number used in the offer SHOULD also be used > in the answer, as specified in [8] > > [8] points to RFC 3264 "An Offer/Answer Model with the Session > Description Protocol (SDP)" > > Corrected Text > -------------- > > > Notes > ----- > The above statement is wrong. RFC 3264 does not mandate the same payload > type in both the offer and the answer. In fact, RFC 3264 section 5.1 states: > > For sendonly RTP streams, the payload type > numbers indicate the value of the payload type field in RTP packets > the offerer is planning to send for that codec. For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to send. > > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) > -------------------------------------- > Title : RTP Payload Format for H.264 Video > Publication Date : May 2011 > Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 Mon Jun 20 07:08:51 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 5F70212D0DD; Mon, 20 Jun 2016 07:05:31 -0700 (PDT) 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 07_SqF1-vH29; Mon, 20 Jun 2016 07:05:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016AD12D16D; Mon, 20 Jun 2016 07:05:24 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-92-5767f823bb34 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.73.12926.328F7675; Mon, 20 Jun 2016 16:05:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.294.0; Mon, 20 Jun 2016 16:05:18 +0200 To: "payload@ietf.org" , , , , , , , , , References: <20160617105301.2A9CBB80D66@rfc-editor.org> From: Magnus Westerlund Message-ID: Date: Mon, 20 Jun 2016 16:05:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160617105301.2A9CBB80D66@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbE9XFf5R3q4wZpZYhb73x9isph+5i+j xcuelewW8ztPs1u8en2F1eJp41lGi0sXzzJZTO2dzWTxpOUHs8WnTk2LxafqHLg9Wp/tZfX4 8uQlk8fOUwfYPFqOvGX1WLLkJ5PHjs0PWD1m7XzC4rHwyDlmj7UTtjMHcEZx2aSk5mSWpRbp 2yVwZdzv/sVecFK44siFfpYGxhX8XYycHBICJhLnzq9nhbDFJC7cW8/WxcjFISRwhFFi97Nt LBDOckaJ5n3PgTIcHMICjhKX7iSDxEUEpjJJTJ/dzQLSLSRgLrHs3yk2EJtZQEji9JxvYFPZ BCwkbv5oBIvzCthLnP28jwVkDouAqsSv72UgYVGBGInG24fZIUoEJU7OfAI2khOo9fuM/Uwg 5cxArQ+2lkFMl5do3jqbGWKrtkRDUwfrBEbBWUi6ZyF0zELSsYCReRWjaHFqcVJuupGxXmpR ZnJxcX6eXl5qySZGYBwd3PJbdQfj5TeOhxgFOBiVeHgX3E0LF2JNLCuuzD3EKMHBrCTCq/8t PVyINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDoxqz5E9h 6+OPK8tcL76vDW5JcCrg3coRJvhXsrabecWaeWrCX/vdk4vUQmI2T/78lPU926/VwmtOdtx+ yN6Y7bV2WitbwbrO5FU3TK5zq+rrHpX+Z7vq6P9rD9aFPFWb5O0efW+hmfYE/RxLQzMNm1nz ev682/6UUWbVe6e2dwwZChUH1vXYKLEUZyQaajEXFScCABRwlfKfAgAA Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 07:08:45 -0700 Cc: avt@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4713) 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, 20 Jun 2016 14:05:31 -0000 Hi, This errata should be handled by the PAYLOAD WG. Please send any feedback to them rather than AVTCORE WG. Cheers Magnus Den 2016-06-17 kl. 12:53, skrev RFC Errata System: > The following errata report has been submitted for RFC6184, > "RTP Payload Format for H.264 Video". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4713 > > -------------------------------------- > Type: Technical > Reported by: Iñaki Baz Castillo > > Section: 8.1 > > Original Text > ------------- > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter > > Corrected Text > -------------- > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > six bytes in the sequence parameter > > Notes > ----- > profile-level-id is composed of three 2-byte length fields. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) > -------------------------------------- > Title : RTP Payload Format for H.264 Video > Publication Date : May 2011 > Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 Mon Jun 20 13:16:14 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 60D6E12D9E1 for ; Mon, 20 Jun 2016 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 tb1pcBJ6BxDP for ; Mon, 20 Jun 2016 13:16:10 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 C329612D9D7 for ; Mon, 20 Jun 2016 13:16:10 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id b72so22936141ywa.3 for ; Mon, 20 Jun 2016 13:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=PNWHccjZFYp7Ekc5ASJ9kVwtzsw5NV8MteuRvyPauF8=; b=0e5PZd2lKKmuLRMm274A23DlZrtiopPSLY4olsRQDPZvU1S0YqfVFU+dF0Tc1trtXe iWHx8X3DrxmwJr7PzDLgPzlzc4U1TQ9GsKKLbh9ATdLuzPLeQCbZnMfn+KcYvrav30i4 NGO2l4k6EpWDnHgcnnzpGSTFHxzg3Srg41FE9YzUUg4E4b1MQPQV0yA+vtWa5LiR0HbO jafYEn0K46KF8k0J29/1TByHfycRZk0PxIIQZwx22cJarzU1lidJX26mefeW7G4XJ1DK 6OXE8weQ0x8bhkjPOcVu59ZMazMk15lNsA77VeAiyiQ8lfrMonv8cXb13k5KHAlmoHOY VIqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=PNWHccjZFYp7Ekc5ASJ9kVwtzsw5NV8MteuRvyPauF8=; b=cKMwf5ikfczjxGyOpuBEB6N4UWU4IV5bXqCBePudXfF6nJ6EBZeTbuohf0S6p3WtXu 0D6zHVn8IjINElibHNzhOCjlh9YPZrosALpCdqLV+gNVuGUtJqttU22BcaKJZqiCp99y wA2/JiaIGS6XTAj8P72o3ULJ0C3pjOJzcWYzx8iIfpXbkS0mL9Tk46VbtaftC0d72547 duCehzUQ31W4sP2LNdWbYyRFuRG3f8jlob7fgKktv4lzcKtmeyJWSnvQDMs5RWecSJD2 vsiy/NGknz3MAUkMeOkkkkphA6l9PLxVB7SiVmIY+6aTalFB5lTtbCpUeu5m6MpcdlwE 65mQ== X-Gm-Message-State: ALyK8tKRrOBIt5LYds5VsdtOzPZ2jUjHCuMFLHR4kF86ewrJs2dKHWjtrfbm67PzVhmrKJjUlK0du6HpYspfjw== X-Received: by 10.129.39.205 with SMTP id n196mr9381247ywn.74.1466453768695; Mon, 20 Jun 2016 13:16:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Mon, 20 Jun 2016 13:15:49 -0700 (PDT) In-Reply-To: <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jun 2016 22:15:49 +0200 Message-ID: To: "payload@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 20 Jun 2016 20:16:13 -0000 2016-06-19 15:47 GMT+02:00 Mo Zanaty (mzanaty) : > Matching H.264 payloads based on configuration parameters is often error = prone and can lead to interop issues. Using the same payload type number in= the answer for the same configuration offered does simplify things and avo= ids some interop issues. There are cases where this is not possible and asy= mmetric payload type numbers are necessary. So the original text with SHOUL= D strength seems appropriate. Well, I'm not arguing against the usage of SHOULD. The original text says: > To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in RFC 3364. But that is not true. RFC 3264 does not say that "the same RTP payload type number used in the offer SHOULD also be used in the answer". --=20 I=C3=B1aki Baz Castillo From nobody Mon Jun 20 14:46:55 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 E8DF612D58E for ; Mon, 20 Jun 2016 14:46:53 -0700 (PDT) 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 eEz1PxUBgFrP for ; Mon, 20 Jun 2016 14:46:52 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 B4B3012D18C for ; Mon, 20 Jun 2016 14:46:51 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so48155221lfe.3 for ; Mon, 20 Jun 2016 14:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dzKPmM1bj3YAMCQkQPitd+ttqKjW6ZjHjWYn75vDMYU=; b=bBYMZs9CZuuNQ8i0QLOirgvzti/Ig5IqlZur6w8nrxqbOh7+fjFqf+x0nAnuZM0Wab ZyFdVBiPyT9LYy2rXcWUU7LANoVFBaXfA9Scq7C+w/gS1xgadGRGRghc1F8cHtJnirzj WAbrX1RrxsIicXj27XPGl3uieOwEG3r2N11wwurIAiKAqLfx2hQCivPB9WNjtVdlmvxX srDQc3DtI5yj3RaveQJAxAXonFRjlw3Ni2lXvipA0zsUSaMeVns4A08PKpOX05wVA7l+ jms7v1lr1UBlP1j3+CDtv1avfYiiCdvGMPiR/zIi+NzAyTNW1yiEqkk7wgFfKUlqVfVz TCuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=dzKPmM1bj3YAMCQkQPitd+ttqKjW6ZjHjWYn75vDMYU=; b=PFxWHJ3R4RGNnJyH3hqIcrkwVImvmkrWokhjmSbZvxfc5naJBP1T5nUiLzdusb2B/m l7QyG+/ZAnrDS64fK6+AJ05KwyLFqCS3Gv09FEHOlasMWqWnheR/qLnxAorz+YXRUTQM zoVQ/ccp8K+nnqRUtBB7ydD7VIsiuEcw3Ym4ItdYrWglSmYFLEStJ9otDksX2SdKSsES uBCHfyS/yfQfgSfNNoWhwXqfHs9oGkP3gBil1DvNcCiuMC05kYjK34FLZDeVw/fgjWND T8n1fFovoWq5kXUMJsspeHfeSx83XJSy4hZ4xaXv7txTAkGcVW99T1HYxbwif5I8gcYz shKw== X-Gm-Message-State: ALyK8tJVUfUJ7Ntm13EseWslQEfCog8qbtdrSvrSYv5w1asR8SiYJaQHR4WjsLaNN6YYgQ== X-Received: by 10.28.197.140 with SMTP id v134mr121578wmf.2.1466459209788; Mon, 20 Jun 2016 14:46:49 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id b77sm3940350wme.0.2016.06.20.14.46.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 14:46:48 -0700 (PDT) From: "Roni Even" To: =?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?= , References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> In-Reply-To: Date: Tue, 21 Jun 2016 00:45:24 +0300 Message-ID: <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxiAO0N9S2DUtvvNCIjuRxsHP+SgKc4fFzAarHRFSgESypAA== Content-Language: he Archived-At: Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 20 Jun 2016 21:46:54 -0000 Hi, >From RFC3264 section 6.1 "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer." > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of I?aki Baz > Castillo > Sent: Monday, June 20, 2016 11:16 PM > To: payload@ietf.org > Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 > (4714) >=20 > 2016-06-19 15:47 GMT+02:00 Mo Zanaty (mzanaty) : > > Matching H.264 payloads based on configuration parameters is often = error > prone and can lead to interop issues. Using the same payload type = number in > the answer for the same configuration offered does simplify things and > avoids some interop issues. There are cases where this is not possible = and > asymmetric payload type numbers are necessary. So the original text = with > SHOULD strength seems appropriate. >=20 > Well, I'm not arguing against the usage of SHOULD. The original text = says: >=20 > > To simplify the handling and matching of these configurations, the > same RTP payload type number used in the offer SHOULD also be used in = the > answer, as specified in RFC 3364. >=20 > But that is not true. RFC 3264 does not say that "the same RTP payload = type > number used in the offer SHOULD also be used in the answer". >=20 >=20 > -- > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Mon Jun 20 14:56:13 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 E0EB812DA92 for ; Mon, 20 Jun 2016 14:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 Wbj117sNfYLH for ; Mon, 20 Jun 2016 14:56:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0A912DA8E for ; Mon, 20 Jun 2016 14:56:10 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id i12so38847423ywa.1 for ; Mon, 20 Jun 2016 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0sEEWtAPJRICty62cN6DLe6cjhFMkhvb3vQHCMQ6kTU=; b=bsWquF8886l26WE+m/ro2/iHZFXNLiOhJ2IYo+67kgwMTAYTOjUytHWIUpYiMbTcCw wK/xET92iCO8wdvHux6/Z/BjSXdHKXo/cSIvQIpllpKB1251e8jYZn5MWBTIm3DE66lV dn5Sj61pNdavMXpFyttxS+hhxHFNQSqotT3+ZHei0M2jqMWN8vIE8VpKULOG2Uay5vUs plsZgrLeoZCEvgwF7cztUQZycXLcBBR8PrdrOOkY6hZQ0LasfyleVEGHtp3knX7Z2H/H sQao071B29D9uh4bX0Af8Helc1q+7aOTDimQNmzacl/dbqRwIj/FXlHkvIRxtyiPt/Ws EsNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0sEEWtAPJRICty62cN6DLe6cjhFMkhvb3vQHCMQ6kTU=; b=NybAJ2OsssZmeatCKQvdaPYV+AGl55bbuG3oCK/G0Wswt+Yug+LZobIZnECKjgJmkI ue8VAXDg5Yr07ViqLeT99lx6GZ3Zffvhe4AMuNpTodJPGYSvbUX1lLXVAwqKH6v6pytw r2TtJ9ALSOOMtXfPPwEInFLFAlWQGdIlqZAVWk28nYHJOYqfTvxPxfzIY/kvojiHDIzZ 3eWxq6VOGshMm8yKN/fDqeM/EojM/ypi4yjd2UJOe6Uoda3NtIe7cLW2zGpI4IrB7/jt EqGTZqTYp0XAm3Q2JW0nXEAa7sWUznSsjKfDZSNA9totqRIZSnQ9ZxFCEUcNZXX944nG 137Q== X-Gm-Message-State: ALyK8tLtJSPnq4A2UdLJBZJQ95bebg9WFVJQaOsEPaZaCIAaJrv1L5XCZuUy9sIserfpTqSzDGBsm59Z1++1TQ== X-Received: by 10.37.217.6 with SMTP id q6mr9842252ybg.144.1466459769705; Mon, 20 Jun 2016 14:56:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Mon, 20 Jun 2016 14:55:50 -0700 (PDT) In-Reply-To: <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jun 2016 23:55:50 +0200 Message-ID: To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 20 Jun 2016 21:56:12 -0000 2016-06-20 23:45 GMT+02:00 Roni Even : > Hi, > From RFC3264 section 6.1 > "In the case of RTP, if a particular codec was referenced with a > specific payload type number in the offer, that same payload type > number SHOULD be used for that codec in the answer." Definitely I missed that. However life would be easier with a MUST in there= . --=20 I=C3=B1aki Baz Castillo From nobody Mon Jun 20 18:00: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 CF2D712D875 for ; Mon, 20 Jun 2016 18:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.427 X-Spam-Level: X-Spam-Status: No, score=-8.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 XjpTDlY_GeCR for ; Mon, 20 Jun 2016 18:00:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8715E12D872 for ; Mon, 20 Jun 2016 18:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1466470803; x=1498006803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OR/T5cfR/Yt6b8NkJa3AU7ur7YdY5mhT0xxJTxRxxxo=; b=L06KuQRZOge9C/zYxEV5gCI7byTmBfKj5Twa9+g7OEtfhFY7/zfx2XOP duLTmItEzEn1Rb4yCKFPjssaMzbwckTTs32Lfw+EKPIR5w4LMYBA4XKzp 7p6C+xUKOBQG4WA+PvxPhxq3bzemfqDC3fquMTzfH1JaHwT1NijiJ+mkp w=; X-IronPort-AV: E=Sophos;i="5.26,501,1459839600"; d="scan'208";a="297202868" Received: from ironmsg04-lv.qualcomm.com ([10.47.202.184]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 18:00:02 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8202"; a="28933690" Received: from nalasexr01g.na.qualcomm.com ([10.49.56.53]) by ironmsg04-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jun 2016 18:00:00 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01G.na.qualcomm.com (10.49.56.53) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 20 Jun 2016 18:00:00 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1178.000; Mon, 20 Jun 2016 18:00:00 -0700 From: "Wang, Ye-Kui" To: Stephan Wenger , "Mo Zanaty (mzanaty)" , RFC Errata System , "payload@ietf.org" Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC6184 (4713) Thread-Index: AQHRydtdA9B+T+YPoEK4emcFUxI0xp/xPNYAgACkVQCAATsvkA== Date: Tue, 21 Jun 2016 00:59:59 +0000 Message-ID: References: <20160617105301.2A9CBB80D66@rfc-editor.org> <733BABF8-3DDD-4E2D-B633-829349982036@cisco.com> <3F6D212B-0BED-4410-9A73-EB361FB8B166@stewe.org> In-Reply-To: <3F6D212B-0BED-4410-9A73-EB361FB8B166@stewe.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rjesup@wgate.com" , "tom.kristensen@tandberg.com" , "keith.drage@alcatel-lucent.com" , "even.roni@huawei.com" , "aamelnikov@fastmail.fm" Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4713) 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, 21 Jun 2016 01:00:08 -0000 SSBhZ3JlZSB3aXRoIE1vIGFuZCBTdGVwaGFuLCB0aGUgb3JpZ2luYWwgdGV4dCBpcyBjb3JyZWN0 Lg0KDQpCUiwgWUsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dCBbbWFp bHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlcGhhbiBXZW5nZXINClNl bnQ6IFN1bmRheSwgSnVuZSAxOSwgMjAxNiA0OjEwIFBNDQpUbzogTW8gWmFuYXR5IChtemFuYXR5 KSA8bXphbmF0eUBjaXNjby5jb20+OyBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZz4NCkNjOiB0b20ua3Jpc3RlbnNlbkB0YW5kYmVyZy5jb207IGFhbWVsbmlrb3ZA ZmFzdG1haWwuZm07IHlla3Vpd2FuZ0BodWF3ZWkuY29tOyBrZWl0aC5kcmFnZUBhbGNhdGVsLWx1 Y2VudC5jb207IGF2dEBpZXRmLm9yZzsgZXZlbi5yb25pQGh1YXdlaS5jb207IHJqZXN1cEB3Z2F0 ZS5jb20NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRd IFJGQzYxODQgKDQ3MTMpDQoNCkhpLA0KDQoNCg0KT24gNi8xOS8xNiwgMDY6MjIsICJhdnQgb24g YmVoYWxmIG9mIE1vIFphbmF0eSAobXphbmF0eSkiIDxhdnQtYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2YgbXphbmF0eUBjaXNjby5jb20+IHdyb3RlOg0KDQo+VGhlIG9yaWdpbmFsIHRleHQg aXMgY29ycmVjdDsgMyBieXRlcyBpbiB0aGUgYmluYXJ5IHJlcHJlc2VudGF0aW9uIGJlY29tZSA2 IHRleHQgY2hhcmFjdGVycyBpbiBiYXNlMTYuIFRoZXJlZm9yZSB0aGlzIGVycmF0YSBzaG91bGQg YmUgcmVqZWN0ZWQuDQoNCkkgYWdyZWUuDQoNClN0ZXBoYW4NCg0KPiANCj4NCj5SZWdhcmRzLA0K Pk1vDQo+DQo+T24gSnVuIDE4LCAyMDE2LCBhdCAxMTozMyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0g PHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+IHdyb3RlOg0KPg0KPlRoZSBmb2xsb3dpbmcgZXJy YXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzYxODQsICJSVFAgDQo+UGF5bG9h ZCBGb3JtYXQgZm9yIEguMjY0IFZpZGVvIi4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPllvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0K Pmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTYxODQmZWlk PTQ3MTMNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlR5cGU6 IFRlY2huaWNhbA0KPlJlcG9ydGVkIGJ5OiBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgu bmV0Pg0KPg0KPlNlY3Rpb246IDguMQ0KPg0KPk9yaWdpbmFsIFRleHQNCj4tLS0tLS0tLS0tLS0t DQo+cHJvZmlsZS1sZXZlbC1pZDoNCj4gICAgICAgIEEgYmFzZTE2IFs3XSAoaGV4YWRlY2ltYWwp IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcNCj4gICAgICAgIHRocmVlIGJ5dGVzIGlu IHRoZSBzZXF1ZW5jZSBwYXJhbWV0ZXINCj4NCj5Db3JyZWN0ZWQgVGV4dA0KPi0tLS0tLS0tLS0t LS0tDQo+cHJvZmlsZS1sZXZlbC1pZDoNCj4gICAgICAgIEEgYmFzZTE2IFs3XSAoaGV4YWRlY2lt YWwpIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcNCj4gICAgICAgIHNpeCBieXRlcyBp biB0aGUgc2VxdWVuY2UgcGFyYW1ldGVyDQo+DQo+Tm90ZXMNCj4tLS0tLQ0KPnByb2ZpbGUtbGV2 ZWwtaWQgaXMgY29tcG9zZWQgb2YgdGhyZWUgMi1ieXRlIGxlbmd0aCBmaWVsZHMuDQo+DQo+SW5z dHJ1Y3Rpb25zOg0KPi0tLS0tLS0tLS0tLS0NCj5UaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBv c3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZSANCj51c2UgIlJlcGx5IEFs bCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvciByZWplY3RlZC4g DQo+V2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cp IGNhbiBsb2cgaW4gdG8gDQo+Y2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwg aWYgbmVjZXNzYXJ5Lg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+UkZDNjE4NCAoZHJhZnQtaWV0Zi1hdnQtcnRwLXJmYzM5ODRiaXMtMTIpDQo+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaXRsZSAgICAgICAgICAgICAgIDogUlRQ IFBheWxvYWQgRm9ybWF0IGZvciBILjI2NCBWaWRlbw0KPlB1YmxpY2F0aW9uIERhdGUgICAgOiBN YXkgMjAxMQ0KPkF1dGhvcihzKSAgICAgICAgICAgOiBZLi1LLiBXYW5nLCBSLiBFdmVuLCBULiBL cmlzdGVuc2VuLCBSLiBKZXN1cA0KPkNhdGVnb3J5ICAgICAgICAgICAgOiBQUk9QT1NFRCBTVEFO REFSRA0KPlNvdXJjZSAgICAgICAgICAgICAgOiBBdWRpby9WaWRlbyBUcmFuc3BvcnQNCj5BcmVh ICAgICAgICAgICAgICAgIDogUmVhbC10aW1lIEFwcGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1 cmUNCj5TdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPlZlcmlmeWluZyBQYXJ0eSAgICAgOiBJ RVNHDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRmLm9yZw0K Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UN CmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQN Cg== From nobody Tue Jun 21 00:56:47 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 325B412D83A for ; Tue, 21 Jun 2016 00:56:45 -0700 (PDT) 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 z7QiCgRu4-ne for ; Tue, 21 Jun 2016 00:56:40 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FF112D114 for ; Tue, 21 Jun 2016 00:56:40 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-a7-5768f33611e3 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.BE.18043.633F8675; Tue, 21 Jun 2016 09:56:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.294.0; Tue, 21 Jun 2016 09:56:36 +0200 To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , Roni Even References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> From: Magnus Westerlund Message-ID: <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> Date: Tue, 21 Jun 2016 09:56:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7qK7Z54xwgy9/tCym77OxuHTxLJPF 33ZmB2aPcw3v2T12zrrL7rFkyU+mAOYoLpuU1JzMstQifbsEroy1Sx4wFczlqph/4iNrA+N0 ji5GTg4JAROJvvvPmSBsMYkL99azgdhCAkcYJXqniHUxcgHZyxkl/k55zQqSEBbwlpjRsocd xBYRiJWY8vcdM0TRSiaJ76++sIAkmIEm/Vy4BayITcBC4uaPRrCpvAL2Eu967zN2MXJwsAio ShxvTAMJiwrESDTePswOUSIocXLmE7AxnAKBEk/eXYcaaSExc/55RghbXqJ562xmiEO1JRqa OlgnMArOQtI+C0nLLCQtCxiZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIEhu/BLb+tdjAe fO54iFGAg1GJhzchPSNciDWxrLgy9xCjBAezkgjvjvdAId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYycWdfDFhW9kTX4V7zsWaFHR3ag/76/gtO/F9tf bJzElr4sMistJ3Wj96mt029FXzyxN3OD+VLNgMPKrQ3rpur8d9ugs2eR5gLL+z1MHKn/Gcpj zokvYrNs6lGeevGjsKPuylmTWg/53lxm8DN5lZlZ83yVfqN+qyuxu2Q7Dhuc0t9reXZG3Gwl luKMREMt5qLiRADlhVQ2WwIAAA== Archived-At: Cc: payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 21 Jun 2016 07:56:45 -0000 Den 2016-06-20 kl. 23:55, skrev Iñaki Baz Castillo: > 2016-06-20 23:45 GMT+02:00 Roni Even : >> Hi, >> From RFC3264 section 6.1 >> "In the case of RTP, if a particular codec was referenced with a >> specific payload type number in the offer, that same payload type >> number SHOULD be used for that codec in the answer." > > Definitely I missed that. However life would be easier with a MUST in there. > I don't disagree that it would be easier. However, that is not what RFC3264 says, so the only way of changing RFC3264. Which, is quite some work. So, is the conclusion that this errata also can be rejected? I think so, I also didn't find the text in 6.1, but I have to say that I didn't look widely. With that text, there are no actual error in the text. 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 Tue Jun 21 02:06: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 3C61412D1D3 for ; Tue, 21 Jun 2016 02:06:31 -0700 (PDT) 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 3A9w1zwFcV_u for ; Tue, 21 Jun 2016 02:06:29 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3273A12B00C for ; Tue, 21 Jun 2016 02:06:29 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id q132so13436592lfe.3 for ; Tue, 21 Jun 2016 02:06:29 -0700 (PDT) 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=YZK/I/N7ZfycXxZ1reWYbunawxTwZJ/z73WyWGi22SM=; b=R3AtGly1BSEivDYPROKCQXgXz/ge8jDicPL3bfcudC+FWQonuLAY1bv6yNW6rxNLN/ 1QSFbdtlJvuO7k6df525T9lplTGtF5Bfu7Tg5KlOiBWOhEifT6LvWRJHAEVJzGFq6jyI jx67aloFnV5topOtK6WE1C+zzJ7S9vJy9UXTkUiZ+kteykEE71hoxQQqDdtnYU6I+5B/ HPjrpDplu4JT85E6ldlaGDiay3Ud8XTe0a+0KcTzpLz470sk2Ee6YRK2eHR9BQ2xSYMu ELq7q8NNvFXYSNbmSCB88qzIjBdYC1IuycXNefxudF/p7dYq7q2MlKlsrscGH3dlMtJV yXwA== 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=YZK/I/N7ZfycXxZ1reWYbunawxTwZJ/z73WyWGi22SM=; b=HoQkmGcZ1aw4wXmkaAfilUnfbXaZGFCJP8nZIY/76RiOgs9rKjSlG/Lu4abWRpBPHW XJD6WrzEwBsn2yY8lsxuQe9kcFU7MDKINMeCJrMH13gu/FfqylXtkfBakVg6dXPFuKQY j34vza4HESVgLC6l+M2/QR21H4J2el85OYpd0+pmHJ+fsgb9E9vgQu18KgzLalj7Acbc LKFTYX4ELz6SsMPZt/MlsSmAm8CH6l5xZMmHiYQDIMQgcnKynnX0nc8aFK4d4vrEtQGR 1CSR9IGohWdeJNyU47XEqA8OSox/spkW+zSqOAu/nTlIrjpq20t5I17v8nZ+5Jw4riWO QNkg== X-Gm-Message-State: ALyK8tJLD/wAV9237kl9y8dw/v6RMPWd5h5fKc9MDS1yiIiWUezs7/Y0cEBFFtptJ5qszw== X-Received: by 10.28.154.144 with SMTP id c138mr2119705wme.63.1466499987192; Tue, 21 Jun 2016 02:06:27 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id w81sm1901650wmg.20.2016.06.21.02.06.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Jun 2016 02:06:26 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , =?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> In-Reply-To: <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> Date: Tue, 21 Jun 2016 12:05:02 +0300 Message-ID: <126401d1cb9b$ffdbf670$ff93e350$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxiAO0N9S2DUtvvNCIjuRxsHP+SgKc4fFzAarHRFQBNAtdwAKLQ482AlE0b/ef4WWwcA== Content-Language: he Archived-At: Cc: payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 21 Jun 2016 09:06:31 -0000 Hi, >From section 5.1 of RFC3264 " Different payload type numbers may be needed in each direction because of interoperability concerns with H.323." I assume this is one reason for the SHOULD Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, June 21, 2016 10:57 AM > To: I=C3=B1aki Baz Castillo; Roni Even > Cc: payload@ietf.org > Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 > (4714) >=20 > Den 2016-06-20 kl. 23:55, skrev I=C3=B1aki Baz Castillo: > > 2016-06-20 23:45 GMT+02:00 Roni Even : > >> Hi, > >> From RFC3264 section 6.1 > >> "In the case of RTP, if a particular codec was referenced with a > >> specific payload type number in the offer, that same payload = type > >> number SHOULD be used for that codec in the answer." > > > > Definitely I missed that. However life would be easier with a MUST = in there. > > >=20 > I don't disagree that it would be easier. However, that is not what > RFC3264 says, so the only way of changing RFC3264. Which, is quite = some > work. >=20 > So, is the conclusion that this errata also can be rejected? >=20 > I think so, I also didn't find the text in 6.1, but I have to say that = I didn't look > widely. With that text, there are no actual error in the text. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Tue Jun 21 06:49:11 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 993C112B05A for ; Tue, 21 Jun 2016 06:49:09 -0700 (PDT) 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 KDZ7NN_UIcH9 for ; Tue, 21 Jun 2016 06:49:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FCA127071 for ; Tue, 21 Jun 2016 06:49:07 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-6f-576945d16756 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.72.12926.1D549675; Tue, 21 Jun 2016 15:49:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Tue, 21 Jun 2016 15:48:45 +0200 To: Roni Even , =?UTF-8?Q?'I=c3=b1aki_Baz_Castillo'?= References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> <126401d1cb9b$ffdbf670$ff93e350$@gmail.com> From: Magnus Westerlund Message-ID: <46cc3c6c-d59b-3f1f-4fc0-a740c4b7e45e@ericsson.com> Date: Tue, 21 Jun 2016 15:48:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <126401d1cb9b$ffdbf670$ff93e350$@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM2K7n+4l18xwg5kZFtP32VhcuniWyeJv O7MDs8e5hvfsHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxtl/H9kLupUqHm5YxtLA+F2q i5GDQ0LARKJxVlQXIyeQKSZx4d56ti5GLg4hgSOMEmt3djJBOMsZJR6fe8gEUiUs4C0xo2UP O4gtIhAv8f33BkaIol5miQP7r4AVMQON+rlwC1gRm4CFxM0fjWwgNq+AvcS5OT/YQDazCKhK zJxdCRIWFYiRaLx9mB2iRFDi5MwnLCAlnECtkxbLQUy0kJg5/zwjhC0v0bx1NjOILSSgLdHQ 1ME6gVFwFpLuWUhaZiFpWcDIvIpRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMHQPbvmtuoPx 8hvHQ4wCHIxKPLwK+hnhQqyJZcWVuYcYJTiYlUR4d9lnhgvxpiRWVqUW5ccXleakFh9ilOZg URLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpglIlgWJ7wwTX91B+V1Ir64l9CJis3zZ/T9OIM +5KkinKppH/rRcR3HPnoeMxi2cpqTSlb/wuH4pc0Hg/rNLy18cmJU3P/3AxZorWtbN3PvKm/ b0YpXl54K21KyL2/HuV7qkT3rdlTxufDsldscrK6y5G3/32Eizb6np8b+PqL9Z9Hq84mdCpP CVNiKc5INNRiLipOBAAGujaDWQIAAA== Archived-At: Cc: payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 21 Jun 2016 13:49:09 -0000 Den 2016-06-21 kl. 11:05, skrev Roni Even: > Hi, >>From section 5.1 of RFC3264 > > " Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323." > > I assume this is one reason for the SHOULD Hi, I actually wrote a longer email yesterday that failed to be sent. I think the text written in the RFC is unchanged from RFC 3984 and as it is part of the O/A specification, thus I most likely wrote it. Therefore I would like to provide my view of how it should be interpreted. Yes, I am pretty certain that it is to reference the should you pointed to. But that was not the only reason as you can se below. I do claim that intention was to avoid violating RFC 3264, but provide stricter limitations within the RFC 3264 rules to address the identification issue. As quoted from RFC3264 it says: However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. What I want to stress here is "the answer might", which is equivalent to say. The Answer MAY use different PT numbers. Due to the matching issues with the three different important parameters, it is a benefit to not change the values. Therefore we wanted to strongly recommend the usage of symmetric PT values and echoed the SHOULD. However, SHOULD clearly allows for using different values in the answer, following RFC3264. And to avoid issues I will note this payload format does add a restriction of not re-using the numbers from the offer: To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [8]. An answer MUST NOT contain a payload type number used in the offer unless the configuration is the same as in the offer. So that is the motivation. But my point with the previous email was really to say that I think we can conclude that the Errata can be rejected. Cheers Magnus > > Roni > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Tuesday, June 21, 2016 10:57 AM >> To: Iñaki Baz Castillo; Roni Even >> Cc: payload@ietf.org >> Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 >> (4714) >> >> Den 2016-06-20 kl. 23:55, skrev Iñaki Baz Castillo: >>> 2016-06-20 23:45 GMT+02:00 Roni Even : >>>> Hi, >>>> From RFC3264 section 6.1 >>>> "In the case of RTP, if a particular codec was referenced with a >>>> specific payload type number in the offer, that same payload type >>>> number SHOULD be used for that codec in the answer." >>> >>> Definitely I missed that. However life would be easier with a MUST in there. >>> >> >> I don't disagree that it would be easier. However, that is not what >> RFC3264 says, so the only way of changing RFC3264. Which, is quite some >> work. >> >> So, is the conclusion that this errata also can be rejected? >> >> I think so, I also didn't find the text in 6.1, but I have to say that I didn't look >> widely. With that text, there are no actual error in the text. >> >> 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 Tue Jun 21 06:51:42 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 02A7112D11E for ; Tue, 21 Jun 2016 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 FbrL1PK__N0D for ; Tue, 21 Jun 2016 06:51:38 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B32512D0C4 for ; Tue, 21 Jun 2016 06:51:38 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id i12so13945863ywa.1 for ; Tue, 21 Jun 2016 06:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=152BRU21vyPTbFVmZdTwO05fLVEVZLT9Amgt1RPmSYA=; b=H/+nMc2Bo7iS9TVlImp/j728lbJg0hhLv5CwYluBkooNqShj1XaDEh2+e9OeXiuD85 EIPeir4RSzrnC92BFKIxXPWEUxVhYuA09ot4HKcHz2d4KrUMWPxCZJbVMUffygQuQ7ib o6fX8IjnSmE2HOduQWM1h1NqDVtUObYvz3ygsagGaRhDuSG6OhsZKIvSJ+SyG1uZ+hj5 auPSyKgpIq+nApf4lmUsAjfpglcbH16ywKNHSAaR6jkOP7UrVrh6j7F1C0CLsqZxn754 BHIYexh0Lh/uZo4n5Yoi4VSK45sFbqE9LhJX9NM+nxvcbmBftt8DhvBfFJKDiuyn4A5V od5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=152BRU21vyPTbFVmZdTwO05fLVEVZLT9Amgt1RPmSYA=; b=gG8YxKBzASZslzQLyc9RcpZCMmskcUYHlS4i5viK4hFnQR9XGqUy9aGUxcMZcHBkRD cRU4sEyEVHqY7zdiLF97J8hah9F5BaaUjyooBmQNY8Prr1No5DMGMpNhGJZjaY/MLKQg D0HOqdnsbI1dFEV4U1aztGZislFpNtke5uDZfLZDwX3K8OPPqSY+Mv+9myM6jhtWNooq aAyz8T2r2kgdjcVO+D32dw2eh6+7TFkE9eLclycRUVelrI+ubwf13zNsr4gy4n6fhWL9 up+Wr6yXujDEyjvKh+/fVaPY0TUlem0v5GHe2eanjCvmTdyGnsFPGgpbfpJLe9gE4YOo M0Dw== X-Gm-Message-State: ALyK8tLiVtdtIvvuyizhW8k30Y9NwiP3vuBEAyqJyZzJHVcIVnFcY+Kkx/NF4U1HzVbZaxI9/JpH7zO4+hyjZA== X-Received: by 10.129.78.216 with SMTP id c207mr11368285ywb.235.1466517097505; Tue, 21 Jun 2016 06:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Tue, 21 Jun 2016 06:51:17 -0700 (PDT) In-Reply-To: <46cc3c6c-d59b-3f1f-4fc0-a740c4b7e45e@ericsson.com> References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> <126401d1cb9b$ffdbf670$ff93e350$@gmail.com> <46cc3c6c-d59b-3f1f-4fc0-a740c4b7e45e@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Jun 2016 15:51:17 +0200 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 21 Jun 2016 13:51:40 -0000 2016-06-21 15:48 GMT+02:00 Magnus Westerlund : > Due to the matching issues with the three different important parameters,= it > is a benefit to not change the values. Therefore we wanted to strongly > recommend the usage of symmetric PT values and echoed the SHOULD. However= , > SHOULD clearly allows for using different values in the answer, following > RFC3264. And to avoid issues I will note this payload format does add a > restriction of not re-using the numbers from the offer: > > To simplify the handling and matching of these configurations, the > same RTP payload type number used in the offer SHOULD also be used > in the answer, as specified in [8]. An answer MUST NOT contain a > payload type number used in the offer unless the configuration is > the same as in the offer. > > > So that is the motivation. > > But my point with the previous email was really to say that I think we ca= n > conclude that the Errata can be rejected. > > Cheers Thanks a lot, Magnus. Very valuable rationale. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 21 11:32:51 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 25B7612DC58 for ; Tue, 21 Jun 2016 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 xUi3S1POsu4W for ; Tue, 21 Jun 2016 11:32:36 -0700 (PDT) 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 BA12612DBCD for ; Tue, 21 Jun 2016 11:31:14 -0700 (PDT) Received: from [10.0.1.4] (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 u5LIV6BR085938 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 13:31:06 -0500 (CDT) (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.4] From: "Ben Campbell" To: "Magnus Westerlund" Date: Tue, 21 Jun 2016 13:31:05 -0500 Message-ID: In-Reply-To: <46cc3c6c-d59b-3f1f-4fc0-a740c4b7e45e@ericsson.com> References: <20160617111801.D0598B80D8D@rfc-editor.org> <8b886c32-e4d0-c940-c3df-6578d276fd58@ericsson.com> <122d01d1cb3d$0e8b9f90$2ba2deb0$@gmail.com> <310664ca-01a5-4a04-386f-f6196d32fa51@ericsson.com> <126401d1cb9b$ffdbf670$ff93e350$@gmail.com> <46cc3c6c-d59b-3f1f-4fc0-a740c4b7e45e@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: =?utf-8?q?I=C3=B1aki?= Baz Castillo , payload@ietf.org Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714) 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, 21 Jun 2016 18:32:39 -0000 I rejected the errata report. Thanks! Ben. On 21 Jun 2016, at 8:48, Magnus Westerlund wrote: > Den 2016-06-21 kl. 11:05, skrev Roni Even: >> Hi, >>> From section 5.1 of RFC3264 >> >> " Different payload type numbers may be needed in each direction >> because of interoperability concerns with H.323." >> >> I assume this is one reason for the SHOULD > > Hi, > > I actually wrote a longer email yesterday that failed to be sent. > > I think the text written in the RFC is unchanged from RFC 3984 and as > it is part of the O/A specification, thus I most likely wrote it. > Therefore I would like to provide my view of how it should be > interpreted. > > Yes, I am pretty certain that it is to reference the should you > pointed to. But that was not the only reason as you can se below. I do > claim that intention was to avoid violating RFC 3264, but provide > stricter limitations within the RFC 3264 rules to address the > identification issue. > > As quoted from RFC3264 it says: > > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > What I want to stress here is "the answer might", which is equivalent > to say. The Answer MAY use different PT numbers. > > Due to the matching issues with the three different important > parameters, it is a benefit to not change the values. Therefore we > wanted to strongly recommend the usage of symmetric PT values and > echoed the SHOULD. However, SHOULD clearly allows for using different > values in the answer, following RFC3264. And to avoid issues I will > note this payload format does add a restriction of not re-using the > numbers from the offer: > > To simplify the handling and matching of these configurations, > the > same RTP payload type number used in the offer SHOULD also be > used > in the answer, as specified in [8]. An answer MUST NOT contain > a > payload type number used in the offer unless the configuration > is > the same as in the offer. > > > So that is the motivation. > > But my point with the previous email was really to say that I think we > can conclude that the Errata can be rejected. > > Cheers > > Magnus > > > > >> >> Roni >> >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Tuesday, June 21, 2016 10:57 AM >>> To: Iñaki Baz Castillo; Roni Even >>> Cc: payload@ietf.org >>> Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 >>> (4714) >>> >>> Den 2016-06-20 kl. 23:55, skrev Iñaki Baz Castillo: >>>> 2016-06-20 23:45 GMT+02:00 Roni Even : >>>>> Hi, >>>>> From RFC3264 section 6.1 >>>>> "In the case of RTP, if a particular codec was referenced with a >>>>> specific payload type number in the offer, that same payload >>>>> type >>>>> number SHOULD be used for that codec in the answer." >>>> >>>> Definitely I missed that. However life would be easier with a MUST >>>> in there. >>>> >>> >>> I don't disagree that it would be easier. However, that is not what >>> RFC3264 says, so the only way of changing RFC3264. Which, is quite >>> some >>> work. >>> >>> So, is the conclusion that this errata also can be rejected? >>> >>> I think so, I also didn't find the text in 6.1, but I have to say >>> that I didn't look >>> widely. With that text, there are no actual error in the text. >>> >>> 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 > ---------------------------------------------------------------------- > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jun 22 02:41:42 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 1F7FF12B01E for ; Wed, 22 Jun 2016 02:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8mpNIRNMpZb for ; Wed, 22 Jun 2016 02:41:38 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61477127058 for ; Wed, 22 Jun 2016 02:41:38 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id r2so13897304oih.2 for ; Wed, 22 Jun 2016 02:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x3a6HK1svgGXYtoZF5nxeMQsz5xXc8PMEQ1WWfA8FYo=; b=Z/qg1bGqnq7LTRbp/zGs9Z3bdmbyTkslzrcAK6qjuKSk1x52KpFIXKGavKKB5XJbwF t+rK43r7bqHcSd7rmk7IpJiOfr2GEZN0QmhYWCDKSKHTRDZuf/8C+dIgfCBFG5E8hQe6 qSfochD0Lg86p4wNmQAxTcrthO1FNyN9elT2aXaU6g3FEkc2FVJQ6LO6CAvGvO/7bmDb Dzq2F3nlSeCc97ZiWio4LWGOyE1TV+4e7VmyI+BbxCmG5v0ojeaEYZ4jmL1NqB3qWCLu LI4JQwlQhLNIQQdetluKFmWD3v77wErV7aSB1bPJ3GIu+4dD15BgYCTT60J1W3jymp4x Ax+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x3a6HK1svgGXYtoZF5nxeMQsz5xXc8PMEQ1WWfA8FYo=; b=aAA6AggYah46TBKR+jVhY8H00W3gerGQ519adDTrZeDG/EDAnOwaJwuW5eHhqcLhGc bQGu8qBAU+oXupN4gF28uvhkH7YAl5QgzDAlinfTrnR08DmwWSQWV9ii+HdzCHKJDdqR IUVi0NGcw8qMgs4RRDbtP4Z5MWfU8m9BUCfp6pS1u/S3ufdhSTkBtQaJDoVbj6YIUKZW uP/hiq2E3IUlyXiOLZJIm21p0CtSDYWR7ytMZThICW47jN7Tn+ZpoJX3939vFqVW78uo l8ghyJdFja0QS0DoTclMeerbuDSrXn4173cd6ZLZGqNoqBg/dhruNWxk515xm6+rsqP5 tIUA== X-Gm-Message-State: ALyK8tIqFKPvqQt87SbkkBKo/w9EeNHrKxMYWolxn9X92/gPnZ79KdAMi7VGPpzDXv69BbLMvsKYJ+orV/7scw== X-Received: by 10.202.193.2 with SMTP id r2mr974338oif.32.1466588497517; Wed, 22 Jun 2016 02:41:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.180.2 with HTTP; Wed, 22 Jun 2016 02:41:37 -0700 (PDT) In-Reply-To: References: From: "Ali C. Begen" Date: Wed, 22 Jun 2016 12:41:37 +0300 Message-ID: To: Thomas Edwards Content-Type: multipart/alternative; boundary=001a113d6c5e6d20f70535dabefe Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03 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, 22 Jun 2016 09:41:41 -0000 --001a113d6c5e6d20f70535dabefe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thomas Here are my comments. First, please take of the nits for your draft as listed here: https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-payload-rtp-ancillary-03.txt Second, please wait for a response from Jonathan, James and Dan before moving on. Further comments inline. On Thu, Jun 16, 2016 at 6:34 AM, Thomas Edwards wrote: > Dear Payload WG, > > I have looked at the WGLC comments on draft-ietf-payload-rtp-ancillary-03= . > I believe that I have responses to these comments (although I am still > working on some offer/answer issues based on SDP Directorate comments). > If the group is OK with these, I can edit the I-D and issue a new version= . > > > > Commenter: Jonathan Lennox Mon, 18 April 2016 15:59 > UTC > > > Comment: "No mechanism is given to associate the video/smpte291 streams > with their associated video/raw or video/jpeg2000 streams. In complicate= d > scenarios (multiple video streams, e.g.) some SDP grouping might be > necessary to provide this association." > Response: How about if the I-D is amended with an example SDP file with > "a=3Dgroup:LS" to show lip sync grouping as per RFC 5888 between say RFC > 4175 video and ANC? > I am ok with this approach. LS grouping is generic enough to sync any two streams. > > Comment: "The RTP clock rate isn=C2=B9t specified. Presumably it should = be the > same as the associated video streams; i.e., normally 90000, but variable > for JPEG2000." > Response: In the description of the timestamp, the I-D states "A 90-kHz > timestamp SHOULD be used". Based on industry input, I believe this is th= e > proper level of specificity. > I think Jonathan wants to see this mentioned in Section 3.1 under Required parameters. > > Commenter: James P. Weaver Tue, 19 April 2016 > 13:11 UTC > > Comment: "I think that the mime-type should probably not be > video/smpte291, but rather application/smpte291. The data carried here > isn=C2=B9t video data, so it seems incorrect to use video as the type." > Response: We did discus this at the WG F2F in Dallas, and my impression i= s > that the group was OK with video/smpte291 although there were some > dissenters. My argument is that SMPTE ST 291 Ancillary Data format only > makes sense within a video environment, and frankly it is probably not th= e > optimal way to carry some of this metadata in a more generic case. The > broadcast industry appears OK with a video type as far as I have seen > through the Video Services Forum Technical Recommendation TR-03 and the > SMPTE ST 2110 processes which reference the I-D. Harald Alvestrand > Thu, 12 May 2016 07:42 UTC pointed out "If one > wishes to multiplex the video and these packets on the same SDP-negotiate= d > RTP session without using BUNDLE, the top level mime-type has to be > "video"." So I'd prefer to keep it video/smpte291 unless there is a > strong consensus in the group against that. > OK. > > >From the SDP Directorate: > > Commenter: Dan Wing Thu, 21 Apr 2016 14:42:10 -0700 > > Comment: "I see the text in 3.1 partially defines the SDP syntax, but is > in a section titled "Media Type Definition". Much of that is very > specific to SDP (especially the text describing location of comma, use of > "{}", suchlike), and should be in section 3.2, "Mapping to SDP"." > Response: I can move the SDP-specific info in section 3.1 into section 3.= 2 > Please do so. > > Comment: "The text needs to if both DID and SDID are required, because I > notice at http://www.smpte-ra.org/smpte-ancillary-data-smpte-st-291, some > DIDs SDIDs, such as 0xa0 ("Audio data in HANC space"). Are such DIDs > without SDIDs illegal to use with SDP, illegal to use with this RTP > Ancillary payload, or anything like that? The I-D should say something > about DIDs that don't have SDIDs, and how they are expressed in the SDP. > For example is it possible for SMPTE to register a new DID next year whic= h > have no SDID, and how do we want that signaled in SDP? This may be solve= d > with a simple, "All DIDs using this RTP Ancillary Payload format will > always have SDIDs registered with them by SMPTE.", which may well exist > somewhere in the document already and I missed it." > Response: It is true that DID 0x80 (deletion) has no required SDID. Some > of the audio ANC packets are "Type 1" ANC packets that have Data Block > Numbers (DBN) in place of where "Type 2" ANC packets have SDIDs. In > either case, one would want to filter based on just the DID. I can make > this clear is section 3.2. > Good idea. > > Comment: "I'd like to see an ABNF syntax of the fmtp parameters, includin= g > things like how long the hex values can be, and whether they can have bot= h > lower and upper case." > Response: I can add the ABNF. > Thanks. > > -Thomas > > > -- > Thomas Edwards > VP Engineering & Development > FOX Networks Engineering and Operations > thomas.edwards@fox.com > Phone: +1.310.369.6696 > 10201 West Pico Blvd. > Los Angeles, CA 90035 > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --001a113d6c5e6d20f70535dabefe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Thomas

Here are my comments. First, = please take of the nits for your draft as listed here:

Second, please wait for a response from J= onathan, James and Dan before moving on.=C2=A0

Fur= ther comments inline.

On Thu, Jun 16, 2016 at 6:34 AM, Thomas Edwards <Thomas.Edw= ards@fox.com> wrote:
Dear P= ayload WG,

I have looked at the WGLC comments on draft-ietf-payload-rtp-ancillary-03.<= br> =C2=A0I believe that I have responses to these comments (although I am stil= l
working on some offer/answer issues based on SDP Directorate comments).
If the group is OK with these, I can edit the I-D and issue a new version.<= br>


Commenter: Jonathan Lennox <jonath= an@vidyo.com> Mon, 18 April 2016 15:59
UTC


Comment:=C2=A0 "No mechanism is given to associate the video/smpte291 = streams
with their associated video/raw or video/jpeg2000 streams.=C2=A0 In complic= ated
scenarios (multiple video streams, e.g.) some SDP grouping might be
necessary to provide this association."
Response: How about if the I-D is amended with an example SDP file with
"a=3Dgroup:LS" to show lip sync grouping as per RFC 5888 between = say RFC
4175 video and ANC?

I am ok with this a= pproach. LS grouping is generic enough to sync any two streams.
= =C2=A0

Comment: "The RTP clock rate isn=C2=B9t specified.=C2=A0 Presumably it= should be the
same as the associated video streams; i.e., normally 90000, but variable for JPEG2000."
Response: In the description of the timestamp, the I-D states "A 90-kH= z
timestamp SHOULD be used".=C2=A0 Based on industry input, I believe th= is is the
proper level of specificity.

I think Jo= nathan wants to see this mentioned in Section 3.1 under Required parameters= .
=C2=A0

Commenter: James P. Weaver <J= ames.Barrett@bbc.co.uk> Tue, 19 April 2016
13:11 UTC

Comment: "I think that the mime-type should probably not be
video/smpte291, but rather application/smpte291. The data carried here
isn=C2=B9t video data, so it seems incorrect to use video as the type."= ;
Response: We did discus this at the WG F2F in Dallas, and my impression is<= br> that the group was OK with video/smpte291 although there were some
dissenters.=C2=A0 My argument is that SMPTE ST 291 Ancillary Data format on= ly
makes sense within a video environment, and frankly it is probably not the<= br> optimal way to carry some of this metadata in a more generic case.=C2=A0 Th= e
broadcast industry appears OK with a video type as far as I have seen
through the Video Services Forum Technical Recommendation TR-03 and the
SMPTE ST 2110 processes which reference the I-D.=C2=A0 Harald Alvestrand <harald@alvestrand.no> Th= u, 12 May 2016 07:42 UTC pointed out "If one
wishes to multiplex the video and these packets on the same SDP-negotiated<= br> RTP session without using BUNDLE, the top level mime-type has to be
"video"."=C2=A0 So I'd prefer to keep it video/smpte291 = unless there is a
strong consensus in the group against that.

=
OK.=C2=A0

>From the SDP Directorate:

Commenter: Dan Wing <dwing@cisco.com<= /a>> Thu, 21 Apr 2016 14:42:10 -0700

Comment: "I see the text in 3.1 partially defines the SDP syntax, but = is
in a section titled "Media Type Definition".=C2=A0 Much of that i= s very
specific to SDP (especially the text describing location of comma, use of "{}", suchlike), and should be in section 3.2, "Mapping to S= DP"."
Response: I can move the SDP-specific info in section 3.1 into section 3.2<= br>


Comment: "The text needs to if both DID and SDID are required, because= I
notice at http://www.smpte-ra.org/smpte-anc= illary-data-smpte-st-291, some
DIDs SDIDs, such as 0xa0 ("Audio data in HANC space").=C2=A0 Are = such DIDs
without SDIDs illegal to use with SDP, illegal to use with this RTP
Ancillary payload, or anything like that?=C2=A0 The I-D should say somethin= g
about DIDs that don't have SDIDs, and how they are expressed in the SDP= .
For example is it possible for SMPTE to register a new DID next year which<= br> have no SDID, and how do we want that signaled in SDP?=C2=A0 This may be so= lved
with a simple, "All DIDs using this RTP Ancillary Payload format will<= br> always have SDIDs registered with them by SMPTE.", which may well exis= t
somewhere in the document already and I missed it."
Response: It is true that DID 0x80 (deletion) has no required SDID.=C2=A0 S= ome
of the audio ANC packets are "Type 1" ANC packets that have Data = Block
Numbers (DBN) in place of where "Type 2" ANC packets have SDIDs.= =C2=A0 In
either case, one would want to filter based on just the DID.=C2=A0 I can ma= ke
this clear is section 3.2.

Good idea.= =C2=A0

Comment: "I'd like to see an ABNF syntax of the fmtp parameters, i= ncluding
things like how long the hex values can be, and whether they can have both<= br> lower and upper case."
Response: I can add the ABNF.

Thanks.= =C2=A0

-Thomas


--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.= 6696
10201 West Pico Blvd.
Los Angeles, CA 90035

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

--001a113d6c5e6d20f70535dabefe-- From nobody Wed Jun 22 08:19:43 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 5B0D412D9D5; Wed, 22 Jun 2016 08:19:42 -0700 (PDT) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622151942.11039.41600.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 08:19:42 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-02.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: Wed, 22 Jun 2016 15:19:42 -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-02.txt Pages : 26 Date : 2016-06-22 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. Also, within the document there are included necessary details for the use of MELP with SDP. 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 23 06:56:42 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 6C7FA12DDFD for ; Thu, 23 Jun 2016 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9RfDCY9S-Hal for ; Thu, 23 Jun 2016 06:56:27 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E640612DDD1 for ; Thu, 23 Jun 2016 06:56:26 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u5NDsvKT011830; Thu, 23 Jun 2016 09:56:24 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 232hrgnfeb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Jun 2016 09:56:24 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 23 Jun 2016 08:56:23 -0500 From: Jonathan Lennox To: "Ali C. Begen" Thread-Topic: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03 Thread-Index: AQHRzVYlfseCks1uFEWoKt2o3ncZQp/3ZzYA Date: Thu, 23 Jun 2016 13:56:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.35.230.88] Content-Type: multipart/alternative; boundary="_000_DAEAE3220F404ED6B5607AE9D8091F74vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-06-23_07:2016-06-23,2016-06-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1606230147 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03 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, 23 Jun 2016 13:56:32 -0000 --_000_DAEAE3220F404ED6B5607AE9D8091F74vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdW4gMjIsIDIwMTYsIGF0IDU6NDEgQU0sIEFsaSBDLiBCZWdlbiA8YWNiZWdlbkBnbWFp bC5jb208bWFpbHRvOmFjYmVnZW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkNvbW1lbnRlcjogSm9u YXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNv bT4+IE1vbiwgMTggQXByaWwgMjAxNiAxNTo1OQ0KVVRDDQoNCg0KQ29tbWVudDogICJObyBtZWNo YW5pc20gaXMgZ2l2ZW4gdG8gYXNzb2NpYXRlIHRoZSB2aWRlby9zbXB0ZTI5MSBzdHJlYW1zDQp3 aXRoIHRoZWlyIGFzc29jaWF0ZWQgdmlkZW8vcmF3IG9yIHZpZGVvL2pwZWcyMDAwIHN0cmVhbXMu ICBJbiBjb21wbGljYXRlZA0Kc2NlbmFyaW9zIChtdWx0aXBsZSB2aWRlbyBzdHJlYW1zLCBlLmcu KSBzb21lIFNEUCBncm91cGluZyBtaWdodCBiZQ0KbmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhpcyBh c3NvY2lhdGlvbi4iDQpSZXNwb25zZTogSG93IGFib3V0IGlmIHRoZSBJLUQgaXMgYW1lbmRlZCB3 aXRoIGFuIGV4YW1wbGUgU0RQIGZpbGUgd2l0aA0KImE9Z3JvdXA6TFMiIHRvIHNob3cgbGlwIHN5 bmMgZ3JvdXBpbmcgYXMgcGVyIFJGQyA1ODg4IGJldHdlZW4gc2F5IFJGQw0KNDE3NSB2aWRlbyBh bmQgQU5DPw0KDQpJIGFtIG9rIHdpdGggdGhpcyBhcHByb2FjaC4gTFMgZ3JvdXBpbmcgaXMgZ2Vu ZXJpYyBlbm91Z2ggdG8gc3luYyBhbnkgdHdvIHN0cmVhbXMuDQoNClRoaXMgc2VlbXMgZ29vZCB0 byBtZS4NCg0KDQpDb21tZW50OiAiVGhlIFJUUCBjbG9jayByYXRlIGlzbsK5dCBzcGVjaWZpZWQu ICBQcmVzdW1hYmx5IGl0IHNob3VsZCBiZSB0aGUNCnNhbWUgYXMgdGhlIGFzc29jaWF0ZWQgdmlk ZW8gc3RyZWFtczsgaS5lLiwgbm9ybWFsbHkgOTAwMDAsIGJ1dCB2YXJpYWJsZQ0KZm9yIEpQRUcy MDAwLiINClJlc3BvbnNlOiBJbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHRpbWVzdGFtcCwgdGhl IEktRCBzdGF0ZXMgIkEgOTAta0h6DQp0aW1lc3RhbXAgU0hPVUxEIGJlIHVzZWQiLiAgQmFzZWQg b24gaW5kdXN0cnkgaW5wdXQsIEkgYmVsaWV2ZSB0aGlzIGlzIHRoZQ0KcHJvcGVyIGxldmVsIG9m IHNwZWNpZmljaXR5Lg0KDQpJIHRoaW5rIEpvbmF0aGFuIHdhbnRzIHRvIHNlZSB0aGlzIG1lbnRp b25lZCBpbiBTZWN0aW9uIDMuMSB1bmRlciBSZXF1aXJlZCBwYXJhbWV0ZXJzLg0KDQpZZXMuDQoN CkFkZGl0aW9uYWxseSwgc2luY2UgSlBFRzIwMDAgY2FuIG9wdGlvbmFsbHkgaGF2ZSBjbG9jayBy YXRlcyBvdGhlciB0aGFuIDkwIGtIeiwgSSB3b3VsZCBwcmVzdW1lIHRoYXQgaWYgdGhhdOKAmXMg dXNlZCwgdGhlIGFuY2lsbGFyeSBkYXRhIHNob3VsZCBoYXZlIGEgbWF0Y2hpbmcgY2xvY2sgcmF0 ZS4NCg0KKFVubGVzcyBubyBvbmUgdXNlcyBKUEVHMjAwMCBhdCBhIGNsb2NrIHJhdGUgb3RoZXIg dGhhbiA5MCBrSHosIGFuZCB0aGF0IHVzYWdlIGNhbiBiZSBjb25zaWRlcmVkIGRlcHJlY2F0ZWQu KQ0KDQo= --_000_DAEAE3220F404ED6B5607AE9D8091F74vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdW4g MjIsIDIwMTYsIGF0IDU6NDEgQU0sIEFsaSBDLiBCZWdlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFj YmVnZW5AZ21haWwuY29tIiBjbGFzcz0iIj5hY2JlZ2VuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnIgY2xhc3M9IiI+DQpDb21t ZW50ZXI6IEpvbmF0aGFuIExlbm5veCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlv LmNvbSIgY2xhc3M9IiI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgTW9uLCAxOCBBcHJpbCAy MDE2IDE1OjU5PGJyIGNsYXNzPSIiPg0KVVRDPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQ29tbWVudDombmJzcDsgJnF1b3Q7Tm8gbWVjaGFuaXNtIGlzIGdpdmVu IHRvIGFzc29jaWF0ZSB0aGUgdmlkZW8vc21wdGUyOTEgc3RyZWFtczxiciBjbGFzcz0iIj4NCndp dGggdGhlaXIgYXNzb2NpYXRlZCB2aWRlby9yYXcgb3IgdmlkZW8vanBlZzIwMDAgc3RyZWFtcy4m bmJzcDsgSW4gY29tcGxpY2F0ZWQ8YnIgY2xhc3M9IiI+DQpzY2VuYXJpb3MgKG11bHRpcGxlIHZp ZGVvIHN0cmVhbXMsIGUuZy4pIHNvbWUgU0RQIGdyb3VwaW5nIG1pZ2h0IGJlPGJyIGNsYXNzPSIi Pg0KbmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhpcyBhc3NvY2lhdGlvbi4mcXVvdDs8YnIgY2xhc3M9 IiI+DQpSZXNwb25zZTogSG93IGFib3V0IGlmIHRoZSBJLUQgaXMgYW1lbmRlZCB3aXRoIGFuIGV4 YW1wbGUgU0RQIGZpbGUgd2l0aDxiciBjbGFzcz0iIj4NCiZxdW90O2E9Z3JvdXA6TFMmcXVvdDsg dG8gc2hvdyBsaXAgc3luYyBncm91cGluZyBhcyBwZXIgUkZDIDU4ODggYmV0d2VlbiBzYXkgUkZD PGJyIGNsYXNzPSIiPg0KNDE3NSB2aWRlbyBhbmQgQU5DPzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkkgYW0gb2sgd2l0aCB0aGlzIGFwcHJvYWNoLiBMUyBncm91cGluZyBpcyBnZW5lcmljIGVub3Vn aCB0byBzeW5jIGFueSB0d28gc3RyZWFtcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ VGhpcyBzZWVtcyBnb29kIHRvIG1lLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxiciBj bGFzcz0iIj4NCkNvbW1lbnQ6ICZxdW90O1RoZSBSVFAgY2xvY2sgcmF0ZSBpc27CuXQgc3BlY2lm aWVkLiZuYnNwOyBQcmVzdW1hYmx5IGl0IHNob3VsZCBiZSB0aGU8YnIgY2xhc3M9IiI+DQpzYW1l IGFzIHRoZSBhc3NvY2lhdGVkIHZpZGVvIHN0cmVhbXM7IGkuZS4sIG5vcm1hbGx5IDkwMDAwLCBi dXQgdmFyaWFibGU8YnIgY2xhc3M9IiI+DQpmb3IgSlBFRzIwMDAuJnF1b3Q7PGJyIGNsYXNzPSIi Pg0KUmVzcG9uc2U6IEluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgdGltZXN0YW1wLCB0aGUgSS1E IHN0YXRlcyAmcXVvdDtBIDkwLWtIejxiciBjbGFzcz0iIj4NCnRpbWVzdGFtcCBTSE9VTEQgYmUg dXNlZCZxdW90Oy4mbmJzcDsgQmFzZWQgb24gaW5kdXN0cnkgaW5wdXQsIEkgYmVsaWV2ZSB0aGlz IGlzIHRoZTxiciBjbGFzcz0iIj4NCnByb3BlciBsZXZlbCBvZiBzcGVjaWZpY2l0eS48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIEpvbmF0aGFuIHdhbnRzIHRvIHNlZSB0aGlzIG1lbnRp b25lZCBpbiBTZWN0aW9uIDMuMSB1bmRlciBSZXF1aXJlZCBwYXJhbWV0ZXJzLjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5BZGRpdGlvbmFsbHksIHNpbmNlIEpQRUcyMDAwIGNhbiBvcHRpb25hbGx5IGhhdmUg Y2xvY2sgcmF0ZXMgb3RoZXIgdGhhbiA5MCBrSHosIEkgd291bGQgcHJlc3VtZSB0aGF0IGlmIHRo YXTigJlzIHVzZWQsIHRoZSBhbmNpbGxhcnkgZGF0YSBzaG91bGQgaGF2ZSBhIG1hdGNoaW5nIGNs b2NrIHJhdGUuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4oVW5sZXNz IG5vIG9uZSB1c2VzIEpQRUcyMDAwIGF0IGEgY2xvY2sgcmF0ZSBvdGhlciB0aGFuIDkwIGtIeiwg YW5kIHRoYXQgdXNhZ2UgY2FuIGJlIGNvbnNpZGVyZWQgZGVwcmVjYXRlZC4pPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DAEAE3220F404ED6B5607AE9D8091F74vidyocom_-- From oftedal@gmail.com Sun Jun 26 06:24: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 D6BA212B055 for ; Sun, 26 Jun 2016 06:24:59 -0700 (PDT) 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 2RogfUMfH1C4 for ; Sun, 26 Jun 2016 06:24:58 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B1E12B050 for ; Sun, 26 Jun 2016 06:24:58 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l125so134874525ywb.2 for ; Sun, 26 Jun 2016 06:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XBKwDIqjULRLcvlZoQaTiHXherQrAqYarWheJM7hOZ0=; b=C1pDLxt7GQg8LrM6BakHYlt6Key9adMXx7BWuDZd9gu6C3Rcb5nH8DgY5l3FrAMuA+ 34Qz94dKZnqmh6WBwdUmTAagsmO7LySM96tTRvEgr606OGqL1uR9mw8uBuwP2mPrLsf9 WzjlLn9/YD1PiULe4wiXP8aEkvkQiDTyXVviDfN/k0V8nZg7+C1Hgg54bzi2pNfSqUwV ivIu5QQf1Bli5brUi5HdMxvHU8zkvlV+6enVkq13/0/TxEAHLZ4UTJTQJiUecrNVtIyU sXMGNK+YqxnCOTS0sYOS6A0DQisQ8ZpHSQ+Y4ZWwLq5inMUfd5olwuYIUMdjpKP4wa5M BQug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XBKwDIqjULRLcvlZoQaTiHXherQrAqYarWheJM7hOZ0=; b=GUjpWBmxq1dLm/60J7sPpPaQxxrQj6CbHP01puW5+/MdN+QSINrkYc0i8kVYn7Jln9 vgOCJGxBeRr8dsnTDVQ4vGuUdLF6aaHLKR6h6tEEP7032iUJlTQ/FIwVH3nLxxegEijI KC2i6KjBesoqx8hKkISv7IuiLu1DfRPQQHhYhpKp75lCj5P/vBcXWlMagYeSUL7rcigq g1lC3ytGOYgUQw73ZSVqQSkSSn2/mvGAbmj5GjjIcpf/JzIoaDtsSDZhYMSMoug0m241 t+eszRV3hZdaUeNGDm3AE7i7GnUIZfLsdwLF7hWPdqEvV865uwNwlaK3IJSq06ZmMNtV 2ttw== X-Gm-Message-State: ALyK8tJPIn+hoW3meHoTCeTNysRXBqDCcdTELOTd52JewdRIm3ZlSCYyw5Npn/G9inCTF1W8oWEz6F+x1Vrlaw== X-Received: by 10.129.159.2 with SMTP id w2mr8650836ywg.112.1466947497317; Sun, 26 Jun 2016 06:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.19.133 with HTTP; Sun, 26 Jun 2016 06:24:56 -0700 (PDT) From: Kjetil Oftedal Date: Sun, 26 Jun 2016 15:24:56 +0200 Message-ID: To: payload@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [payload] Comments on draft-ietf-payload-rtp-ancillary-03 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: Sun, 26 Jun 2016 14:49:55 -0000 Hi everyone I have some comments on the draft for RTP payload for ancillary data: The introduction to this standard refers to RFC4175 as one of the standards it should be interoperable with. However, RFC4175 has a 15-bit line number field allowing support for video rasters with 32K lines. This new draft only has 11-bit line numbers with the effect of limiting the supported video rasters to 2047 lines. The emerging 4K/UHD standards on the other hand has around 2160 active lines, thus not fully supported. There is a similar issue with the Horizontal_Offset field. This field is limited to 4096 (12-bits). Ancillary data can be carried in the horizontal blanking/HANC of a SDI-signal, which starts after the active video section, thus it is barley reachable in 3840/UHD formats. And since audio is placed before ancillary data in the horizontal blanking the horizontal offset for any ancillary packet might exceed the supported values for this field. To resolve both these issues I would suggest that the Horizontal_Offset field is replaced with a single bit, indicating that the ancillary packet should be embedded in HANC space, and requiring that the ancillary packets should be packetized in a the same order as the original video signal. As it is required per ST291 that multiple ancillary packets on the same line shall be embedded back-to-back reducing this field to a single bit should not cause any real world issues. (The implementer of the Ancillary embedder must make sure that the Ancillary packets are embedded correctly. Audio is also carried with ancillary packets in SDI but likely with another RTP-standard over the network (AES67?). Thus when multiplexing the multiple streams network streams back into a SDI-video signal no gaps must occur in the Audio/Ancillary packet stream per line even if the audio layout changes, and the Horizontal_Offset field can not be blindly trusted anyway) With the reduction of the Horizontal_Offset field to a single bit, the Line_Number field can easily be extended to support the same vertical resolution as RFC4175, without any additional overhead compared to the current packet format. It is worth nothing that this suggestion will not work for SD Ancillary EDH-packets which should not be carried using this standard, as the checksums contained within this packet are likely to be wrong when the signal is reconstructed. Best regards, Kjetil Oftedal