From internet-drafts@ietf.org Tue Jul 2 11:01:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2689B21F8CB4; Tue, 2 Jul 2013 11:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rBp6MwiEzZH; Tue, 2 Jul 2013 11:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDB421F844E; Tue, 2 Jul 2013 11:01:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702180128.29473.20279.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 11:01:28 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:01:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Update to Remove DVI4 from the Recommended Codecs for th= e RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) Author(s) : Timothy B. Terriberry Filename : draft-ietf-avtcore-avp-codecs-03.txt Pages : 4 Date : 2013-07-02 Abstract: The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-avp-codecs-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-avp-codecs-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jul 3 06:30:07 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF711E81A0; Wed, 3 Jul 2013 06:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqQ43O5wegna; Wed, 3 Jul 2013 06:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7985311E8145; Wed, 3 Jul 2013 06:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703133006.5832.28535.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 06:30:06 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:30:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure R= TP (SRTP) Author(s) : David A. McGrew Kevin M. Igoe Filename : draft-ietf-avtcore-srtp-aes-gcm-07.txt Pages : 33 Date : 2013-07-03 Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jul 8 13:27:31 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5921321F9CF1; Mon, 8 Jul 2013 13:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wocmcqF1tFdw; Mon, 8 Jul 2013 13:27:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BD521F9D5D; Mon, 8 Jul 2013 13:27:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708202726.32720.60771.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 13:27:26 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)' to Proposed Standard (draft-ietf-avtcore-avp-codecs-03.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:27:31 -0000 The IESG has approved the following document: - 'Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)' (draft-ietf-avtcore-avp-codecs-03.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs/ Technical Summary: The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. Working Group Summary: There has been strong support for doing this update with a number of individuals being active. There was some discussion if also PCMA should be included, but there was no consensus on that, and the WG has chosen to progress without any additions to the list. Document Quality: The recommnedation in this document matches actual deployment better than the original recommendations in what codecs was recommended to implement. With the approval of this specification many more implementations will fulfill the recommendations in this document than previous. The document has gotten pretty good review during its development and in WG last call. Personnel: Magnus Westerlund is Document Shepherd. Richard Barnes is responsible AD. From internet-drafts@ietf.org Mon Jul 8 14:29:18 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535C521F9E34; Mon, 8 Jul 2013 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuW3ae5VZG60; Mon, 8 Jul 2013 14:29:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C694721F9D71; Mon, 8 Jul 2013 14:29:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 14:29:17 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:29:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-05.txt Pages : 10 Date : 2013-07-08 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Jul 9 01:09:59 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36AA21F99CF for ; Tue, 9 Jul 2013 01:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.336 X-Spam-Level: X-Spam-Status: No, score=-105.336 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MS3UrOaRoXGd for ; Tue, 9 Jul 2013 01:09:53 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9B21F9AC2 for ; Tue, 9 Jul 2013 01:09:45 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-a0-51dbc5488762 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 64.DC.19388.845CBD15; Tue, 9 Jul 2013 10:09:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Tue, 9 Jul 2013 10:09:44 +0200 Message-ID: <51DBC578.9000306@ericsson.com> Date: Tue, 9 Jul 2013 10:10:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> In-Reply-To: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvra7H0duBBp9bjCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvStkxgLDkpV3Pzt2MB4TaSLkZNDQsBEoulqOwuELSZx4d56 ti5GLg4hgcOMEoveLmGFcJYxStyY/pINpIpXQFuic8k6sA4WARWJnp+bmUFsNgELiZs/GsFq RAWCJY5s38wCUS8ocXLmEzBbREBIYnr/BCYQW1jAReLr1c9g9UICjhJfp/8Cq+EUcJK4sO0g 1EWSEltetLOD2MwCehJTrrYwQtjyEs1bZzND9GpLNDR1sE5gFJyFZN0sJC2zkLQsYGRexcie m5iZk15uvokRGH4Ht/w22MG46b7YIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTAWvnqVpPvowI/TLa28rt6Zh+7n8Hp++2H6b1JeyUNzwb2Gqzb47LDnUp34a2XIrkuX rn6Nenfpm/JthQ23gspnqjBHG5lXO3u4GHLtjFlcyWUfL3nxjqC7nWW4ju+nm/Wn9q3Y+3Hd fZYFz6c/+HT5/5GpE79MPMwkVHKqeOHBOVfXrXec8f7/TCWW4oxEQy3mouJEAPFCB/INAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:09:59 -0000 WG, This document has just been in IESG review and the authors has discussed with the IESG. One discuss raised was the implications of the MAC based generation of short-term persistent CNAMES. The conclusion in that discussion was to remove that option and rely only on random names in that case. I wanted to inform the WG about this significant change and give you a chance to react to this change before the document is approved. You will have one week to react. The details can be seen in this diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05 Cheers Magnus Westerlund On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) > Author(s) : Ali Begen > Colin Perkins > Dan Wing > Eric Rescorla > Filename : draft-ietf-avtcore-6222bis-05.txt > Pages : 10 > Date : 2013-07-08 > > Abstract: > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > persistent transport-level identifier for an RTP endpoint. While the > Synchronization Source (SSRC) identifier of an RTP endpoint may > change if a collision is detected or when the RTP application is > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > endpoints can be uniquely identified and associated with their RTP > media streams. > > For proper functionality, RTCP CNAMEs should be unique within the > participants of an RTP session. However, the existing guidelines for > choosing the RTCP CNAME provided in the RTP standard are insufficient > to achieve this uniqueness. RFC 6222 was published to update those > guidelines to allow endpoints to choose unique RTCP CNAMEs. > Unfortunately, later investigations showed that some parts of the new > algorithms were unnecessarily complicated and/or ineffective. This > document addresses these concerns and replaces RFC 6222. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 keith.drage@alcatel-lucent.com Tue Jul 9 08:38:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46B11E8128 for ; Tue, 9 Jul 2013 08:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CX4VaVl3-ch for ; Tue, 9 Jul 2013 08:38:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9556211E812A for ; Tue, 9 Jul 2013 08:38:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r69FcY27028495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Jul 2013 10:38:35 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r69FcXqj026928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 17:38:33 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 17:38:33 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt Thread-Index: AQHOfCI3WkFGIrKCkEarOElRktFoVplb3cQAgACdy0A= Date: Tue, 9 Jul 2013 15:38:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0675B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> In-Reply-To: <51DBC578.9000306@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:38:46 -0000 No comment on removing option a), but later in the document I did note the = sentence: "This value MUST be at least 96 bits and MAY be up to 512 bits." To me "MAY defines an option, and therefore this appears to be stating that= the upper limit is optional, whereas I believe you are stating: "This value MUST be at least 96 bits and MUST be less than 512 bits." Regards Keith > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: 09 July 2013 09:11 > To: avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt >=20 > WG, >=20 > This document has just been in IESG review and the authors has discussed > with the IESG. One discuss raised was the implications of the MAC based > generation of short-term persistent CNAMES. The conclusion in that > discussion was to remove that option and rely only on random names in > that case. >=20 > I wanted to inform the WG about this significant change and give you a > chance to react to this change before the document is approved. You will > have one week to react. >=20 > The details can be seen in this diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Audio/Video Transport Core Maintenanc= e > Working Group of the IETF. > > > > Title : Guidelines for Choosing RTP Control Protocol > (RTCP) Canonical Names (CNAMEs) > > Author(s) : Ali Begen > > Colin Perkins > > Dan Wing > > Eric Rescorla > > Filename : draft-ietf-avtcore-6222bis-05.txt > > Pages : 10 > > Date : 2013-07-08 > > > > Abstract: > > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > > persistent transport-level identifier for an RTP endpoint. While th= e > > Synchronization Source (SSRC) identifier of an RTP endpoint may > > change if a collision is detected or when the RTP application is > > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > > endpoints can be uniquely identified and associated with their RTP > > media streams. > > > > For proper functionality, RTCP CNAMEs should be unique within the > > participants of an RTP session. However, the existing guidelines fo= r > > choosing the RTCP CNAME provided in the RTP standard are insufficien= t > > to achieve this uniqueness. RFC 6222 was published to update those > > guidelines to allow endpoints to choose unique RTCP CNAMEs. > > Unfortunately, later investigations showed that some parts of the ne= w > > algorithms were unnecessarily complicated and/or ineffective. This > > document addresses these concerns and replaces RFC 6222. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From dwing@cisco.com Tue Jul 9 19:15:10 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21421F8749 for ; Tue, 9 Jul 2013 19:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVO5UWkcSlup for ; Tue, 9 Jul 2013 19:15:06 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 395AE11E80EF for ; Tue, 9 Jul 2013 19:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5718; q=dns/txt; s=iport; t=1373422506; x=1374632106; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pOOvR6m3CyX7XjahJKXAGelzSzofYB2jiZ+RfoOequs=; b=WnQSs+ifdS0Tj2VzVAcd7VjakhcATdplFksegORa0ew/Qt8D4rfP6jo5 CgXc7nop171jZVDvWbm6xpkT5B6Z5VV3nKQZm32aIwb77fj5mku9/7Mp5 zI99BvMFzcRbL6PTSzGus1HAnjGdbrACb7ca0WSg5NT3oxe3LVDFo2NKJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAMLC3FGrRDoJ/2dsb2JhbABagwkyR8EOgREWdIIjAQEBAwEBAQEJbQUHAgILEQQBAQEnBxsMHwkIBhMJiAAFCAW6CgSOMIEEMwcGgwNrA4klji+BKZAggzEcgS0 X-IronPort-AV: E=Sophos;i="4.87,1032,1363132800"; d="scan'208";a="83074050" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Jul 2013 02:15:05 +0000 Received: from sjc-vpn3-1253.cisco.com (sjc-vpn3-1253.cisco.com [10.21.68.229]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6A2F314032386; Wed, 10 Jul 2013 02:15:03 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0675B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 9 Jul 2013 19:15:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24BEECDC-9FE6-4FBE-85F9-2ACBF9887591@cisco.com> References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0675B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1508) Cc: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 02:15:10 -0000 On Jul 9, 2013, at 8:38 AM, "DRAGE, Keith (Keith)" = wrote: > No comment on removing option a), but later in the document I did note = the sentence: >=20 > "This value MUST be at least 96 bits and MAY be up to 512 bits." >=20 > To me "MAY defines an option, and therefore this appears to be stating = that the upper limit is optional, whereas I believe you are stating: >=20 > "This value MUST be at least 96 bits and MUST be less than 512 bits." RFC4096 ("Randomness Requirements for Security") has as its longest = output 512 bits, and that document is what we cite for generating the = random value. A value longer than 512 bits is permitted, and would not = cause interoperability problems; it just needs to fit into the CNAME = space, which has a maximum size of 255 octets of ASCII characters. If = there is need to specify the maximum length to conform to RFC3550's = CNAME length limit, that maximum would be 255 octets * 3 / 4 =3D 191.25 = octets (the 3/4 is to for binary to BASE64 encoding, the .25 octets gets = into nuance of BASE64 encoding, I don't want to worry about BASE64 = encoders). But that is a limit of CNAME encoding in RFC3550. I propose = draft-ietf-avtcore-6222bis just say "The value MUST be at least 96 bits" = and not worry about the maximum -- CNAME already has a maximum due to = its 255 octet length. -d >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Magnus Westerlund >> Sent: 09 July 2013 09:11 >> To: avt@ietf.org >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt >>=20 >> WG, >>=20 >> This document has just been in IESG review and the authors has = discussed >> with the IESG. One discuss raised was the implications of the MAC = based >> generation of short-term persistent CNAMES. The conclusion in that >> discussion was to remove that option and rely only on random names in >> that case. >>=20 >> I wanted to inform the WG about this significant change and give you = a >> chance to react to this change before the document is approved. You = will >> have one week to react. >>=20 >> The details can be seen in this diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 >>=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >>=20 >> On 2013-07-08 23:29, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Audio/Video Transport Core = Maintenance >> Working Group of the IETF. >>>=20 >>> Title : Guidelines for Choosing RTP Control Protocol >> (RTCP) Canonical Names (CNAMEs) >>> Author(s) : Ali Begen >>> Colin Perkins >>> Dan Wing >>> Eric Rescorla >>> Filename : draft-ietf-avtcore-6222bis-05.txt >>> Pages : 10 >>> Date : 2013-07-08 >>>=20 >>> Abstract: >>> The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a >>> persistent transport-level identifier for an RTP endpoint. While = the >>> Synchronization Source (SSRC) identifier of an RTP endpoint may >>> change if a collision is detected or when the RTP application is >>> restarted, its RTCP CNAME is meant to stay unchanged, so that RTP >>> endpoints can be uniquely identified and associated with their RTP >>> media streams. >>>=20 >>> For proper functionality, RTCP CNAMEs should be unique within the >>> participants of an RTP session. However, the existing guidelines = for >>> choosing the RTCP CNAME provided in the RTP standard are = insufficient >>> to achieve this uniqueness. RFC 6222 was published to update = those >>> guidelines to allow endpoints to choose unique RTCP CNAMEs. >>> Unfortunately, later investigations showed that some parts of the = new >>> algorithms were unnecessarily complicated and/or ineffective. = This >>> document addresses these concerns and replaces RFC 6222. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>>=20 >>>=20 >>=20 >>=20 >> -- >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From keith.drage@alcatel-lucent.com Wed Jul 10 07:11:55 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DEA21F9F13 for ; Wed, 10 Jul 2013 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilHJboqOlvor for ; Wed, 10 Jul 2013 07:11:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7537D21F9AEE for ; Wed, 10 Jul 2013 07:11:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6AEBhqM010882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 09:11:45 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6AEBhJ5018151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 16:11:43 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 16:11:43 +0200 From: "DRAGE, Keith (Keith)" To: Dan Wing Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt Thread-Index: AQHOfRNJWkFGIrKCkEarOElRktFoVpld9FNQ Date: Wed, 10 Jul 2013 14:11:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B067E6C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0675B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <24BEECDC-9FE6-4FBE-85F9-2ACBF9887591@cisco.com> In-Reply-To: <24BEECDC-9FE6-4FBE-85F9-2ACBF9887591@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:11:55 -0000 If that applies then I agree. I might suggest an informative statement indicating that the maximum length= is fixed by RFC 3550. Keith > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 10 July 2013 03:15 > To: DRAGE, Keith (Keith) > Cc: Magnus Westerlund; avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt >=20 >=20 > On Jul 9, 2013, at 8:38 AM, "DRAGE, Keith (Keith)" lucent.com> wrote: >=20 > > No comment on removing option a), but later in the document I did note > the sentence: > > > > "This value MUST be at least 96 bits and MAY be up to 512 bits." > > > > To me "MAY defines an option, and therefore this appears to be stating > that the upper limit is optional, whereas I believe you are stating: > > > > "This value MUST be at least 96 bits and MUST be less than 512 > bits." >=20 > RFC4096 ("Randomness Requirements for Security") has as its longest outpu= t > 512 bits, and that document is what we cite for generating the random > value. A value longer than 512 bits is permitted, and would not cause > interoperability problems; it just needs to fit into the CNAME space, > which has a maximum size of 255 octets of ASCII characters. If there is > need to specify the maximum length to conform to RFC3550's CNAME length > limit, that maximum would be 255 octets * 3 / 4 =3D 191.25 octets (the 3/= 4 > is to for binary to BASE64 encoding, the .25 octets gets into nuance of > BASE64 encoding, I don't want to worry about BASE64 encoders). But that > is a limit of CNAME encoding in RFC3550. I propose draft-ietf-avtcore- > 6222bis just say "The value MUST be at least 96 bits" and not worry about > the maximum -- CNAME already has a maximum due to its 255 octet length. >=20 > -d >=20 >=20 >=20 > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > >> Magnus Westerlund > >> Sent: 09 July 2013 09:11 > >> To: avt@ietf.org > >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt > >> > >> WG, > >> > >> This document has just been in IESG review and the authors has > discussed > >> with the IESG. One discuss raised was the implications of the MAC base= d > >> generation of short-term persistent CNAMES. The conclusion in that > >> discussion was to remove that option and rely only on random names in > >> that case. > >> > >> I wanted to inform the WG about this significant change and give you a > >> chance to react to this change before the document is approved. You > will > >> have one week to react. > >> > >> The details can be seen in this diff: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > >> > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> > >> On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Audio/Video Transport Core > Maintenance > >> Working Group of the IETF. > >>> > >>> Title : Guidelines for Choosing RTP Control Protocol > >> (RTCP) Canonical Names (CNAMEs) > >>> Author(s) : Ali Begen > >>> Colin Perkins > >>> Dan Wing > >>> Eric Rescorla > >>> Filename : draft-ietf-avtcore-6222bis-05.txt > >>> Pages : 10 > >>> Date : 2013-07-08 > >>> > >>> Abstract: > >>> The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > >>> persistent transport-level identifier for an RTP endpoint. While > the > >>> Synchronization Source (SSRC) identifier of an RTP endpoint may > >>> change if a collision is detected or when the RTP application is > >>> restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > >>> endpoints can be uniquely identified and associated with their RTP > >>> media streams. > >>> > >>> For proper functionality, RTCP CNAMEs should be unique within the > >>> participants of an RTP session. However, the existing guidelines > for > >>> choosing the RTCP CNAME provided in the RTP standard are > insufficient > >>> to achieve this uniqueness. RFC 6222 was published to update those > >>> guidelines to allow endpoints to choose unique RTCP CNAMEs. > >>> Unfortunately, later investigations showed that some parts of the > new > >>> algorithms were unnecessarily complicated and/or ineffective. This > >>> document addresses these concerns and replaces RFC 6222. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> Audio/Video Transport Core Maintenance > >>> avt@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avt > >>> > >>> > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> > >> _______________________________________________ > >> Audio/Video Transport Core Maintenance > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt From tterribe@xiph.org Wed Jul 10 10:56:57 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2A21F9DC6 for ; Wed, 10 Jul 2013 10:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Q6wQZuVrOK for ; Wed, 10 Jul 2013 10:56:51 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id BCE3921F9DB0 for ; Wed, 10 Jul 2013 10:56:51 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E51B5F2301 for ; Wed, 10 Jul 2013 10:56:22 -0700 (PDT) Message-ID: <51DDA046.1020502@xiph.org> Date: Wed, 10 Jul 2013 10:56:22 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: avt@ietf.org References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> In-Reply-To: <51DBC578.9000306@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:56:57 -0000 Magnus Westerlund wrote: > I wanted to inform the WG about this significant change and give you a > chance to react to this change before the document is approved. You will > have one week to react. I've read the changes and they look fine to me. From internet-drafts@ietf.org Thu Jul 11 04:00:39 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EBC21F9A1F; Thu, 11 Jul 2013 04:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEhWjZcjEaYg; Thu, 11 Jul 2013 04:00:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE421F99DB; Thu, 11 Jul 2013 04:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711110039.10104.13956.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 04:00:39 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 11:00:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Sending Multiple Types of Media in a Single RTP Session Author(s) : Magnus Westerlund Colin Perkins Jonathan Lennox Filename : draft-ietf-avtcore-multi-media-rtp-session-03.txt Pages : 18 Date : 2013-07-11 Abstract: This document specifies how an RTP session can contain media streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multi-media-rtp-sessi= on-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jul 11 04:04:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0011E8102; Thu, 11 Jul 2013 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Ekuv64DMtz; Thu, 11 Jul 2013 04:04:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2AC21F9B94; Thu, 11 Jul 2013 04:04:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711110428.10126.2775.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 04:04:28 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 11:04:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session Author(s) : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-01.txt Pages : 16 Date : 2013-07-11 Abstract: This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are sending multiple media streams in a single RTP session. In particular, issues involving Real-Time Transport Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-multi-stream-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kmigoe@nsa.gov Thu Jul 11 05:46:44 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97F21F9A50 for ; Thu, 11 Jul 2013 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH+6Gk+0LciN for ; Thu, 11 Jul 2013 05:46:39 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5B11E811A for ; Thu, 11 Jul 2013 05:46:35 -0700 (PDT) X-TM-IMSS-Message-ID: <2d31e497000ca4c8@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 2d31e497000ca4c8 ; Thu, 11 Jul 2013 08:51:27 -0400 Received: from MSMR-GH1-UEA01.corp.nsa.gov (10.215.225.4) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 11 Jul 2013 08:46:22 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA01.corp.nsa.gov ([10.215.225.4]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 08:46:22 -0400 From: "Igoe, Kevin M." To: 'Woo-Hwan Kim' , "avt@ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" Thread-Topic: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 Thread-Index: AQHOcvZdyF8XiGfZnU6WzSL8YTGH5plfgpCw Date: Thu, 11 Jul 2013 12:46:21 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CAB243CD51@MSMR-GH1-UEA03.corp.nsa.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CAB243CD51MSMRGH1UEA03cor_" MIME-Version: 1.0 Cc: Magnus Westerlund , Daesung Kwon , Je Hong Park Subject: Re: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:46:44 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CAB243CD51MSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks for the observations. I think draft -07 (which I put out before I saw your note) caught most of the errors you point out. Your time and effort in reviewing the draft are greatly appreciated. From: woohwankim@gmail.com [mailto:woohwankim@gmail.com] On Behalf Of Woo-H= wan Kim Sent: Thursday, June 27, 2013 1:23 AM To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Cc: Je Hong Park; Daesung Kwon; Magnus Westerlund Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 Hi. Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-06. 1. In section 5.2, Tag_Size_Flag is used for CCM mode input and it is writt= en that the tag size for GCM mode is determined by the algorithm choice. There is no difference between CCM and GCM from the point of view that the = ciphersuite can determine the tag length. CCM needs tag length in the input formatting function while GCM does not. But I think it does not imply that the inputs of GCM and CCM differ and it = is better to be consistent. 2. AES-CCM ciphersuites is defined for each tag length except but Section 1= 4.1. I think it is better to add the following ciphersuites in Section 14.1 as w= ell as other parts of the draft. - AEAD_AES_128_CCM_8 - AEAD_AES_256_CCM_8 - AEAD_AES_128_CCM_12 - AEAD_AES_256_CCM_12 3. Section 6, Section 11.1 (2^24)-16 octets =3D> (2^28)-16 octets Regards, Woo-Hwan Kim --_000_3C4AAD4B5304AB44A6BA85173B4675CAB243CD51MSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many thanks for the obser= vations.  I think draft -07 (which I put out

before I saw your note) c= aught most of the errors you point out.

Your time and effort in r= eviewing the draft are greatly appreciated.

 <= /p>

From: woohwank= im@gmail.com [mailto:woohwankim@gmail.com] On Behalf Of Woo-Hwan Kim
Sent: Thursday, June 27, 2013 1:23 AM
To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
Cc: Je Hong Park; Daesung Kwon; Magnus Westerlund
Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-0= 6

 

Hi.

 

Here are some comments on the draft-ietf-avtcor= e-srtp-aes-gcm-06.


1. In section 5.2, Tag_Size_Flag is used for CCM mode input and it is writt= en that the tag size for GCM mode is determined by the algorithm choice.

There is no difference between CCM and GCM from the = point of view that the ciphersuite can determine the tag length.
CCM needs tag length in the input formatting function while GCM does not. <= br> But I think it does not imply that the inputs of GCM and CCM differ and it = is better to be consistent.

 

2. AES-CCM ciphersuites is defined for each tag leng= th except but Section 14.1.

I think it is better to add the following ciphersuit= es in Section 14.1 as well as other parts of the draft.

- AEAD_AES_128_CCM_8

- AEAD_AES_256_CCM_8

- AEAD_AES_128_CCM_12

- AEAD_AES_256_CCM_12

 

3. Section 6, Section 11.1
 (2^24)-16 octets =3D> (2^28)-16 octets

 

Regards, Woo-Hwan Kim

--_000_3C4AAD4B5304AB44A6BA85173B4675CAB243CD51MSMRGH1UEA03cor_-- From internet-drafts@ietf.org Sun Jul 14 01:04:18 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7511E80F6; Sun, 14 Jul 2013 01:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.379 X-Spam-Level: X-Spam-Status: No, score=-98.379 tagged_above=-999 required=5 tests=[AWL=-4.111, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cAHqfHUhmmY; Sun, 14 Jul 2013 01:04:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53611E80F2; Sun, 14 Jul 2013 01:04:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714080418.18036.97048.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 01:04:18 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 08:04:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-05.txt Pages : 28 Date : 2013-07-14 Abstract: NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-clksrc-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 14 03:43:14 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D721E8083; Sun, 14 Jul 2013 03:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkNK7DpjP0I1; Sun, 14 Jul 2013 03:43:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4263721E804D; Sun, 14 Jul 2013 03:43:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714104314.21693.56509.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 03:43:14 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 10:43:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-06.txt Pages : 10 Date : 2013-07-14 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 14 11:40:47 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950AC21F9CCA; Sun, 14 Jul 2013 11:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R3WEjU1lvu8; Sun, 14 Jul 2013 11:40:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485121F9ADA; Sun, 14 Jul 2013 11:40:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714184047.28660.71355.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 11:40:47 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 18:40:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP and Leap Seconds Author(s) : Kevin Gross Ray van Brandenburg Filename : draft-ietf-avtcore-leap-second-03.txt Pages : 8 Date : 2013-07-14 Abstract: This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-leap-second-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Sun Jul 14 12:12:24 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58BA21F9AB4 for ; Sun, 14 Jul 2013 12:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL7waKLyvb4D for ; Sun, 14 Jul 2013 12:12:20 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id D6DE121F9A6D for ; Sun, 14 Jul 2013 12:12:20 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 0JeQ1m0040mlR8UA8KCLj3; Sun, 14 Jul 2013 19:12:20 +0000 Received: from mail-oa0-x236.google.com ([IPv6:2607:f8b0:4003:c02::236]) by omta11.emeryville.ca.mail.comcast.net with comcast id 0KCK1m00e2DFVdt8XKCLMn; Sun, 14 Jul 2013 19:12:20 +0000 Received: by mail-oa0-f54.google.com with SMTP id o6so14956297oag.13 for ; Sun, 14 Jul 2013 12:12:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTyq/xCE7OkO8LIbPj51Cfven1Dj6thdOiXcunLw6/A=; b=N9gYXFdsXglC0c+6VsaZgvrOMPhGbQboAPAjznbqPQRfLUAxTPwEvLpbgwQkgHHrVJ iDRs72tciQd/kt30dovJC+C6+o7PniXNpl4nGE/mvKX2faGtJXDnzfk8QTnrVqKWpSYw 8XjtwA66feXRXozoJM73bImMaZvFWB0Y1Kx9iYIh647gY47wM4gfV1rA1ldJoSEiXO2H xhgRLFiWmT+HEq1I6tKKyE0QVBYCHj06VQz1+ZycW+QzlDikIjPSgEFvmo1ehfGeejWl ExpgrS+10/SS2DcH26iPL0jR0oqPtVXHuPT4a/FSXB1QcTLzLF4qVPBEfS5Ae1oB2hjr shmw== MIME-Version: 1.0 X-Received: by 10.60.54.39 with SMTP id g7mr41070756oep.18.1373829139570; Sun, 14 Jul 2013 12:12:19 -0700 (PDT) Received: by 10.182.34.202 with HTTP; Sun, 14 Jul 2013 12:12:19 -0700 (PDT) In-Reply-To: <20130714184047.28660.71355.idtracker@ietfa.amsl.com> References: <20130714184047.28660.71355.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 13:12:19 -0600 Message-ID: From: Kevin Gross To: "avt@ietf.org" Content-Type: multipart/alternative; boundary=089e01161db0d8a97604e17d85e1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373829140; bh=oTyq/xCE7OkO8LIbPj51Cfven1Dj6thdOiXcunLw6/A=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=cAIjVu/q/sYWSzPZvnkLYkVMpKp755O0l6Kx05e4fb93637m1pQfURWlzU/Zh8AjD o4KOgtLDX50jiwsjChUVqWaa8MJ3uwvIse7Ssy7XNJhUkp7sVnEA2K5SNp6SmgKkfv Hdx10eaGnrX6q8VtS3JZNo5tdZ/dlb58X2zFw33MduvPOTB0aod105s/NlZDGBQjGp UEM+0xMdCTHOWFIoavxqoqVqar6CAcYR3OdtYLpZaw1JCUN9Dp3xQW8ETEDmQqvUtE 96Ml3Oz32We8ZIcO8jPWbAIBqJzxloZxTPKYzlUu/Cmnr4roOxwcCZecjqePdPTqtA lbvRCTd2AJznA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 19:12:24 -0000 --089e01161db0d8a97604e17d85e1 Content-Type: text/plain; charset=ISO-8859-1 This version resolves comments received from John Fletcher. I've also added an informative discussion or receiver behavior as requested during my IETF86 presentation. I will not be presenting this at IETF87 because I believe it is ready for WGLC. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Sun, Jul 14, 2013 at 12:40 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > Title : RTP and Leap Seconds > Author(s) : Kevin Gross > Ray van Brandenburg > Filename : draft-ietf-avtcore-leap-second-03.txt > Pages : 8 > Date : 2013-07-14 > > Abstract: > This document discusses issues that arise when RTP sessions span > Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 > to describe how RTP senders and receivers should behave in the > presence of leap seconds. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-leap-second-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --089e01161db0d8a97604e17d85e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This version resolves comments received from John Fletcher= . I've also added an informative discussion or receiver behavior as req= uested during my IETF86 presentation. I will not be presenting this at IETF= 87 because I believe it is ready for WGLC.

Kevin Gross
+1-303-447-0517
Media = Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Sun, Jul 14, 2013 at 12:40 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Audio/Video Transport Core Maintenance = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP and Leap Seconds
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Kevin Gross
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ray van Brandenburg
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-leap-second-03= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-14

Abstract:
=A0 =A0This document discusses issues that arise when RTP sessions span
=A0 =A0Coordinated Universal Time (UTC) leap seconds. =A0It updates RFC 355= 0
=A0 =A0to describe how RTP senders and receivers should behave in the
=A0 =A0presence of leap seconds.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap= -second

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-0= 3

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtco= re-leap-second-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--089e01161db0d8a97604e17d85e1-- From internet-drafts@ietf.org Mon Jul 15 04:52:11 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C40D21F8952; Mon, 15 Jul 2013 04:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKHupurVBQRz; Mon, 15 Jul 2013 04:52:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1515F21F9A05; Mon, 15 Jul 2013 04:52:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715115202.7033.83195.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 04:52:02 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 11:52:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session: = Grouping RTCP Reception Statistics and Other Feedback Author(s) : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-optimisation-00.txt Pages : 10 Date : 2013-07-11 Abstract: RTP allows multiple media streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimi= sation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisation= -00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Mon Jul 15 10:10:26 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C839F11E81A4 for ; Mon, 15 Jul 2013 10:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKvIhfgdJxnD for ; Mon, 15 Jul 2013 10:10:23 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8842211E8140 for ; Mon, 15 Jul 2013 10:10:12 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 0dtC1m0070mlR8UA9hACFn; Mon, 15 Jul 2013 17:10:12 +0000 Received: from mail-oa0-x234.google.com ([IPv6:2607:f8b0:4003:c02::234]) by omta11.emeryville.ca.mail.comcast.net with comcast id 0hA91m00226Tkke8XhA9VV; Mon, 15 Jul 2013 17:10:12 +0000 Received: by mail-oa0-f52.google.com with SMTP id g12so15824756oah.25 for ; Mon, 15 Jul 2013 10:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ugCqNfBnMlrPlw2KIi1cWwN1nYw6FBsaeqFaeRXhxPM=; b=OQikkVzfvnBDurtbik0KkV0iDXdB0WWJDZZeX/Ww0uKLONBGAnITtXig1xENhBRQoF WO6VWNUzBHYE0yyPVUI6ipPus+hZTyyQqVzaAnZVNJAxeCocfASWeY7uACJZlVMfowwq xOLJzwL9/vmo/55BJciqf1hCcdXX1xuicMWT2xdOR7OtHgcidzC2an+oYSil7sl+M2NU 1jq/1PNgW8Q4xArv8IJXrSSe5HJiFfmuDP2PHlBxwQx36e8ZH8YHE3ZJ+IKWnosar7eF jz7A5/obUwpsVo614cS7P+RsQhDOFOmja4MrFlrmeEav4gvpvMRmo1U/51EWIVZBN6HY DxQw== MIME-Version: 1.0 X-Received: by 10.60.164.33 with SMTP id yn1mr44522340oeb.5.1373908208897; Mon, 15 Jul 2013 10:10:08 -0700 (PDT) Received: by 10.182.34.202 with HTTP; Mon, 15 Jul 2013 10:10:08 -0700 (PDT) In-Reply-To: <51DBC578.9000306@ericsson.com> References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> Date: Mon, 15 Jul 2013 11:10:08 -0600 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b41cba8bed98004e18fee0e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373908212; bh=ugCqNfBnMlrPlw2KIi1cWwN1nYw6FBsaeqFaeRXhxPM=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=Am/QjaJzf4AsdrWYgZfEqeZtdRTgZHSXgamtvY4Gv8WY3uJokkr6ZZ+bF3mGhuca/ FVPm+G6WdZfMOVUgC4hSL8I7zya/Mf20yw7dGF41pigZLnxBCj8tXRrx+DQ6go1WRS UVCEcaVeGWCQWRT5dVmn69L88i63bQe+iEsomgFJ6LePmCUcNooKeGZsNV7N70MKrX ajzvWLt2wGjtMHdR499enBal4cSzeRkjJLFQ2ANVey6aR4JQz5RrrUbCg3zKNwKUdY aX3OXyHzJcYgJlqBMgb862rnnjAE/WclbRHU521s0wgNWAVtJkYi04fupgSDF6vjdQ uPxOyrXMFrOSg== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:10:26 -0000 --047d7b41cba8bed98004e18fee0e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, this is a significant change. It appears to imply that a cryptographic PRNG is required in every RTP device and things will be more difficult for 3rd party network performance monitoring systems. Although there is discussion in the draft downplaying these issues, there are RTP applications that won't otherwise require a CPRNG and there are applications where ease of monitoring is more important than security. What was the reason given for wanting to remove the MAC option? If we go with this, I suggest an editorial pass to reduce repetition in the last two bullets in section 4.2 and clean up references to "multiple", "several" as there are now only two methods recommended for generating CNAMEs. Let me know if you need any help with this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > This document has just been in IESG review and the authors has discussed > with the IESG. One discuss raised was the implications of the MAC based > generation of short-term persistent CNAMES. The conclusion in that > discussion was to remove that option and rely only on random names in > that case. > > I wanted to inform the WG about this significant change and give you a > chance to react to this change before the document is approved. You will > have one week to react. > > The details can be seen in this diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > Cheers > > Magnus Westerlund > > > On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Audio/Video Transport Core Maintenanc= e > Working Group of the IETF. > > > > Title : Guidelines for Choosing RTP Control Protocol > (RTCP) Canonical Names (CNAMEs) > > Author(s) : Ali Begen > > Colin Perkins > > Dan Wing > > Eric Rescorla > > Filename : draft-ietf-avtcore-6222bis-05.txt > > Pages : 10 > > Date : 2013-07-08 > > > > Abstract: > > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > > persistent transport-level identifier for an RTP endpoint. While th= e > > Synchronization Source (SSRC) identifier of an RTP endpoint may > > change if a collision is detected or when the RTP application is > > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > > endpoints can be uniquely identified and associated with their RTP > > media streams. > > > > For proper functionality, RTCP CNAMEs should be unique within the > > participants of an RTP session. However, the existing guidelines fo= r > > choosing the RTCP CNAME provided in the RTP standard are insufficien= t > > to achieve this uniqueness. RFC 6222 was published to update those > > guidelines to allow endpoints to choose unique RTCP CNAMEs. > > Unfortunately, later investigations showed that some parts of the ne= w > > algorithms were unnecessarily complicated and/or ineffective. This > > document addresses these concerns and replaces RFC 6222. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --047d7b41cba8bed98004e18fee0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, this is a significant change. It appears to imply tha= t a cryptographic PRNG is required in every RTP device and things will be m= ore difficult for 3rd party network performance monitoring systems.
Although there is discussion in the draft downplaying these issu= es, there are RTP applications that won't otherwise require a CPRNG and= there are applications where ease of monitoring is more important than sec= urity.

What was the reason given for wanting to remove the MAC opti= on?

If we go with this, I suggest an editorial pass = to reduce repetition in the last two bullets in section 4.2 and clean up re= ferences to "multiple", "several" as there are now only= two methods recommended for generating CNAMEs. Let me know if you need any= help with this.

Kevin G= ross
+1-303-447-0517
Media Network Consultant
AVA= Networks -=A0www.AVAnw= .com,=A0www.X192.org<= /a>


On Tue, Jul 9, 2013 at 2:10 AM, Magnus W= esterlund <magnus.westerlund@ericsson.com> wrot= e:
WG,

This document has just been in IESG review and the authors has discussed with the IESG. One discuss raised was the implications of the MAC based
generation of short-term persistent CNAMES. The conclusion in that
discussion was to remove that option and rely only on random names in
that case.

I wanted to inform the WG about this significant change and give you a
chance to react to this change before the document is approved. You will have one week to react.

The details can be seen in this diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6= 222bis-05


Cheers

Magnus Westerlund


On 2013-07-08 23:29, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the Audio/Video Transport Core Mainten= ance Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Guidelines for Choosing RTP Co= ntrol Protocol (RTCP) Canonical Names (CNAMEs)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ali Begen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Colin Perkins
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dan Wing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-6222bis-05.tx= t
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 10
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-08
>
> Abstract:
> =A0 =A0The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
> =A0 =A0persistent transport-level identifier for an RTP endpoint. =A0W= hile the
> =A0 =A0Synchronization Source (SSRC) identifier of an RTP endpoint may=
> =A0 =A0change if a collision is detected or when the RTP application i= s
> =A0 =A0restarted, its RTCP CNAME is meant to stay unchanged, so that R= TP
> =A0 =A0endpoints can be uniquely identified and associated with their = RTP
> =A0 =A0media streams.
>
> =A0 =A0For proper functionality, RTCP CNAMEs should be unique within t= he
> =A0 =A0participants of an RTP session. =A0However, the existing guidel= ines for
> =A0 =A0choosing the RTCP CNAME provided in the RTP standard are insuff= icient
> =A0 =A0to achieve this uniqueness. =A0RFC 6222 was published to update= those
> =A0 =A0guidelines to allow endpoints to choose unique RTCP CNAMEs.
> =A0 =A0Unfortunately, later investigations showed that some parts of t= he new
> =A0 =A0algorithms were unnecessarily complicated and/or ineffective. = =A0This
> =A0 =A0document addresses these concerns and replaces RFC 6222.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-622= 2bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtc= ore-6222bis-05
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b41cba8bed98004e18fee0e-- From kevin.gross@avanw.com Mon Jul 15 10:22:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086F611E8105 for ; Mon, 15 Jul 2013 10:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.582 X-Spam-Level: **** X-Spam-Status: No, score=4.582 tagged_above=-999 required=5 tests=[AWL=-3.936, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz4QPZks7NV7 for ; Mon, 15 Jul 2013 10:22:49 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7C57311E8113 for ; Mon, 15 Jul 2013 10:22:49 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 0etP1m0020S2fkCA8hNljR; Mon, 15 Jul 2013 17:22:45 +0000 Received: from mail-oa0-x230.google.com ([IPv6:2607:f8b0:4003:c02::230]) by omta09.emeryville.ca.mail.comcast.net with comcast id 0hNk1m00Z5B3tyL8VhNkD0; Mon, 15 Jul 2013 17:22:45 +0000 Received: by mail-oa0-f48.google.com with SMTP id f4so15773464oah.7 for ; Mon, 15 Jul 2013 10:22:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YFA+13bhsGL4nsqc2E/OhwfyGQFzF2LL3cPa6baLzIU=; b=FWJwdqbC7TMBqp3ciA8Yq0Zq1RMSY39MCit2yTHsnlXOk7043qYfTT9IcHGIOlhLzB eCGYlzjbP8rirT8VDLLNjKZ9DkiB4Y5saSxJQD9l3nhu6wAKQMl5+Sf3jyib22l1n7NW 3F8OLux4T98We84Qxpgvf5cK/6nXFT1LCZgtb4MPvOJc36GVTCSPZ1fwzgoyIWzWYb1U wV3/LRx00jW1CO1/F5ZWvwsaODYhPdEGwJWel4Hav/c4LCkXabzIR3Hy+XTvn/mD2Xyn +cata5t1TCqdRTrAbUYeyDnwW+y5CbaDI5VC6Eg2oaHXwnL+HA9x9rvneFvSKTogeJc/ VUjg== MIME-Version: 1.0 X-Received: by 10.60.41.66 with SMTP id d2mr44870687oel.28.1373908964225; Mon, 15 Jul 2013 10:22:44 -0700 (PDT) Received: by 10.182.34.202 with HTTP; Mon, 15 Jul 2013 10:22:44 -0700 (PDT) In-Reply-To: <20130714080418.18036.97048.idtracker@ietfa.amsl.com> References: <20130714080418.18036.97048.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:22:44 -0600 Message-ID: From: Kevin Gross To: "avt@ietf.org" Content-Type: multipart/alternative; boundary=089e0149c800c43e2204e1901ba3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373908965; bh=YFA+13bhsGL4nsqc2E/OhwfyGQFzF2LL3cPa6baLzIU=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=XkhfvyOQtaP+afCiRaql0ZEIaIb3ki0NtUM0T6fwZKZcMKW0mrZfeidBeMnvCeXig P3MsXXgsSmCVBAN2la+lckdnqYUfxP0wIOHvdcZK9LUkZ0hukzHqUbZg88MKTV5OWy UKBsIjMjFi+h7uD4rLPmzKUM1bwZMxLsk4VgXg8bWs+9R0TOTiS9NJ/KRTRYhemJVu ovLF5x+09JD7aqIuQ48tq5DFcBTEcrFp3OZCxPgK+6VKf7pAJakpPQm588CmZd97XU 0Y3CQwygm9aKphGFgkhP9UDp2aVQm35K+Kif8mlZL+6LiB8PnV4W3H7vrqa8n3tf+Q 9d4cSRUyY1CKA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:22:54 -0000 --089e0149c800c43e2204e1901ba3 Content-Type: text/plain; charset=ISO-8859-1 This revision addresses to issues brought up in WGLC. Offer/answer is now a pure declarative model. Negotiation can be accomplished through external means or through techniques described in RFC 5939. Thanks to Magnus for the input on this. We've also added source-level registrations to the IANA section and defined them explicitly in the ABNF. Aidan has requested time to discuss the draft in Berlin so I assume we'll decide next steps for this draft during the meeting. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Sun, Jul 14, 2013 at 2:04 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > Title : RTP Clock Source Signalling > Author(s) : Aidan Williams > Kevin Gross > Ray van Brandenburg > Hans Stokking > Filename : draft-ietf-avtcore-clksrc-05.txt > Pages : 28 > Date : 2013-07-14 > > Abstract: > NTP format timestamps are used by several RTP protocols for > synchronisation and statistical measurements. This memo specifies > SDP signalling identifying timestamp reference clock sources and SDP > signalling identifying the media clock sources in a multimedia > session. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --089e0149c800c43e2204e1901ba3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This revision addresses to issues brought up in WGLC.
=
Offer/answer is now a pure declarative model. Negotiation ca= n be accomplished through external means or through techniques described in= RFC 5939. Thanks to Magnus for the input on this.

We've also added source-level registrations to the IANA = section and defined them explicitly in the ABNF.

A= idan has requested time to discuss the draft in Berlin so I assume we'l= l decide next steps for this draft during the meeting.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Netwo= rks -=A0www.AVAnw.com,=A0www.X192.org


On Sun, Jul 14, 2013 at 2:04 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Audio/Video Transport Core Maintenance = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Clock Source Signalling
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Aidan Williams
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin Gross
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ray van Brandenburg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hans Stokking
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-clksrc-05.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-14

Abstract:
=A0 =A0NTP format timestamps are used by several RTP protocols for
=A0 =A0synchronisation and statistical measurements. =A0This memo specifies=
=A0 =A0SDP signalling identifying timestamp reference clock sources and SDP=
=A0 =A0signalling identifying the media clock sources in a multimedia
=A0 =A0session.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-cl= ksrc-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--089e0149c800c43e2204e1901ba3-- From abegen@cisco.com Mon Jul 15 10:26:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADA121E80FA for ; Mon, 15 Jul 2013 10:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su+Nc67t0coj for ; Mon, 15 Jul 2013 10:26:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBD711E8105 for ; Mon, 15 Jul 2013 10:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5141; q=dns/txt; s=iport; t=1373909168; x=1375118768; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wvwHx1Mebj6DnU+JCJwRNIXvXhC9+lccTMWmP4l4d9U=; b=bkC+RfTAR+SXFp6LhVpoUmihcwsIs/1Ed+gpMHwjDGKF3cSHEKyfcxmB PqzXdhZZ4npKV/ZWZeOoQYuA/8AcHGX/4FXXRXp4N71/I4wqxMT9VCB89 d7/5Q//Z2HpyjKaVWmeWpSW8dI7RPd24MFHZiIcBr8dzya5LhyKTPrIlV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFIv5FGtJXHB/2dsb2JhbABXA4JlITRJBsFSgRMWdIIjAQEBAwEBAQEJPTAFCQICAQgYCh0HGwwLFBECBA4FCAGIAQYBBgW1ZASPLQIhEAcRgnptA4hvkBaQJIMSgig X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208";a="234837398" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 15 Jul 2013 17:26:06 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6FHQ5sY015893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 17:26:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 12:26:05 -0500 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt Thread-Index: AQHOfCI4duxf3HHV+EK539KA5+dpqJlcUx0AgAoEwACAAAR2AA== Date: Mon, 15 Jul 2013 17:26:04 +0000 Message-ID: References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:26:13 -0000 MAC addresses are not unique anymore, so cannot be reliably used for cname = generation. On Jul 15, 2013, at 10:10 AM, Kevin Gross wrote: > Yes, this is a significant change. It appears to imply that a cryptograph= ic PRNG is required in every RTP device and things will be more difficult f= or 3rd party network performance monitoring systems. >=20 > Although there is discussion in the draft downplaying these issues, there= are RTP applications that won't otherwise require a CPRNG and there are ap= plications where ease of monitoring is more important than security. >=20 > What was the reason given for wanting to remove the MAC option? >=20 > If we go with this, I suggest an editorial pass to reduce repetition in t= he last two bullets in section 4.2 and clean up references to "multiple", "= several" as there are now only two methods recommended for generating CNAME= s. Let me know if you need any help with this. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org >=20 >=20 > On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund wrote: > WG, >=20 > This document has just been in IESG review and the authors has discussed > with the IESG. One discuss raised was the implications of the MAC based > generation of short-term persistent CNAMES. The conclusion in that > discussion was to remove that option and rely only on random names in > that case. >=20 > I wanted to inform the WG about this significant change and give you a > chance to react to this change before the document is approved. You will > have one week to react. >=20 > The details can be seen in this diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. > > > > Title : Guidelines for Choosing RTP Control Protocol (R= TCP) Canonical Names (CNAMEs) > > Author(s) : Ali Begen > > Colin Perkins > > Dan Wing > > Eric Rescorla > > Filename : draft-ietf-avtcore-6222bis-05.txt > > Pages : 10 > > Date : 2013-07-08 > > > > Abstract: > > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > > persistent transport-level identifier for an RTP endpoint. While th= e > > Synchronization Source (SSRC) identifier of an RTP endpoint may > > change if a collision is detected or when the RTP application is > > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > > endpoints can be uniquely identified and associated with their RTP > > media streams. > > > > For proper functionality, RTCP CNAMEs should be unique within the > > participants of an RTP session. However, the existing guidelines fo= r > > choosing the RTCP CNAME provided in the RTP standard are insufficien= t > > to achieve this uniqueness. RFC 6222 was published to update those > > guidelines to allow endpoints to choose unique RTCP CNAMEs. > > Unfortunately, later investigations showed that some parts of the ne= w > > algorithms were unnecessarily complicated and/or ineffective. This > > document addresses these concerns and replaces RFC 6222. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Mon Jul 15 11:45:09 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C7911E81E0; Mon, 15 Jul 2013 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQZ0L6JqJ+wF; Mon, 15 Jul 2013 11:45:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5511E81C6; Mon, 15 Jul 2013 11:45:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715184505.9072.24782.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:45:05 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:45:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for using the Multiplexing Features of RTP to= Support Multiple Media Streams Author(s) : Magnus Westerlund Bo Burman Colin Perkins Harald Tveit Alvestrand Filename : draft-ietf-avtcore-multiplex-guidelines-01.txt Pages : 46 Date : 2013-07-15 Abstract: The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multiplex-guidelines-= 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 11:55:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32BA11E8202; Mon, 15 Jul 2013 11:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv-CHU5z0Xz9; Mon, 15 Jul 2013 11:55:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 942F311E8210; Mon, 15 Jul 2013 11:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715185534.31264.26535.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:55:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:55:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Multimedia Congestion Control: Circuit Breakers for Unic= ast RTP Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-ietf-avtcore-rtp-circuit-breakers-03.txt Pages : 17 Date : 2013-07-15 Abstract: The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP "circuit-breakers". Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-circuit-breakers-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Mon Jul 15 13:48:47 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088AC11E81E3 for ; Mon, 15 Jul 2013 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.203 X-Spam-Level: * X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob7aGmk9RU+A for ; Mon, 15 Jul 2013 13:48:43 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2696D11E81FD for ; Mon, 15 Jul 2013 13:48:43 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0jvi1m0041wfjNsA1koiyl; Mon, 15 Jul 2013 20:48:42 +0000 Received: from mail-ob0-x231.google.com ([IPv6:2607:f8b0:4003:c01::231]) by omta23.emeryville.ca.mail.comcast.net with comcast id 0koh1m00h4ocCJw8jkoiqe; Mon, 15 Jul 2013 20:48:42 +0000 Received: by mail-ob0-f177.google.com with SMTP id ta17so14369857obb.8 for ; Mon, 15 Jul 2013 13:48:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AWpV1Pr0QgOEVCNF2K+uC+qom/lmsffBPHJuyutgcLM=; b=WouFNABTpz00rQ115VV/lKmO0pRtY0c01oEczeFZSsg5FpFsAbiUAuBRFzCAb4nt3O iR+WQ1z0ptXicQbwx5WlEJcg38uJ0TRhT1wtpftY/NeA+wGpcXlbCNAijklMz2sUygkG xTy/Lr6xgfPiD4tLQ1Y9qdHGyc5N4sfevWPLqgggkalC7rSJVJYE8qJMdiJEtcv8RT34 VQR6rjXfRjmIzXnC5ODzVOPOUO6/xCTQ+ZQ1WhcYLtBpe841HeLVW5qI+r991k08FMrE GSRokrQtpZqjkki/PKVOCImYfXwD/m6CriJClvU7GQQlHNUWEhbmjsK+CKh9nIQ6IeNx DxUw== MIME-Version: 1.0 X-Received: by 10.182.196.1 with SMTP id ii1mr44309468obc.93.1373921321573; Mon, 15 Jul 2013 13:48:41 -0700 (PDT) Received: by 10.182.34.202 with HTTP; Mon, 15 Jul 2013 13:48:41 -0700 (PDT) In-Reply-To: References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> Date: Mon, 15 Jul 2013 14:48:41 -0600 Message-ID: From: Kevin Gross To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=089e015383e05267a204e192fc3e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373921322; bh=AWpV1Pr0QgOEVCNF2K+uC+qom/lmsffBPHJuyutgcLM=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=Gtd2hnfq5aBhae1ayzeKm0RcSd88M3vP4Tyr9YEVBL/Xxzf5HlJM98kT1eSrGEaGI Y7uvvK5pQvmGzXcSxJ3pSavPPnMzKM1f/jN6S1YGptjYdrs98pTeZqxiBKwx1epeK6 EFYDMF4yuVFR5ATxLzEQHfrTyx4SeIfe9yidO49lyWoSrTLDbvSDtm6LoxnjNIl2iW KY9XTX7RLTA7pARjCtiRW3TiLI2ar6lHjYzDpbLJ5GEDgUjdZW25RZvSXNPpIZCBFM PmRw4LBSgo5yL/E28HOAxNw+U9ntjSm2sQTakYB5BHS2f8UBkq1u4ehGv64HYYdPW8 j+JWP75oL2Fag== Cc: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:48:47 -0000 --089e015383e05267a204e192fc3e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've done quick research on this issue and it is real and I'm surprised it has not been more disruptive. MAC addresses have been assumed by many to be globally unique for a long time. Sorry if this has already been discussed somewhere, but it seems harsh to remove MAC-based CNAMEs entirely. They can be used safely in many environments and there at least two motivations for doing so. Can we demote MAC-based CNAMEs to NOT RECOMMENDED instead? There are other instances in the draft where we describe how previous recommendations were found to be lacking. How about we add something to the draft to explain why MAC-based CNAMEs are no longer permitted/recommended. I'm willing to help with this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Jul 15, 2013 at 11:26 AM, Ali C. Begen (abegen) w= rote: > MAC addresses are not unique anymore, so cannot be reliably used for cnam= e > generation. > > On Jul 15, 2013, at 10:10 AM, Kevin Gross wrote: > > > Yes, this is a significant change. It appears to imply that a > cryptographic PRNG is required in every RTP device and things will be mor= e > difficult for 3rd party network performance monitoring systems. > > > > Although there is discussion in the draft downplaying these issues, > there are RTP applications that won't otherwise require a CPRNG and there > are applications where ease of monitoring is more important than security= . > > > > What was the reason given for wanting to remove the MAC option? > > > > If we go with this, I suggest an editorial pass to reduce repetition in > the last two bullets in section 4.2 and clean up references to "multiple"= , > "several" as there are now only two methods recommended for generating > CNAMEs. Let me know if you need any help with this. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com, www.X192.org > > > > > > On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > WG, > > > > This document has just been in IESG review and the authors has discusse= d > > with the IESG. One discuss raised was the implications of the MAC based > > generation of short-term persistent CNAMES. The conclusion in that > > discussion was to remove that option and rely only on random names in > > that case. > > > > I wanted to inform the WG about this significant change and give you a > > chance to react to this change before the document is approved. You wil= l > > have one week to react. > > > > The details can be seen in this diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > > > > Cheers > > > > Magnus Westerlund > > > > > > On 2013-07-08 23:29, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Audio/Video Transport Core > Maintenance Working Group of the IETF. > > > > > > Title : Guidelines for Choosing RTP Control Protocol > (RTCP) Canonical Names (CNAMEs) > > > Author(s) : Ali Begen > > > Colin Perkins > > > Dan Wing > > > Eric Rescorla > > > Filename : draft-ietf-avtcore-6222bis-05.txt > > > Pages : 10 > > > Date : 2013-07-08 > > > > > > Abstract: > > > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > > > persistent transport-level identifier for an RTP endpoint. While > the > > > Synchronization Source (SSRC) identifier of an RTP endpoint may > > > change if a collision is detected or when the RTP application is > > > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > > > endpoints can be uniquely identified and associated with their RTP > > > media streams. > > > > > > For proper functionality, RTCP CNAMEs should be unique within the > > > participants of an RTP session. However, the existing guidelines > for > > > choosing the RTCP CNAME provided in the RTP standard are > insufficient > > > to achieve this uniqueness. RFC 6222 was published to update thos= e > > > guidelines to allow endpoints to choose unique RTCP CNAMEs. > > > Unfortunately, later investigations showed that some parts of the > new > > > algorithms were unnecessarily complicated and/or ineffective. Thi= s > > > document addresses these concerns and replaces RFC 6222. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-05 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Audio/Video Transport Core Maintenance > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > -- > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > --089e015383e05267a204e192fc3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've done quick research on this issue and it is real = and I'm surprised it has not been more disruptive. MAC addresses have b= een assumed by many to be globally unique for a long time.

Sorry if this has already been discussed somewhere, but it seems harsh to r= emove MAC-based CNAMEs entirely. They can be used safely in many environmen= ts and there at least two motivations for doing so. Can we demote MAC-based= CNAMEs to NOT RECOMMENDED instead?

There are other instances in the draft where we describ= e how previous recommendations were found to be lacking. How about we add s= omething to the draft to explain why MAC-based CNAMEs are no longer permitt= ed/recommended. I'm willing to help with this.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Netwo= rks -=A0www.AVAnw.com,=A0www.X192.org


On Mon, Jul 15, 2013 at 11:26 AM, Ali C.= Begen (abegen) <abegen@cisco.com> wrote:
MAC addresses are not unique anymore, so cannot be reliably used for cname = generation.

On Jul 15, 2013, at 10:10 AM, Kevin Gross <kevin.gross@avanw.com> wrote:

> Yes, this is a significant change. It appears to imply that a cryptogr= aphic PRNG is required in every RTP device and things will be more difficul= t for 3rd party network performance monitoring systems.
>
> Although there is discussion in the draft downplaying these issues, th= ere are RTP applications that won't otherwise require a CPRNG and there= are applications where ease of monitoring is more important than security.=
>
> What was the reason given for wanting to remove the MAC option?
>
> If we go with this, I suggest an editorial pass to reduce repetition i= n the last two bullets in section 4.2 and clean up references to "mult= iple", "several" as there are now only two methods recommend= ed for generating CNAMEs. Let me know if you need any help with this.
>
> Kevin Gross
> +1-303-447-05= 17
> Media Network Consultant
> AVA Networks - www.= AVAnw.com, www.X192.o= rg
>
>
> On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wr= ote:
> WG,
>
> This document has just been in IESG review and the authors has discuss= ed
> with the IESG. One discuss raised was the implications of the MAC base= d
> generation of short-term persistent CNAMES. The conclusion in that
> discussion was to remove that option and rely only on random names in<= br> > that case.
>
> I wanted to inform the WG about this significant change and give you a=
> chance to react to this change before the document is approved. You wi= ll
> have one week to react.
>
> The details can be seen in this diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtc= ore-6222bis-05
>
>
> Cheers
>
> Magnus Westerlund
>
>
> On 2013-07-08 23:29, inter= net-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > =A0This draft is a work item of the Audio/Video Transport Core Ma= intenance Working Group of the IETF.
> >
> > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Guidelines for Choosing R= TP Control Protocol (RTCP) Canonical Names (CNAMEs)
> > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ali Begen
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Colin Perkins=
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dan Wing
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla=
> > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-6222bis-= 05.txt
> > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 10
> > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-08
> >
> > Abstract:
> > =A0 =A0The RTP Control Protocol (RTCP) Canonical Name (CNAME) is = a
> > =A0 =A0persistent transport-level identifier for an RTP endpoint.= =A0While the
> > =A0 =A0Synchronization Source (SSRC) identifier of an RTP endpoin= t may
> > =A0 =A0change if a collision is detected or when the RTP applicat= ion is
> > =A0 =A0restarted, its RTCP CNAME is meant to stay unchanged, so t= hat RTP
> > =A0 =A0endpoints can be uniquely identified and associated with t= heir RTP
> > =A0 =A0media streams.
> >
> > =A0 =A0For proper functionality, RTCP CNAMEs should be unique wit= hin the
> > =A0 =A0participants of an RTP session. =A0However, the existing g= uidelines for
> > =A0 =A0choosing the RTCP CNAME provided in the RTP standard are i= nsufficient
> > =A0 =A0to achieve this uniqueness. =A0RFC 6222 was published to u= pdate those
> > =A0 =A0guidelines to allow endpoints to choose unique RTCP CNAMEs= .
> > =A0 =A0Unfortunately, later investigations showed that some parts= of the new
> > =A0 =A0algorithms were unnecessarily complicated and/or ineffecti= ve. =A0This
> > =A0 =A0document addresses these concerns and replaces RFC 6222. > >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-avtcor= e-6222bis
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis= -05
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -avtcore-6222bis-05
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


--089e015383e05267a204e192fc3e-- From csp@csperkins.org Mon Jul 15 14:04:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2B21E8176 for ; Mon, 15 Jul 2013 14:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.373 X-Spam-Level: X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXKgxfwC8qlN for ; Mon, 15 Jul 2013 14:04:43 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7F21E8186 for ; Mon, 15 Jul 2013 14:04:43 -0700 (PDT) Received: from [81.187.2.149] (port=37293 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uypwj-0008G8-Az; Mon, 15 Jul 2013 22:04:39 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D864B91C-3FF0-4211-BEE5-BB4799D51EDF" From: Colin Perkins In-Reply-To: Date: Mon, 15 Jul 2013 22:04:36 +0100 Message-Id: <77AD16BE-01CC-49ED-9892-029277C9C02B@csperkins.org> References: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> <51877C75.8040805@ericsson.com> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:04:48 -0000 --Apple-Mail=_D864B91C-3FF0-4211-BEE5-BB4799D51EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Kevin, Thank you so much for such a detailed review. I'm about to submit = draft-ietf-avtcore-rtp-security-options-04 which incorporates your = grammatical feedback, and makes numerous editorial changes to try to = address your comments below. Cheers, Colin On 30 Jun 2013, at 04:00, Kevin Gross wrote: > I've now read this draft. There were too many minor grammatical issues = to list individually so I edited the XML and have attached a copy. >=20 > The rest of the issues are general editorial and feedback on = readability from the perspective of someone trying to learn this stuff. = I hope this is useful to the authors. >=20 > General: There is no definitions section in the draft and there is a = lot of security terminology in the draft. Except where noted, I was able = to use Wikipedia to orient myself. >=20 > Section 2: What's the distinction, in this context, between "multicast = groups" and "broadcast topologies". >=20 > Section 3, paragraph 2: Wordy >=20 > Section 3.1, paragraph 2: Wordy >=20 > Section 3.1.1, paragraph 1: Add a ref for "TLS resumption" >=20 > Section 3.1.1, paragraph 3, lines 6-8: Unclear >=20 > Section 3.1.3, first paragraph, last sentence: "SSRC uniqueness = property" and its relation to this security issue requires elaboration >=20 > Section 3.1.5, second paragraph: Are any references available for = proprietary solutions mentioned >=20 > Section 3.2: Where does the recommendation not to use RFC 3550 Section = 9 come from? >=20 > Section 3.3, first paragraph: Unclear >=20 > Section 3.3, third paragraph: Does "central nodes" and "peers" refer = to the same entities? >=20 > Section 3.4, second paragraph: Unclear >=20 > Section 3.5, second paragraph: Are any references available for = proprietary solutions mentioned >=20 > Section 3.6, first paragraph: What are "RTP hint tracks"? >=20 > Section 4.1.1, Potential for other leakage: I don't understand how RTP = and RTCP headers are are visible to observers when RTP and RTCP packets = are wrapped in cryptographic containers. Are we talking about IPsec? = Wouldn't such wrapping include these headers? >=20 > Section 4.1.3, Base level, paragraph 2, second sentence: Incomplete = sentence/thought or otherwise unclear >=20 > Section 4.1.3, Using Identities, paragraph 4, first 2 sentences: = Unclear >=20 > Section 4.1.4, Certificate based, lines 6-10: Confusing, run-on = sentence >=20 > Section 5.2, Location disclosure: Add ref or definition for "ICE = negotiation" >=20 > Section 5.2, note at end of section: Unclear >=20 > Section 7: Does a security document require a security section? >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org >=20 >=20 > On Mon, May 6, 2013 at 3:48 AM, Magnus Westerlund = wrote: > WG, >=20 > (as individual contributor) >=20 > This update of the RTP security options has a number of improvements. >=20 > 1. It discusses known usage or inclusion in standard specs of = different > choices. >=20 > 2. It has two new examples, PSS and RTSP 2.0. >=20 > 3. A section on identity. >=20 > I think this is good enough for its purpose and would really = appreciate > some feedback on it. Both from people knowing security and people who > don't. >=20 > Cheers >=20 > Magnus Westerlund >=20 > On 2013-05-06 11:40, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. > > > > Title : Options for Securing RTP Sessions > > Author(s) : Magnus Westerlund > > Colin Perkins > > Filename : = draft-ietf-avtcore-rtp-security-options-03.txt > > Pages : 32 > > Date : 2013-05-06 > > > > Abstract: > > The Real-time Transport Protocol (RTP) is used in a large number = of > > different application domains and environments. This = heterogeneity > > implies that different security mechanisms are needed to provide > > services such as confidentiality, integrity and source = authentication > > of RTP/RTCP packets suitable for the various environments. The = range > > of solutions makes it difficult for RTP-based application = developers > > to pick the most suitable mechanism. This document provides an > > overview of a number of security solutions for RTP, and gives > > guidance for developers on how to choose the appropriate security > > mechanism. > > > > > > The IETF datatracker status page for this draft is: > > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options > > > > There's also a htmlized version available at: > > = http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 > > > > A diff from the previous version is available at: > > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options= -03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_D864B91C-3FF0-4211-BEE5-BB4799D51EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Kevin,

Thank you so much for such a detailed review. = I'm about to submit draft-ietf-avtcore-rtp-security-options-04 = which incorporates your grammatical feedback, and makes numerous = editorial changes to try to address your comments = below.

Cheers,
Colin



On 30 Jun 2013, at 04:00, Kevin = Gross wrote:
I've now = read this draft. There were too many minor grammatical issues to list = individually so I edited the XML and have attached a = copy.

The rest of the issues are general = editorial and feedback on readability from the perspective of someone = trying to learn this stuff. I hope this is useful to the authors.

General: There is no = definitions section in the draft and there is a lot of security = terminology in the draft. Except where noted, I was able to use = Wikipedia to orient myself.

Section 2: What's the distinction, in this = context, between "multicast groups" and "broadcast = topologies".

Section 3, = paragraph 2: Wordy

Section 3.1, paragraph 2: = Wordy

Section 3.1.1, = paragraph 1: Add a ref for "TLS resumption"

Section 3.1.1, paragraph 3, lines = 6-8: Unclear

Section 3.1.3, first = paragraph, last sentence: "SSRC uniqueness property" and its relation to = this security issue requires elaboration

Section 3.1.5, second paragraph: = Are any references available for proprietary solutions mentioned

Section 3.2: Where does the = recommendation not to use RFC 3550 Section 9 come from?

Section 3.3, first paragraph: = Unclear

Section 3.3, third paragraph: Does "central nodes" and "peers" refer to = the same entities?

Section 3.4, second paragraph: Unclear

Section 3.5, second paragraph: Are any references available for = proprietary solutions mentioned

Section 3.6, first paragraph: What are "RTP hint = tracks"?

Section 4.1.1, Potential for other leakage: I = don't understand how RTP and RTCP headers are are visible to observers = when RTP and RTCP packets are wrapped in cryptographic containers. Are = we talking about IPsec? Wouldn't such wrapping include these = headers?

Section 4.1.3, Base level, = paragraph 2, second sentence: Incomplete sentence/thought or otherwise = unclear

Section 4.1.3, = Using Identities, paragraph 4, first 2 sentences: Unclear

Section 4.1.4, Certificate = based, lines 6-10: Confusing, run-on sentence

Section 5.2, Location disclosure: = Add ref or definition for "ICE negotiation"

Section 5.2, note at end of = section: Unclear

Section = 7: Does a security document require a security section?

Kevin Gross
+1-303-447-0517
Media Network = Consultant
AVA Networks - www.AVAnw.com, www.X192.org


On Mon, May 6, 2013 at 3:48 AM, = Magnus Westerlund <magnus.westerlund@ericsson.com> = wrote:
WG,

(as individual contributor)

This update of the RTP security options has a number of = improvements.

1. It discusses known usage or inclusion in standard specs of = different
choices.

2. It has two new examples, PSS and RTSP 2.0.

3. A section on identity.

I think this is good enough for its purpose and would really = appreciate
some feedback on it. Both from people knowing security and people = who
don't.

Cheers

Magnus Westerlund

On 2013-05-06 11:40, internet-drafts@ietf.org = wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
>  This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF.
>
>       Title           : = Options for Securing RTP Sessions
>       Author(s)       : Magnus = Westerlund
>                   =         Colin Perkins
>       Filename        : = draft-ietf-avtcore-rtp-security-options-03.txt
>       Pages           : = 32
>       Date           =  : 2013-05-06
>
> Abstract:
>    The Real-time Transport Protocol (RTP) is used in a = large number of
>    different application domains and environments. =  This heterogeneity
>    implies that different security mechanisms are needed = to provide
>    services such as confidentiality, integrity and source = authentication
>    of RTP/RTCP packets suitable for the various = environments.  The range
>    of solutions makes it difficult for RTP-based = application developers
>    to pick the most suitable mechanism.  This = document provides an
>    overview of a number of security solutions for RTP, = and gives
>    guidance for developers on how to choose the = appropriate security
>    mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-= security-options
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtcore-rtp-securi= ty-options-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rt= p-security-options-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


--

Magnus Westerlund

= ----------------------------------------------------------------------
= Multimedia Technologies, Ericsson Research EAB/TVM
= ----------------------------------------------------------------------
= Ericsson AB                | = Phone  +46 10 7148287
F=E4r=F6gatan 6                | = Mobile +46 = 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.= com
= ----------------------------------------------------------------------
=

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

= <draft-ietf-avtcore-rtp-security-options-03-kg.xml>



-- 
Colin Perkins



= --Apple-Mail=_D864B91C-3FF0-4211-BEE5-BB4799D51EDF-- From internet-drafts@ietf.org Mon Jul 15 14:06:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9521E816C; Mon, 15 Jul 2013 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-W7Tsf0ipWE; Mon, 15 Jul 2013 14:06:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B821E818A; Mon, 15 Jul 2013 14:06:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715210622.23973.22493.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:06:22 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:06:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-04.txt Pages : 32 Date : 2013-07-15 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Tue Jul 16 07:58:33 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55521F9B8C; Tue, 16 Jul 2013 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsNPlcex7ima; Tue, 16 Jul 2013 07:58:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14CA21F84D1; Tue, 16 Jul 2013 07:58:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEwPhL020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:58:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEwP2U023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:58:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:58:25 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrA Date: Tue, 16 Jul 2013 14:58:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [AVTCORE] FW: Taxonomy X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:58:33 -0000 Extensive cross-post do not reply to this email. For information. We do expect participation input from all the listed worki= ng groups (and possibly more). Keith -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: 16 July 2013 15:53 To: avtext@ietf.org Subject: [avtext] Taxonomy (As AVTEXT WG cochair) The latest version of the RTP taxonomy draft has been submitted. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by DISPATCH, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant meeting time discussing the contents= in the AVTEXT meeting in Berlin, so please start raising your issues on th= e AVTEXT list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Jul 17 04:07:01 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C366921F9948; Wed, 17 Jul 2013 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7BkwHXD8h6U; Wed, 17 Jul 2013 04:06:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF521F9D4A; Wed, 17 Jul 2013 04:06:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6HB6nwZ009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:06:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HB6lVR032483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:06:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:06:48 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARA= Date: Wed, 17 Jul 2013 11:06:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [AVTCORE] Taxonomy X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:07:02 -0000 Breaking my own rule about cross posting... Just wanted to add is that this document would not be retrospective, i.e. w= e would not start rewriting the existing published RFCs to take into accoun= t the new terminology. The expectation however is that documents going forward from other working = groups would use the new terminology rather than other terms.=20 Obviously how this is handled is up to the individual working groups, but u= sing the new terminology will be the only good way of making your results u= nderstandable outside your specific field. So that is why your review and input is important. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 16 July 2013 15:58 > To: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; > avt@ietf.org > Subject: FW: Taxonomy >=20 > Extensive cross-post do not reply to this email. >=20 > For information. We do expect participation input from all the listed > working groups (and possibly more). >=20 > Keith >=20 > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 15:53 > To: avtext@ietf.org > Subject: [avtext] Taxonomy >=20 > (As AVTEXT WG cochair) >=20 > The latest version of the RTP taxonomy draft has been submitted. >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping- > taxonomy/ >=20 > This document was allocated to AVTEXT by DISPATCH, and we have created a > milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant meeting time discussing the > contents in the AVTEXT meeting in Berlin, so please start raising your > issues on the AVTEXT list. >=20 > Additionally, if there are counter proposals existing that the AVTEXT > chairs would not otherwise be aware of, then please identify them to the > AVTEXT chairs / list. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From iesg-secretary@ietf.org Wed Jul 17 10:57:10 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5BC21E8084; Wed, 17 Jul 2013 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqqH0XchwlJX; Wed, 17 Jul 2013 10:57:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE73221E8085; Wed, 17 Jul 2013 10:57:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130717175708.29035.94141.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 10:57:08 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' to Proposed Standard (draft-ietf-avtcore-6222bis-06.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:57:10 -0000 The IESG has approved the following document: - 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' (draft-ietf-avtcore-6222bis-06.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ Technical Summary The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. Working Group Summary The requirements for this replacement of RFC 6222 came from RTCWEB WG, which identified the linkability and privacy issue of the previous random method. There was strong WG consensus to address this issue. The method of addressing it, using a cryptographic random number generator, was obvious. The main concern in WG last call has been around the clarity of the motivation for the update. Document Quality The Shepherd assumes that this will see significant implementation, especially initially in any WebRTC implementations. The document has gotten a fair amount of reviews in the WG last call. Personnel Magnus Westerlund is the Document Shepherd. Richard Barnes is the Responsible Area Director. From ibc@aliax.net Wed Jul 17 04:27:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1E21F9D92 for ; Wed, 17 Jul 2013 04:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dltejGltPGM7 for ; Wed, 17 Jul 2013 04:27:13 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 96CAC21F9DBE for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bn16so2908161qab.12 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EKaU4MI2ZQsAWPvMCk3JxHj6BeoOuRCIjkCYNQ+jx9I=; b=LIwOIdxGSs5u/F/wptrjw51TS9Qy0aQT9zoa/6LtfDwKXSWKrmkzix2ekJ0hxQbmvA Fkvj+Tpp5vkA2hpQKn6rvX9JmRZS8C7TjpiT+CtatcybjpRu9fnAMagZKsANXFvP6r9C OSjZteJPQH4VueICUCi7WqbhucqVPN1c2ulyoaiAOfMbtZ1zJaybD6RopFIAG4HP87pq Pa1I/Bwp5jvXKgVC/Y0DpeTa9m1NoCW3NFLHpUE0ZkT6H/9tEEAJwZ3/b3eeIXrdtvTh E1jau0++sJlII+Ab0XAzjRVYd1K/9jYQyOSiG9xND30mbQePa5K2RB4qPndT16o13NUE RHCQ== X-Received: by 10.224.90.1 with SMTP id g1mr8708293qam.0.1374060427977; Wed, 17 Jul 2013 04:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 17 Jul 2013 04:26:47 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 13:26:47 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlCIkGmyYz5rlpK8WA42r449TmZT7OlUcsroGydf2ASjd7DJvqH6ujZj5TV5u69lU0awsx8 X-Mailman-Approved-At: Wed, 17 Jul 2013 11:10:37 -0700 Cc: "clue@ietf.org" , "dispatch@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] [dispatch] Taxonomy X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:27:13 -0000 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Wed Jul 17 17:44:57 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243E421F9CB1 for ; Wed, 17 Jul 2013 17:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUGSwBfq5Ksw for ; Wed, 17 Jul 2013 17:44:51 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4A03721F9C86 for ; Wed, 17 Jul 2013 17:44:48 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6I0ijQc000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jul 2013 19:44:46 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6I0ii1c024709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 02:44:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 02:44:44 +0200 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Thread-Topic: Agenda for IETF87 - Berlin Thread-Index: Ac6DT/4AvkJySzKQRs2xbvd4z8YEgA== Date: Thu, 18 Jul 2013 00:44:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06C2A8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [AVTCORE] Agenda for IETF87 - Berlin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 00:44:57 -0000 I have just posted the initial agenda for Berlin at https://datatracker.ietf.org/meeting/87/agenda/avtext/ Comments welcome. Note that the intent of the penultimate agenda item is not to duplicate the= MMUSIC discussion - but rather to reflect the impact on AVTEXT of the MMUS= IC discussions. Regards Keith From keith.drage@alcatel-lucent.com Thu Jul 18 04:23:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25221F8C71 for ; Thu, 18 Jul 2013 04:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKo5-pwljCLp for ; Thu, 18 Jul 2013 04:23:38 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7721F842B for ; Thu, 18 Jul 2013 04:23:22 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6IBNJon016275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Jul 2013 06:23:21 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6IBNJYl025613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 13:23:19 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 13:23:19 +0200 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Thread-Topic: Agenda for IETF87 - Berlin Thread-Index: Ac6DT/4AvkJySzKQRs2xbvd4z8YEgAAWSDjg Date: Thu, 18 Jul 2013 11:23:19 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06C66E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06C2A8@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06C2A8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [AVTCORE] Agenda for IETF87 - Berlin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 11:23:43 -0000 Wrong mailing list - mouse problems > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: 18 July 2013 01:45 > To: avt@ietf.org > Subject: [AVTCORE] Agenda for IETF87 - Berlin >=20 > I have just posted the initial agenda for Berlin at >=20 > https://datatracker.ietf.org/meeting/87/agenda/avtext/ >=20 > Comments welcome. >=20 > Note that the intent of the penultimate agenda item is not to duplicate > the MMUSIC discussion - but rather to reflect the impact on AVTEXT of the > MMUSIC discussions. >=20 > Regards >=20 > Keith > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ron.even.tlv@gmail.com Thu Jul 18 06:54:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1911E8146; Thu, 18 Jul 2013 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcxrea7hAxys; Thu, 18 Jul 2013 06:54:43 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1EB11E814B; Thu, 18 Jul 2013 06:54:39 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so6674771wiv.2 for ; Thu, 18 Jul 2013 06:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=BmMv3sJHFEtC2IOe/mUJ3EBblimAT9bdF+9iFwZNyEM=; b=kdjeolUmlW6fZPvPtjBKyHUG7izArn0qdBtLdazbFW/w7edNwdXz5x6MGG2jR/Ybtb XK1PcXTvpvCSwyLHJHi6SSnjeU1ftrQ00pLNeciMonG2ZwmScvqOGG/CeSo8DD4HvpXo iubVlikgW6mQNmKBGRsCLrX09T9w1DIU1jHgRl3gh3/I78CORw93Na2tCxOmr1Y2VpY5 cqLJ+CI+vG9a0KxgTHH4+u6JvFlh5TUjNViSTFFXbdf2NFCn22xKGLe4WgPhDxigTZHs Vse+77/6wq6lT471bujQsSx15pMPByctcrNXilq/pzIQhbW6QZW++CITF5jctUdkojM/ HfVw== X-Received: by 10.180.36.107 with SMTP id p11mr8279985wij.31.1374155678309; Thu, 18 Jul 2013 06:54:38 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fs8sm42137895wib.0.2013.07.18.06.54.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Jul 2013 06:54:37 -0700 (PDT) From: "Roni Even" To: Date: Thu, 18 Jul 2013 16:52:49 +0300 Message-ID: <02cc01ce83be$18770040$496500c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02CD_01CE83D7.3DC48660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6DvcjZVgjnzbluS1OU6/8RBOibkg== Content-Language: en-us Cc: payload@ietf.org Subject: [AVTCORE] IETF87 Berin agenda - AVTcore X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:54:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CD_01CE83D7.3DC48660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02CE_01CE83D7.3DC48660" ------=_NextPart_001_02CE_01CE83D7.3DC48660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Attached is the agenda (txt and HTML version), note that we have allocated time for h.265 payload specification which is a payload WG document Roni ------=_NextPart_001_02CE_01CE83D7.3DC48660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Attached is the = agenda (txt and HTML version), note that we have allocated time for = h.265 payload specification which is a payload WG = document

Roni

------=_NextPart_001_02CE_01CE83D7.3DC48660-- ------=_NextPart_000_02CD_01CE83D7.3DC48660 Content-Type: text/plain; name="a13072.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a13072.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Wednesday, 31 July 2013 at 9:00-11:30 (Bellevue ) -------------------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 Multiplex guidelines (Colin Perkins , 10) draft-ietf-avtcore-multiplex-guidelines-01 09:30 Support of mutiple RTP streams (Jonathan Lennox , 25) draft-ietf-avtcore-multi-media-rtp-session-03 draft-ietf-avtcore-rtp-multi-stream-01 draft-ietf-avtcore-rtp-multi-stream-optimisation-00 09:55 Circuit Breakers for Unicast Sessions (Colin Perkins , 25) draft-ietf-avtcore-rtp-circuit-breakers-03 10:20 RTP Clock Source Signalling (Aidan Williams, 15) draft-ietf-avtcore-clksrc-05 10:35 RTP Payload Format for High Efficiency Video Coding(Ye-kui Wang, 15) 10:50 End ------=_NextPart_000_02CD_01CE83D7.3DC48660 Content-Type: text/html; name="agenda.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="agenda.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Wednesday, 31 July 2013 at 9:00-11:30 (Bellevue )

09:00 AVTCore Status UpdateChairs
09:20 Multiplex guidelinesColin Perkins=20
draft-ietf-avtcore-multiplex-guidelines-01
09:30 Support of mutiple RTP streamsJonathan Lennox=20
draft-ietf-avtcore-multi-media-rtp-session-03
= draft-ietf-avtcore-rtp-multi-stream-01
draft-ietf-avtcore-rtp-multi-stream-optimisation-00
09:55 Circuit Breakers for Unicast SessionsColin Perkins=20
draft-ietf-avtcore-rtp-circuit-breakers-03
10:20 RTP Clock Source SignallingAidan = Williams
draft-ietf= -avtcore-clksrc-05
10:35 RTP Payload Format for High Efficiency Video = CodingYe-kui Wang
10:50 End
------=_NextPart_000_02CD_01CE83D7.3DC48660-- From csp@csperkins.org Thu Jul 18 08:20:05 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D221E8118 for ; Thu, 18 Jul 2013 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRiXcVhhKVoB for ; Thu, 18 Jul 2013 08:20:01 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6221E811B for ; Thu, 18 Jul 2013 08:19:56 -0700 (PDT) Received: from [130.209.247.112] (port=59229 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uzpzk-0007rk-7H for avt@ietf.org; Thu, 18 Jul 2013 16:19:55 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130715185534.31264.26535.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 16:19:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15912DF9-1145-4099-9F00-BC1436859D6A@csperkins.org> References: <20130715185534.31264.26535.idtracker@ietfa.amsl.com> To: avt@ietf.org X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:20:06 -0000 This is a relatively minor update, based on comments received during the = last meeting. Changes include: - In Section 4.3, reorder the text to be clearer that the sender is = allowed to reduce it's sending rate by a factor of ten when the = congestion circuit breaker fires, to see if this resolves the problem, = before it has to cease transmission. - In Section 4.2 and Section 4.3, add some text about sessions with a = large enough number of media streams that the receivers has to generate = round-robin RTCP reception reports. - In Section 4.3, clarify what RTCP reporting interval is used to = trigger the circuit breaker - Add Section 7 on the Impact of RTCP Reporting Groups. There are also some minor editorial fixes. Colin On 15 Jul 2013, at 19:55, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Multimedia Congestion Control: Circuit = Breakers for Unicast RTP Sessions > Author(s) : Colin Perkins > Varun Singh > Filename : draft-ietf-avtcore-rtp-circuit-breakers-03.txt > Pages : 17 > Date : 2013-07-15 >=20 > Abstract: > The Real-time Transport Protocol (RTP) is widely used in telephony, > video conferencing, and telepresence applications. Such = applications > are often run on best-effort UDP/IP networks. If congestion control > is not implemented in the applications, then network congestion will > deteriorate the user's multimedia experience. This document does = not > propose a congestion control algorithm; instead, it defines a = minimal > set of RTP "circuit-breakers". Circuit-breakers are conditions = under > which an RTP sender needs to stop transmitting media data in order = to > protect the network from excessive congestion. It is expected that, > in the absence of severe congestion, all RTP applications running on > best-effort IP networks will be able to run without triggering these > circuit breakers. Any future RTP congestion control specification > will be expected to operate within the constraints defined by these > circuit breakers. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-circuit-breakers= -03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Thu Jul 18 08:32:14 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F611E815B for ; Thu, 18 Jul 2013 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFOArNGH1LCE for ; Thu, 18 Jul 2013 08:32:05 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD611E8156 for ; Thu, 18 Jul 2013 08:31:56 -0700 (PDT) Received: from [130.209.247.112] (port=59312 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzqBK-0003h3-Kt for avt@ietf.org; Thu, 18 Jul 2013 16:31:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130711110039.10104.13956.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 16:31:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AEA448C-D9E6-4DE4-A513-461B8E619EDF@csperkins.org> References: <20130711110039.10104.13956.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:32:14 -0000 The changes in this version are to extract the contents of Section 6.4, = which have now moved into draft-ietf-avtcore-rtp-multi-stream-01. Colin On 11 Jul 2013, at 12:00, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Sending Multiple Types of Media in a Single = RTP Session > Author(s) : Magnus Westerlund > Colin Perkins > Jonathan Lennox > Filename : = draft-ietf-avtcore-multi-media-rtp-session-03.txt > Pages : 18 > Date : 2013-07-11 >=20 > Abstract: > This document specifies how an RTP session can contain media streams > with media from multiple media types such as audio, video, and text. > This has been restricted by the RTP Specification, and thus this > document updates RFC 3550 and RFC 3551 to enable this behaviour for > applications that satisfy the applicability for using multiple media > types in a single RTP session. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-sessio= n >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multi-media-rtp-sess= ion-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Thu Jul 18 08:46:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520711E815C for ; Thu, 18 Jul 2013 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUiJWq2YXdu9 for ; Thu, 18 Jul 2013 08:46:31 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20711E8162 for ; Thu, 18 Jul 2013 08:46:31 -0700 (PDT) Received: from [130.209.247.112] (port=59496 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzqPQ-0005Sw-T5 for avt@ietf.org; Thu, 18 Jul 2013 16:46:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130711110428.10126.2775.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 16:46:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <545237B2-3EC0-4430-88F3-67849678403F@csperkins.org> References: <20130711110428.10126.2775.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:46:35 -0000 The main changes in this version are to expand the section on RTCP = Considerations for Streams with Disparate Rates by moving text on this = topic from draft-ietf-avtcore-multi-media-rtp-session; and to move the = section about Grouping of RTCP Reception Statistics and Other Feedback = into a separate draft, = draft-ietf-avtcore-rtp-multi-stream-optimisation-00, since it contains = RTCP extensions rather than just clarifications to RFC3550. Colin On 11 Jul 2013, at 12:04, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Sending Multiple Media Streams in a Single RTP = Session > Author(s) : Jonathan Lennox > Magnus Westerlund > Qin Wu > Colin Perkins > Filename : draft-ietf-avtcore-rtp-multi-stream-01.txt > Pages : 16 > Date : 2013-07-11 >=20 > Abstract: > This document expands and clarifies the behavior of the Real-Time > Transport Protocol (RTP) endpoints when they are sending multiple > media streams in a single RTP session. In particular, issues > involving Real-Time Transport Control Protocol (RTCP) messages are > described. >=20 > This document updates RFC 3550 in regards to handling of multiple > SSRCs per endpoint in RTP sessions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-multi-stream-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Thu Jul 18 08:56:24 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925B211E8175 for ; Thu, 18 Jul 2013 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8WzY50xmjWY for ; Thu, 18 Jul 2013 08:56:10 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC411E816E for ; Thu, 18 Jul 2013 08:56:08 -0700 (PDT) Received: from [130.209.247.112] (port=59865 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzqYm-0000zL-EO for avt@ietf.org; Thu, 18 Jul 2013 16:56:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130715115202.7033.83195.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 16:56:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3007B5F1-15FE-42EA-B826-204DFC43A643@csperkins.org> References: <20130715115202.7033.83195.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:56:25 -0000 This draft contains the text on Grouping of RTCP Reception Statistics = and Other Feedback that was moved from = draft-ietf-avtcore-rtp-multi-stream-01. Colin On 15 Jul 2013, at 12:52, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Sending Multiple Media Streams in a Single RTP = Session: Grouping RTCP Reception Statistics and Other Feedback > Author(s) : Jonathan Lennox > Magnus Westerlund > Qin Wu > Colin Perkins > Filename : = draft-ietf-avtcore-rtp-multi-stream-optimisation-00.txt > Pages : 10 > Date : 2013-07-11 >=20 > Abstract: > RTP allows multiple media streams to be sent in a single session, = but > requires each Synchronisation Source (SSRC) to send RTCP reception > quality reports for every other SSRC visible in the session. This > causes the number of RTCP reception reports to grow with the number > of SSRCs, rather than the number of endpoints. In many cases most = of > these RTCP reception reports are unnecessary, since all SSRCs of an > endpoint are co-located and see the same reception quality. This > memo defines a Reporting Group extension to RTCP to reduce the > reporting overhead in such scenarios. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optim= isation >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisatio= n-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Thu Jul 18 09:54:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9411E8197 for ; Thu, 18 Jul 2013 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUXdAzVvbDKq for ; Thu, 18 Jul 2013 09:54:24 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2511E819D for ; Thu, 18 Jul 2013 09:54:16 -0700 (PDT) Received: from [130.209.247.112] (port=60461 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzrT5-0004O0-Pd for avt@ietf.org; Thu, 18 Jul 2013 17:54:16 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130715184505.9072.24782.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 17:54:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7532A7CC-6323-4B18-A0EA-7031DC36CE8F@csperkins.org> References: <20130715184505.9072.24782.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:54:29 -0000 The changes in this version are a significant rewrite of Sections 3 and = 4, along with more minor editorial fixes to the rest of the draft. In = addition, Appendix C is removed, since it duplicates the contents of = draft-ietf-avtcore-rtp-multi-stream. Colin On 15 Jul 2013, at 19:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Guidelines for using the Multiplexing Features = of RTP to Support Multiple Media Streams > Author(s) : Magnus Westerlund > Bo Burman > Colin Perkins > Harald Tveit Alvestrand > Filename : draft-ietf-avtcore-multiplex-guidelines-01.txt > Pages : 46 > Date : 2013-07-15 >=20 > Abstract: > The Real-time Transport Protocol (RTP) is a flexible protocol that > can be used in a wide range of applications, networks, and system > topologies. That flexibility makes for wide applicability, but can > complicate the application design process. One particular design > question that has received much attention is how to support multiple > media streams in RTP. This memo discusses the available options and > design trade-offs, and provides guidelines on how to use the > multiplexing features of RTP to support multiple media streams. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multiplex-guidelines= -01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Mon Jul 29 01:43:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13921F92C2; Mon, 29 Jul 2013 01:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.5 X-Spam-Level: X-Spam-Status: No, score=-98.5 tagged_above=-999 required=5 tests=[AWL=-3.876, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYGIX6rS4XhB; Mon, 29 Jul 2013 01:43:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF1A21F9E52; Mon, 29 Jul 2013 01:43:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729084350.25184.22437.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 01:43:50 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:43:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-12.txt Pages : 22 Date : 2013-07-29 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-12 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 ray.vanbrandenburg@tno.nl Mon Jul 29 01:49:03 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E418321F90FD for ; Mon, 29 Jul 2013 01:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.088 X-Spam-Level: **** X-Spam-Status: No, score=4.088 tagged_above=-999 required=5 tests=[AWL=-3.384, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehOFjjGkkcCU for ; Mon, 29 Jul 2013 01:48:59 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id B4E8821F918F for ; Mon, 29 Jul 2013 01:48:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,768,1367964000"; d="scan'208";a="11856530" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 29 Jul 2013 10:48:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Mon, 29 Jul 2013 10:48:30 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" , Martin Thomson , Roni Even Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt Thread-Index: AQHOjDftiZdFqe4/jEmTIRU5lnJxVJl7WFzb Date: Mon, 29 Jul 2013 08:48:29 +0000 Message-ID: References: <20130729084350.25184.22437.idtracker@ietfa.amsl.com> In-Reply-To: <20130729084350.25184.22437.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:49:04 -0000 Hi, This version of the draft includes the final comments received during IETF = LC and from Martin Thomson as Appsdir reviewer. = Best regards, Ray On 29 jul. 2013, at 10:45, "internet-drafts@ietf.org" wrote: > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Core Maintenance W= orking Group of the IETF. > = > Title : Inter-destination Media Synchronization using the RT= P Control Protocol (RTCP) > Author(s) : Ray van Brandenburg > Hans Stokking > Oskar van Deventer > Fernando Boronat > Mario Montagud > Kevin Gross > Filename : draft-ietf-avtcore-idms-12.txt > Pages : 22 > Date : 2013-07-29 > = > Abstract: > This document defines a new RTP Control Protocol (RTCP) Packet Type > and an RTCP Extended Report (XR) Block Type to be used for achieving > Inter-Destination Media Synchronization (IDMS). IDMS is the process > of synchronizing playout across multiple geographically distributed > media receivers. Using the RTCP XR IDMS Report Block defined in this > document, media playout information from participants in a > synchronization group can be collected. Based on the collected > information, an RTCP IDMS Settings Packet can then be sent to > distribute a common target playout point to which all the distributed > receivers, sharing a media experience, can synchronize. > = > Typical use cases in which IDMS is useful are social TV, shared > service control (i.e. applications where two or more geographically > separated users are watching a media stream together), distance > learning, networked video walls, networked loudspeakers, etc. > = > = > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms > = > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-idms-12 > = > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-12 > = > = > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From fluffy@cisco.com Wed Jul 31 01:42:30 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D121F9E68 for ; Wed, 31 Jul 2013 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7m4AsXCgTGm for ; Wed, 31 Jul 2013 01:42:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC921F8E2A for ; Wed, 31 Jul 2013 01:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=431; q=dns/txt; s=iport; t=1375259691; x=1376469291; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KkWHjtdYMvvL29vArkwUsJfh1G0OjRrj5MkKL8f0jeo=; b=hAbz7pjkT0sVPNj8qxFioDuF1lkYiK+CMNmpY6knsWbVl9pTnq4GGdwW +ebojKyOJtCdeYmJbk7ewVczhZsQdimx76pQ/wnJI3VatQvwYKxYtZP1s 52YnoOQDStCzQIQsYRPLooM1ak/aIgUf09Kt1avvj4BLLDZD45lDOHSxX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFvK+FGtJV2Y/2dsb2JhbABbgwaBBb4cgRgWdIImAQQ6PxIBKhRCJwQODYgIuFqPTTGDH3EDqSuDFIIq X-IronPort-AV: E=Sophos;i="4.89,785,1367971200"; d="scan'208";a="241748963" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 08:32:58 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6V8WwS2000590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 08:32:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 03:32:58 -0500 From: "Cullen Jennings (fluffy)" To: "avt@ietf.org" Thread-Topic: DSCP and draft-ietf-avtcore-multiplex-guidelines Thread-Index: AQHOjciPmV/rY9uyQEKe5EPEi8StQA== Date: Wed, 31 Jul 2013 08:32:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.177] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C416E56ABAD2A40897F570AA56FA9B2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Colin Perkins Subject: [AVTCORE] DSCP and draft-ietf-avtcore-multiplex-guidelines X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:42:33 -0000 There was discussion in TSVWG about DSCP and bundle. After this, it seems i= t would be good if the draft-ietf-avtcore-multiplex-guidelines draft said t= hat if there are packets being sent with different DSCP on the same UDP 5 t= uple, they MUST manage the congestion control independently as they may be = flowing over different paths.=20 Probably worth checking the minutes of the AVTWG meeting when they come out= . From finlayson@live555.com Wed Jul 31 11:19:05 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31411E81A6 for ; Wed, 31 Jul 2013 11:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUfcwYRv7D1P for ; Wed, 31 Jul 2013 11:19:00 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id B7FFC11E81B3 for ; Wed, 31 Jul 2013 11:18:59 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r6VIIuRl083580 for ; Wed, 31 Jul 2013 11:18:57 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_C1B75B98-4F87-4D2D-9D71-C14A5C50B1BD" Message-Id: Date: Wed, 31 Jul 2013 20:18:56 +0200 To: avt@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [AVTCORE] Clarifying the H.264 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:19:05 -0000 --Apple-Mail=_C1B75B98-4F87-4D2D-9D71-C14A5C50B1BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As I noted in Wednesday morning's AVTCORE session, the proposed H.265 = RTP payload format specification is not as clear as it could be about = how a RTP sender knows when to set the "M" bit on an outgoing RTP = packet. Currently, the text says: Marker bit (M): 1 bit Set for the last packet of the access unit indicated by the RTP timestamp, in line with the normal use of the M bit in video formats, to allow an efficient playout buffer handling. Decoders can use this bit as an early indication of the last packet of an access unit. There is nothing inherently wrong with this. However (because we're not = in the MPEG world here :-) it's not sufficient to fully specify only how = the receivers of RTP packets should behave; we should also try to = specify, as clearly as possible, how the *senders* of RTP packets should = behave. We should try to give at least some guidance about when the NAL = unit that's being sent ends an "access unit" because - for many = implementations - it is not immediately obvious. If I were amending the H.264 payload format specification - which of = course I'm not - then I would, hypothetically, add a paragraph something = like the following: ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP = sender implementation whether or not the NAL unit ends an access unit. = Instead, the implementation can obtain this information separately, from = the encoder. If, however, this information is not directly available = from the encoder (e.g., because the implementation is sending data that = consists solely of a sequence of pre-encoded NAL units), then it must = instead inspect the next NAL unit, to determine whether or not the = current NAL unit ends an access unit. The following rule can be used: The current NAL unit ends an access unit if it is a VCL NAL unit = (i.e., if its "nal_unit_type" is in the range [1..5]), and if either: - the next NAL unit is not a VCL NAL unit, or - either the current NAL unit's "nal_unit_type" or the next NAL = unit's "nal_unit_type" - but not both - is 5 (i.e., "Coded slice of an = IDR picture"), or - the next NAL unit's "nal_ref_idc" field differs from the = current NAL unit's "nal_ref_idc" field, with one of them being equal to = zero, or - both the current and next NAL units begin with slice headers, = and their "frame_num" fields differ, or - both the current and next NAL units begin with slice headers, = and their "pic_parameter_set_id" fields differ, or - both the current and next NAL units begin with slice headers, = and their "field_pic_flag" fields differ, or - both the current and next NAL units begin with slice headers, = and their "bottom_field_flag" fields differ, or - both the current and next NAL units' "nal_ref_idc" field is 5, = and the "idr_pic_id" fields differ. ---------- (I derived this rule from Section 7.4.1.2.4 - "Detection of the first = VCL NAL unit of a primary coded picture" - of the H.264 specification. = Perhaps it could be simplified?) I suggest that an analogous paragraph be added to the H.265 RTP payload = format specification. (Or alternatively, instead of writing a detailed = rule like this, perhaps a reference to an appropriate part of the H.265 = specification might be made instead (can we do this in a IETF RFC?).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_C1B75B98-4F87-4D2D-9D71-C14A5C50B1BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As I = noted in Wednesday morning's AVTCORE session, the proposed H.265 RTP = payload format specification is not as clear as it could be about how a = RTP sender knows when to set the "M" bit on an outgoing RTP = packet.


Currently, the text = says:

   Marker bit (M): 1 = bit

      Set for the last = packet of the access unit indicated by the RTP
    =   timestamp, in line with the normal use of the M bit in = video
      formats, to allow an efficient = playout buffer handling.  Decoders
      = can use this bit as an early indication of the last packet of = an
      access = unit.

There is nothing inherently wrong = with this.  However (because we're not in the MPEG world here :-) = it's not sufficient to fully specify only how the receivers of RTP = packets should behave; we should also try to specify, as clearly as = possible, how the *senders* of RTP packets should behave.  We = should try to give at least some guidance about when the NAL unit that's = being sent ends an "access unit" because - for many implementations = - it is not immediately obvious.

If I were = amending the H.264 payload format specification - which of course I'm = not - then I would, hypothetically, add a paragraph something like the = following:

----------
Unfortunately = the contents of a NAL unit, alone, does not tell a RTP sender = implementation whether or not the NAL unit ends an access unit. =  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not = directly available from the encoder (e.g., because the implementation is = sending data that consists solely of a sequence of pre-encoded NAL = units), then it must instead inspect the next NAL unit, to determine = whether or not the current NAL unit ends an access unit.  The = following rule can be used:
    The current NAL unit = ends an access unit if it is a VCL NAL unit (i.e., if its = "nal_unit_type" is in the range [1..5]), and if either:
- the = next NAL unit is not a VCL NAL unit, or
- either = the current NAL unit's "nal_unit_type" or the next NAL = unit's "nal_unit_type" - but not both - is 5 (i.e., "Coded slice of = an IDR picture"), or
- the next NAL unit's = "nal_ref_idc" field differs from the current NAL = unit's "nal_ref_idc" field, with one of them being equal to zero, = or
= - both the current and next NAL units begin with slice headers, = and their "frame_num" fields differ, or
- both = the current and next NAL units begin with slice headers, = and their "pic_parameter_set_id" fields differ, = or
= - both the current and next NAL units' "nal_ref_idc" field is 5, = and the "idr_pic_id" fields = differ.
----------

(I derived this = rule from Section 7.4.1.2.4 - "Detection of the first VCL NAL unit = of a primary coded picture" - of the H.264 specification.  Perhaps = it could be simplified?)

I suggest that an = analogous paragraph be added to the H.265 RTP payload format = specification.  (Or alternatively, instead of writing a detailed = rule like this, perhaps a reference to an appropriate part of the H.265 = specification might be made instead (can we do this in a IETF = RFC?).)

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_C1B75B98-4F87-4D2D-9D71-C14A5C50B1BD-- From mzanaty@cisco.com Wed Jul 31 16:58:37 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CCE11E80E2; Wed, 31 Jul 2013 16:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4mXpUnOWnZP; Wed, 31 Jul 2013 16:58:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A88AF21F99A9; Wed, 31 Jul 2013 16:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19170; q=dns/txt; s=iport; t=1375315104; x=1376524704; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7JIuxYoqp7rsDFCvKAgZVXeFWnu0pN210KoennfGuNA=; b=fKj8ykvLiTxzygSv04mmmUegqrQcBKGwg46uQX5mmmXPn3Py159N8JJ0 sJnSggwn5edY1rc733Wi4orC9wlg8keSbATs9AbPljpMI7hqiljclzavD aaYUE0UNgr7pjc+u8aB9AeNFaYTAxmhAtClzDx1wxGUXEp23sP+RcP0zt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAOCj+VGtJXG+/2dsb2JhbABbgkJENVC9K4EJgRwWdIIkAQEBBC1cAgEIEQQBAQsZBAcyFAkIAgQBEgiICLklj1Y3AYMYcwOpLIFbgTmCKg X-IronPort-AV: E=Sophos;i="4.89,790,1367971200"; d="scan'208,217";a="242026423" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 23:58:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6VNwNIc013551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 23:58:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 18:58:22 -0500 From: "Mo Zanaty (mzanaty)" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.264 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOjhp3XWusdVYmq0SHqDkxPhapBJl/ZD4w Date: Wed, 31 Jul 2013 23:58:22 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.170.78] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [AVTCORE] Clarifying the H.264 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 23:58:37 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, If your application interfaces with an encoder or systems layer (container = file format, transport stream, CDN stream, etc.) that does not indicate fra= me boundaries nor any timing information, then how are you setting the RTP = timestamp? That seems like a much more fundamental issue than the marker bi= t. If you are willing to detect the last NALU of a frame by waiting for the fi= rst VCL NALU of the next frame, that is very simple in both H.264 and H.265= . The first bit after the VCL NALU header is set if it's the first VCL NALU= of a frame. This works in H.265 because the slice header explicitly has su= ch a flag. It works in H.264 because the slice header starts with the macro= block address which will be 0 at the start of the frame (assuming no ASO/FM= O), and 0 encodes to 1 under ue(v) encoding rules. Keep in mind the NALU he= ader is 2 bytes in H.265 vs. 1 byte in H.264, so the slice header offsets a= re different. If you can't wait for the first NALU of the next frame, it is much harder t= o detect the last NALU of a frame without full VCL bitstream parsing, unles= s you use some heuristics which may be simpler but less reliable. This is p= art of the reason why the marker bit in video payloads indicates end of fra= me, because it may be very difficult for RTP receivers to detect without de= ep parsing otherwise. Note that RTP receivers are technically forbidden to = rely on the marker bit. But many implementations detect whether it is relia= ble, then use it as an optimization to minimize latency if reliable. I don't think the draft needs any more text beyond what it currently says. Regards, Mo From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Wednesday, July 31, 2013 2:19 PM To: avt@ietf.org Subject: [AVTCORE] Clarifying the H.264 RTP payload format specification's = text on when to set the RTP "M" bit As I noted in Wednesday morning's AVTCORE session, the proposed H.265 RTP p= ayload format specification is not as clear as it could be about how a RTP = sender knows when to set the "M" bit on an outgoing RTP packet. Currently, the text says: Marker bit (M): 1 bit Set for the last packet of the access unit indicated by the RTP timestamp, in line with the normal use of the M bit in video formats, to allow an efficient playout buffer handling. Decoders can use this bit as an early indication of the last packet of an access unit. There is nothing inherently wrong with this. However (because we're not in= the MPEG world here :-) it's not sufficient to fully specify only how the = receivers of RTP packets should behave; we should also try to specify, as c= learly as possible, how the *senders* of RTP packets should behave. We sho= uld try to give at least some guidance about when the NAL unit that's being= sent ends an "access unit" because - for many implementations - it is not = immediately obvious. If I were amending the H.264 payload format specification - which of course= I'm not - then I would, hypothetically, add a paragraph something like the= following: ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not directly available from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect the next= NAL unit, to determine whether or not the current NAL unit ends an access = unit. The following rule can be used: The current NAL unit ends an access unit if it is a VCL NAL unit (i.e.,= if its "nal_unit_type" is in the range [1..5]), and if either: - the next NAL unit is not a VCL NAL unit, or - either the current NAL unit's "nal_unit_type" or the next NAL= unit's "nal_unit_type" - but not both - is 5 (i.e., "Coded slice of an IDR= picture"), or - the next NAL unit's "nal_ref_idc" field differs from the curr= ent NAL unit's "nal_ref_idc" field, with one of them being equal to zero, o= r - both the current and next NAL units begin with slice headers,= and their "frame_num" fields differ, or - both the current and next NAL units begin with slice headers,= and their "pic_parameter_set_id" fields differ, or - both the current and next NAL units begin with slice headers,= and their "field_pic_flag" fields differ, or - both the current and next NAL units begin with slice headers,= and their "bottom_field_flag" fields differ, or - both the current and next NAL units' "nal_ref_idc" field is 5= , and the "idr_pic_id" fields differ. ---------- (I derived this rule from Section 7.4.1.2.4 - "Detection of the first VCL N= AL unit of a primary coded picture" - of the H.264 specification. Perhaps = it could be simplified?) I suggest that an analogous paragraph be added to the H.265 RTP payload for= mat specification. (Or alternatively, instead of writing a detailed rule l= ike this, perhaps a reference to an appropriate part of the H.265 specifica= tion might be made instead (can we do this in a IETF RFC?).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

If your application interfaces with an = encoder or systems layer (container file format, transport stream, CDN stre= am, etc.) that does not indicate frame boundaries nor any timing information, then how are you setting the RTP timestamp? That seems= like a much more fundamental issue than the marker bit.<= /p>

 

If you are willing to detect the last N= ALU of a frame by waiting for the first VCL NALU of the next frame, that is= very simple in both H.264 and H.265. The first bit after the VCL NALU header is set if it’s the first VCL NALU of a frame. Th= is works in H.265 because the slice header explicitly has such a flag. It w= orks in H.264 because the slice header starts with the macroblock address w= hich will be 0 at the start of the frame (assuming no ASO/FMO), and 0 encodes to 1 under ue(v) encoding rules. Keep= in mind the NALU header is 2 bytes in H.265 vs. 1 byte in H.264, so the sl= ice header offsets are different.

 

If you can’t wait for the first N= ALU of the next frame, it is much harder to detect the last NALU of a frame= without full VCL bitstream parsing, unless you use some heuristics which may be simpler but less reliable. This is part of the reason why the= marker bit in video payloads indicates end of frame, because it may be ver= y difficult for RTP receivers to detect without deep parsing otherwise. Not= e that RTP receivers are technically forbidden to rely on the marker bit. But many implementations detect wheth= er it is reliable, then use it as an optimization to minimize latency if re= liable.

 

I don’t think the draft needs any= more text beyond what it currently says.

 

Regards,

Mo

 

 

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Wednesday, July 31, 2013 2:19 PM
To: avt@ietf.org
Subject: [AVTCORE] Clarifying the H.264 RTP payload format specifica= tion's text on when to set the RTP "M" bit

 

As I noted in Wednesday morning's AVTCORE session, t= he proposed H.265 RTP payload format specification is not as clear as it co= uld be about how a RTP sender knows when to set the "M" bit on an= outgoing RTP packet.

 

Currently, the text says:

 

   Marker bit (M): 1 bit

 

      Set for the last packet of the = access unit indicated by the RTP

      timestamp, in line with the nor= mal use of the M bit in video

      formats, to allow an efficient = playout buffer handling.  Decoders

      can use this bit as an early in= dication of the last packet of an

      access unit.

 

There is nothing inherently wrong with this.  H= owever (because we're not in the MPEG world here :-) it's not sufficient to= fully specify only how the receivers of RTP packets should behave; we shou= ld also try to specify, as clearly as possible, how the *senders* of RTP packets should behave.  We should try to giv= e at least some guidance about when the NAL unit that's being sent ends an = "access unit" because - for many implementations - it is not= immediately obvious.

 

If I were amending the H.264 payload format specific= ation - which of course I'm not - then I would, hypothetically, add a parag= raph something like the following:

 

----------

Unfortunately the contents of a NAL unit, alone, doe= s not tell a RTP sender implementation whether or not the NAL unit ends an = access unit.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not directly available from the encoder (e.g., because= the implementation is sending data that consists solely of a sequence of p= re-encoded NAL units), then it must instead inspect the next NAL unit, to d= etermine whether or not the current NAL unit ends an access unit.  The following rule can be used:

    The current NAL unit ends an access un= it if it is a VCL NAL unit (i.e., if its "nal_unit_type" is in th= e range [1..5]), and if either:

   &nb= sp;        - the next NAL unit is= not a VCL NAL unit, or

   &nb= sp;        - either the current N= AL unit's "nal_unit_type" or the next NAL unit's "nal_u= nit_type" - but not both - is 5 (i.e., "Coded slice of an IDR pic= ture"), or

   &nb= sp;        - the next NAL unit's = "nal_ref_idc" field differs from the current NAL unit's &quo= t;nal_ref_idc" field, with one of them being equal to zero, or

   &nb= sp;        - both the current and= next NAL units begin with slice headers, and their "frame_num" f= ields differ, or

   &nb= sp;        - both the current and= next NAL units begin with slice headers, and their "pic_par= ameter_set_id" fields differ, or

   &nb= sp;        - both the current and= next NAL units begin with slice headers, and their "field_p= ic_flag" fields differ, or

   &nb= sp;        - both the current and= next NAL units begin with slice headers, and their "bottom_= field_flag" fields differ, or

   &nb= sp;        - both the current and= next NAL units' "nal_ref_idc" field is 5, and the "idr= _pic_id" fields differ.

----------

 

(I derived this rule from Section 7.4.1.2.4 - &= quot;Detection of the first VCL NAL unit of a primary coded picture" -= of the H.264 specification.  Perhaps it could be simplified?)

 

I suggest that an analogous paragraph be added to th= e H.265 RTP payload format specification.  (Or alternatively, instead = of writing a detailed rule like this, perhaps a reference to an appropriate= part of the H.265 specification might be made instead (can we do this in a IETF RFC?).)

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_--