From jonathan@vidyo.com Wed Sep 4 14:19:24 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6721E8088 for ; Wed, 4 Sep 2013 14:19:24 -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.000, BAYES_00=-2.599] 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 J1Rw7Fp6OZQ1 for ; Wed, 4 Sep 2013 14:19:20 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 169A111E8115 for ; Wed, 4 Sep 2013 14:19:18 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 578BA553959; Wed, 4 Sep 2013 17:19:18 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B5F765538D0; Wed, 4 Sep 2013 17:19:17 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Wed, 4 Sep 2013 17:16:31 -0400 From: Jonathan Lennox To: Marc Petit-Huguenin , Glen Zorn Date: Wed, 4 Sep 2013 17:19:16 -0400 Thread-Topic: multiple-clock-rates: minor issues during proto writeup Thread-Index: Ac6ptAbffaSFIHkvRlyjR6VKkNn6uw== Message-ID: <541165F9-78D1-42A9-95A1-832F8BA6F59D@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: [avtext] multiple-clock-rates: minor issues during proto writeup X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:19:24 -0000 Hi -- I noticed two issues while working on the Publication Request writeup of th= e multiple-clock-rates draft. (I'd like to apologize for taking so long to= get to this.) [As shepherd:] One was caught by the I-D nits tool. This document formally updates RFC 35= 50, and says so in the document header, but currently the abstract doesn't = mention this fact. It's sufficient to add a sentence "It updates RFC 3550." to the end of the = Abstract. See the Internet Draft checklist section 3.1.D for a full description of the relevant requireme= nt. [As individual:] The other is a minor quibble to the terminology section. It defines an RTP= Sender as a logical network element that "receives RTCP RR packets", and a= n RTP Receiver as one that "sends RTCP RR packets." This isn't quite true, since a network element can be both an RTP Sender an= d an RTP Receiver simultaneously. When you're both a sender and a receiver,= you send RTCP reception report blocks in your SR packets, not in RR packet= s. I think more accurate wording would be to say that an RTCP Sender "receives= RTCP reception report blocks", and an RTCP Receiver "sends RTCP reception = report blocks." Does the WG agree to such a change, if we need to update the draft anyway t= o resolve the first issue? -- Jonathan Lennox jonathan@vidyo.com From magnus.westerlund@ericsson.com Thu Sep 5 00:22:54 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43DA21F842A for ; Thu, 5 Sep 2013 00:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, 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 FZ6iB9m6CJU2 for ; Thu, 5 Sep 2013 00:22:49 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17021F9A6C for ; Thu, 5 Sep 2013 00:22:49 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-57-52283147fbc5 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.59.25272.74138225; Thu, 5 Sep 2013 09:22:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Thu, 5 Sep 2013 09:22:46 +0200 Message-ID: <52283188.6040209@ericsson.com> Date: Thu, 5 Sep 2013 09:23:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathan Lennox References: <541165F9-78D1-42A9-95A1-832F8BA6F59D@vidyo.com> In-Reply-To: <541165F9-78D1-42A9-95A1-832F8BA6F59D@vidyo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvja67oUaQwYZp2hYf791gtVg/+RKL xf7F55ktLqy5y+TA4nH5irfHzll32T2WLPnJ5NH27A57AEsUl01Kak5mWWqRvl0CV8b51pNM Bd0CFTsaHjI2ML7n6WLk5JAQMJHofn+MEcIWk7hwbz1bFyMXh5DAUUaJp7d/s0A4Sxklpv28 wwJSxSugLfFl32Qwm0VAReJy328wm03AQuLmj0Y2EFtUIFiifftXNoh6QYmTM5+A1YgIaEhc fPYBLM4sUCjx4fJ0MFtYwFfi6pofTCC2kICNxJ1X/9lBbE4BW4nPX3dBXScpsW3RMXaIXj2J KVdbGCFseYnmrbOZIXq1JRqaOlgnMArNQrJ6FpKWWUhaFjAyr2LkKE4tTspNNzLYxAgM6oNb flvsYLz81+YQozQHi5I47xa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDNT5qamfw5V elP2pD121fzLpeJHV7w2/2ksrjb7n8jrJjfTGzVq3+a3fTGelHB6lt6+M7YZ2a7s2fa3ivfo Sd9OjchZZrfnaNsbnYYdHCvXOtYoSy/53f92ygLuwzbqE/+2dPVmbbwqNTvvZVNgv8vX+Yd2 vGJsVF+Zc+7aj1WrOD/J/vGdmqnEUpyRaKjFXFScCABeLvR6OAIAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] multiple-clock-rates: minor issues during proto writeup X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 07:22:54 -0000 On 2013-09-04 23:19, Jonathan Lennox wrote: > Hi -- > > I noticed two issues while working on the Publication Request writeup > of the multiple-clock-rates draft. (I'd like to apologize for taking > so long to get to this.) > > [As shepherd:] > > One was caught by the I-D nits tool. This document formally updates > RFC 3550, and says so in the document header, but currently the > abstract doesn't mention this fact. > > It's sufficient to add a sentence "It updates RFC 3550." to the end > of the Abstract. See the Internet Draft checklist > section 3.1.D for a full > description of the relevant requirement. > > > [As individual:] > > The other is a minor quibble to the terminology section. It defines > an RTP Sender as a logical network element that "receives RTCP RR > packets", and an RTP Receiver as one that "sends RTCP RR packets." > > This isn't quite true, since a network element can be both an RTP > Sender and an RTP Receiver simultaneously. When you're both a sender > and a receiver, you send RTCP reception report blocks in your SR > packets, not in RR packets. > > I think more accurate wording would be to say that an RTCP Sender > "receives RTCP reception report blocks", and an RTCP Receiver "sends > RTCP reception report blocks." > > Does the WG agree to such a change, if we need to update the draft > anyway to resolve the first issue? -- Jonathan Lennox > jonathan@vidyo.com Agree that you spotted a minor shortcoming and are fine with your suggestion. Cheers 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 bill.wu@huawei.com Tue Sep 10 19:51:03 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C711E8110 for ; Tue, 10 Sep 2013 19:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XARdjz-EWyMT for ; Tue, 10 Sep 2013 19:50:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1587A11E80D1 for ; Tue, 10 Sep 2013 19:50:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXE80658; Wed, 11 Sep 2013 02:50:45 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 11 Sep 2013 03:50:35 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 11 Sep 2013 03:50:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Wed, 11 Sep 2013 10:50:35 +0800 From: Qin Wu To: Jonathan Lennox , Marc Petit-Huguenin , Glen Zorn Thread-Topic: multiple-clock-rates: minor issues during proto writeup Thread-Index: Ac6ptAbffaSFIHkvRlyjR6VKkNn6uwE5Y8mw Date: Wed, 11 Sep 2013 02:50:35 +0000 Message-ID: References: <541165F9-78D1-42A9-95A1-832F8BA6F59D@vidyo.com> In-Reply-To: <541165F9-78D1-42A9-95A1-832F8BA6F59D@vidyo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "avtext@ietf.org" Subject: Re: [avtext] multiple-clock-rates: minor issues during proto writeup X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:51:03 -0000 Make sense to me. Regards! -Qin -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Jonathan Lennox Sent: Thursday, September 05, 2013 5:19 AM To: Marc Petit-Huguenin; Glen Zorn Cc: avtext@ietf.org Subject: [avtext] multiple-clock-rates: minor issues during proto writeup Hi -- I noticed two issues while working on the Publication Request writeup of th= e multiple-clock-rates draft. (I'd like to apologize for taking so long to= get to this.) [As shepherd:] One was caught by the I-D nits tool. This document formally updates RFC 35= 50, and says so in the document header, but currently the abstract doesn't = mention this fact. It's sufficient to add a sentence "It updates RFC 3550." to the end of the = Abstract. See the Internet Draft checklist section 3.1.D for a full description of the relevant requireme= nt. [As individual:] The other is a minor quibble to the terminology section. It defines an RTP= Sender as a logical network element that "receives RTCP RR packets", and a= n RTP Receiver as one that "sends RTCP RR packets." This isn't quite true, since a network element can be both an RTP Sender an= d an RTP Receiver simultaneously. When you're both a sender and a receiver,= you send RTCP reception report blocks in your SR packets, not in RR packet= s. I think more accurate wording would be to say that an RTCP Sender "receives= RTCP reception report blocks", and an RTCP Receiver "sends RTCP reception = report blocks." Does the WG agree to such a change, if we need to update the draft anyway t= o resolve the first issue? -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From albrecht.schwarz@alcatel-lucent.com Thu Sep 12 01:35:36 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7030A21E818F for ; Thu, 12 Sep 2013 01:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 cIqLzo8FmkXM for ; Thu, 12 Sep 2013 01:35:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5B66F21E818E for ; Thu, 12 Sep 2013 01:35:26 -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 r8C8ZNql013858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2013 03:35:25 -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 r8C8ZNJ9021090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 10:35:23 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 12 Sep 2013 10:35:23 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "jonathan@vidyo.com" Thread-Topic: [Taxonomy] 2.3. Media Source - Comment Thread-Index: Ac6vkwRKMv4nHJDKT0iLJiSY2B9Cug== Date: Thu, 12 Sep 2013 08:35:23 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0AFE82@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC0AFE82FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "avtext@ietf.org" Subject: [avtext] [Taxonomy] 2.3. Media Source - Comment X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:35:36 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC0AFE82FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jonathan, if the "media source" is not limited to audio and video only, then I'd like= to suggest following update proposal to clause 2.3; 2.3. Media Source A Media Source logically defines the source of a raw stream of media data as generated either by a single capture device or by a conceptual source. A Media Source represents an Audio Source or a Video Source. A Media Source represents a source of media data of a dedi= cated media type (e.g., audio, video, text). What do you think? Albrecht --_000_786615F3A85DF44AA2A76164A71FE1AC0AFE82FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jonathan,

 

if the „media source“ is not limited = to audio and video only, then I’d like to suggest following update pr= oposal to clause 2.3;

 

2.3. Media Source

 

   A Media Source logically defines the= source of a raw stream of media

   data as generated either by a single= capture device or by a

   conceptual source.  A Media = Source represents an Audio Source or a

   Video Source. A Media Source represents a source of media data of a dedicated = media type (e.g., audio, video, text).

 

 

What do you think?

Albrecht

--_000_786615F3A85DF44AA2A76164A71FE1AC0AFE82FR711WXCHMBA03zeu_-- From jonathan@vidyo.com Thu Sep 12 08:01:04 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA7311E826E for ; Thu, 12 Sep 2013 08:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OEM_S_DOL=1.2] 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 S5YFr5Lrs61X for ; Thu, 12 Sep 2013 08:00:58 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id AE7CF11E8236 for ; Thu, 12 Sep 2013 08:00:05 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1CAD98BE91F; Thu, 12 Sep 2013 10:59:47 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 83F978BE72C; Thu, 12 Sep 2013 10:59:46 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Thu, 12 Sep 2013 10:59:46 -0400 From: Jonathan Lennox To: "Schwarz, Albrecht (Albrecht)" Date: Thu, 12 Sep 2013 10:59:43 -0400 Thread-Topic: [Taxonomy] 2.3. Media Source - Comment Thread-Index: Ac6vyFQx+N4lWaqXT6GMTdhLf5jkKA== Message-ID: References: <786615F3A85DF44AA2A76164A71FE1AC0AFE82@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0AFE82@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C08204829700465A87959B6AC6B6EFAFvidyocom_" MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] [Taxonomy] 2.3. Media Source - Comment X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:01:04 -0000 --_000_C08204829700465A87959B6AC6B6EFAFvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It makes sense to me, though I'm not the primary person working on the docu= ment at this point. (Magnus and Bo currently have the editing token.) On Sep 12, 2013, at 4:35 AM, "Schwarz, Albrecht (Albrecht)" > wrote: Hello Jonathan, if the =84media source=93 is not limited to audio and video only, then I=92= d like to suggest following update proposal to clause 2.3; 2.3. Media Source A Media Source logically defines the source of a raw stream of media data as generated either by a single capture device or by a conceptual source. A Media Source represents an Audio Source or a Video Source. A Media Source represents a source of media data of a dedi= cated media type (e.g., audio, video, text). What do you think? Albrecht -- Jonathan Lennox jonathan@vidyo.com --_000_C08204829700465A87959B6AC6B6EFAFvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
It makes sense to me, though I'm not the primary person working= on the document at this point.  (Magnus and Bo currently have the edi= ting token.) 

On Sep 12, 2013, at 4:35 AM, "Schwarz= , Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> wrote:

 
if the =84media source=93 is not limited to audio and video only, then I= =92d like to suggest following update proposal to clause 2.3;
 
2.3. Media Source=
 
   A Me= dia Source logically defines the source of a raw stream of media=
   data as generated either by a single capture de= vice or by a
   conceptual source. =  A Media Source repres= ents an Audio Source or a
   Vide= o Source. A Media Source represents a source of media data of a ded= icated media type (e.g., audio, video, text).
 
What do = you think?
Albrecht

--
Jonathan Lennox
jonat= han@vidyo.com

= --_000_C08204829700465A87959B6AC6B6EFAFvidyocom_-- From gsalguei@cisco.com Thu Sep 12 12:36:19 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFFF11E81A4 for ; Thu, 12 Sep 2013 12:36:19 -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 WgCT79cIkHMn for ; Thu, 12 Sep 2013 12:36:14 -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 0C36611E8198 for ; Thu, 12 Sep 2013 12:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8869; q=dns/txt; s=iport; t=1379014574; x=1380224174; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kIKmAMNtwrBxkxpLhgaDPdiDLWCU5bfPZP89BSpV/i0=; b=Bt+iDlgui2btrw9bJb9piTPz/ly1h48P6/fsKf5zJ9+k5YmPXMdXZSpO pQBlTwjDZ47T8hKXW2R1fw0EBnSBcYKcErEUOF6tZNyzPzHdz2u3E2XEX QQxz/vkoaPS/YOmIzCKkeRzT12lfFxn/TjeAndsmdqzCRH8EN9ZKIH4lV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIIWMlKtJXG9/2dsb2JhbABbgwc4UsBigR4WdIImAQEEAQEBawsQAgEIIh0HJwsUEQEBBA4FCId6DLpkBI4sgQ4xB4MdgQADqWyDIoFoQg X-IronPort-AV: E=Sophos;i="4.90,892,1371081600"; d="scan'208,217";a="259034167" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2013 19:36:13 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8CJaD9p027733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 19:36:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 14:36:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Schwarz, Albrecht (Albrecht)" Thread-Topic: [avtext] [Taxonomy] 2.3. Media Source - Comment Thread-Index: Ac6vkwRKMv4nHJDKT0iLJiSY2B9CugAhjo+A Date: Thu, 12 Sep 2013 19:36:11 +0000 Message-ID: References: <786615F3A85DF44AA2A76164A71FE1AC0AFE82@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0AFE82@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.55] Content-Type: multipart/alternative; boundary="_000_D85334BB1373A34AA5FF84F9A623928A1F028C0Exmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" Subject: Re: [avtext] [Taxonomy] 2.3. Media Source - Comment X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:36:19 -0000 --_000_D85334BB1373A34AA5FF84F9A623928A1F028C0Exmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Albrecht - As Jonathan mentioned, Magnus and Bo are currently making extensive changes= to the Concepts section. The concepts are going to be presented as a medi= a chain of transformations and streams that media can be subject to from se= nder to receiver. As part of that effort, this has overhauled the Media Sou= rce sub-section to which you refer. While your comment is perfectly valid i= n the context of the original text, could you please review the section (po= sted below) and suggest edits or confirm it meets your needs? Cheers, Gonzalo +++++++++++++++++++++++++++++++++ 2.1.4. Media Source A Media Source is the logical source of a reference clock synchronized time progressing digital media stream, called a Source Stream (Section 2.1.5). This transformation takes one or more Raw Streams (Section 2.1.3) and provides a Source Stream as output. This output has been synchronized with some reference clock, even if just a system local wall clock. The output can be of different origins. One type is directly associated with a particular Media Capture's Raw Stream. Others are more conceptual sources, like an audio mix of multiple Raw Streams (Figure 3), a mixed selection of the three loudest inputs regarding speech activity, a selection of a particular video based on the current speaker, i.e. typically based on other Media Sources. Raw Raw Raw Stream Stream Stream | | | V V V +--------------------------+ | Media Source |<-- Reference Clock | Mixer | +--------------------------+ | V Source Stream Figure 3: Conceptual Media Source in form of Audio Mixer +++++++++++++++++++++++++++++++++ On Sep 12, 2013, at 4:35 AM, "Schwarz, Albrecht (Albrecht)" > wrote: Hello Jonathan, if the =84media source=93 is not limited to audio and video only, then I=92= d like to suggest following update proposal to clause 2.3; 2.3. Media Source A Media Source logically defines the source of a raw stream of media data as generated either by a single capture device or by a conceptual source. A Media Source represents an Audio Source or a Video Source. A Media Source represents a source of media data of a dedi= cated media type (e.g., audio, video, text). What do you think? Albrecht _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_D85334BB1373A34AA5FF84F9A623928A1F028C0Exmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Albrecht - 

As Jonathan mentioned, Magnus a= nd Bo are currently making extensive changes to the Concepts section.  = ;The concepts are going to be presented as a media chain of transformations= and streams that media can be subject to from sender to receiver. As part of that effort, this has overhauled th= e Media Source sub-section to which you refer. While your comment is perfec= tly valid in the context of the original text, could you please review the = section (posted below) and suggest edits or confirm it meets your needs?

Cheers,

Gonzalo

++++++++= 3;++++++++++++++= 3;+++++++++

2.1.4.  Media Source

   A Media Source is the logical source of a reference clock
   synchronized time progressing digital media stream, called a S= ource
   Stream (Section 2.1.5).  This transformation takes one or= more Raw
   Streams (Section 2.1.3) and provides a Source Stream as output= .  This
   output has been synchronized with some reference clock, even i= f just
   a system local wall clock.

   The output can be of different origins.  One type is dire= ctly
   associated with a particular Media Capture's Raw Stream.  = ;Others are
   more conceptual sources, like = an audio mix of multiple Raw Streams
   (Figure 3), a mixed selection of the three loudest inputs rega= rding
   speech activity, a selection of a particular video based on th= e
   current speaker, i.e. typically based on other Media Sources.<= br>
                 Raw   &n= bsp;   Raw       Raw
                Stream    = ;Stream    Stream
                  |   &nb= sp;     |         |
                  V   &nb= sp;     V         V
              +---------------------= -----+
              |       &nb= sp;Media Source      |<-- Reference Clock
              |       &nb= sp;   Mixer          |
              +---------------------= -----+
                     = ;       |
                     = ;       V
                     = ; Source Stream

         Figure 3: Conceptual Media Source in form= of Audio Mixer

++++++++= 3;++++++++++++++= 3;+++++++++



On Sep 12, 2013, at 4:35 AM, "Schwarz, Albrecht (Albrecht)" <<= a href=3D"mailto:albrecht.schwarz@alcatel-lucent.com">albrecht.schwarz@alca= tel-lucent.com> wrote:

Hello Jonathan,
 
if the =84media source=93 is not limited to audio and video only, then I=92= d like to suggest following update proposal to clause 2.3;
 
2.3. Media Source
 
   A Media Source logically defines the source of a raw stream of= media
   data as generated either by a single capture device or by a    conceptual source.  A Media Source represents an Aud= io Source or a
   Video Source. A Media Source represents a source of media= data of a dedicated media type (e.g., audio, video, text).
 
 
What do you think?
Albrecht
_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext

--_000_D85334BB1373A34AA5FF84F9A623928A1F028C0Exmbrcdx04ciscoc_-- From internet-drafts@ietf.org Sun Sep 15 02:50:39 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F6F21E804B; Sun, 15 Sep 2013 02:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Kid2DOfdjv+K; Sun, 15 Sep 2013 02:50:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D79C721F9EBE; Sun, 15 Sep 2013 02:50:38 -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.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130915095038.510.83378.idtracker@ietfa.amsl.com> Date: Sun, 15 Sep 2013 02:50:38 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-10.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 09:50: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 Extensions Working = Group of the IETF. Title : Support for Multiple Clock Rates in an RTP Session Author(s) : Marc Petit-Huguenin Glen Zorn Filename : draft-ietf-avtext-multiple-clock-rates-10.txt Pages : 12 Date : 2013-09-15 Abstract: This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. It updates RFC 3550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-multiple-clock-rates-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-multiple-clock-rates-10 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 magnus.westerlund@ericsson.com Sun Sep 15 23:16:34 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968E21F9D1B for ; Sun, 15 Sep 2013 23:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.592 X-Spam-Level: X-Spam-Status: No, score=-105.592 tagged_above=-999 required=5 tests=[AWL=0.657, 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 eZOvk3wKpnon for ; Sun, 15 Sep 2013 23:16:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7D821F9A71 for ; Sun, 15 Sep 2013 23:16:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-b0-5236a23b8ee2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2A.0C.16099.B32A6325; Mon, 16 Sep 2013 08:16:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Mon, 16 Sep 2013 08:16:27 +0200 Message-ID: <5236A27A.1070304@ericsson.com> Date: Mon, 16 Sep 2013 08:17:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20130915095038.510.83378.idtracker@ietfa.amsl.com> In-Reply-To: <20130915095038.510.83378.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvja71IrMggysfpC0+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIbL39kLXglUzL5e2MC4nLeLkZNDQsBEYtnpW+wQtpjEhXvr 2boYuTiEBA4zSmxqXskC4SxnlHj++zorSBWvgLbE3NbjzCA2i4CqxN/mLjYQm03AQuLmj0Yw W1QgWKJ9+1c2iHpBiZMzn7CA2CICohLXd58D2yYs4C9xYv5zsDlCAvYSZ7d8YQSxOQUcJKa/ 6meBuEhSYtuiY2D1zAJ6ElOutjBC2PISzVtnQ/VqSzQ0dbBOYBSchWTdLCQts5C0LGBkXsXI npuYmZNebriJERh+B7f81t3BeOqcyCFGaQ4WJXHeTXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUwRu6/xmbi28IqsXV26LPpF13vPEj+cctwaUzZszjn6XMPMAq5y57InzrtmP78fxfv LtFPCUt8Y7iIJ9Ys5XRT5qP8ncJFc7LvV/o2KHyw/Lru9b/gxZsOZe6et/Drhmlnm/4f2Th9 X7aQ65VKxxm/qzW3XU3hv3I6o80rdLv++52qPOK3ElqNtJVYijMSDbWYi4oTAeDZNwcNAgAA Subject: Re: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-10.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 06:16:34 -0000 Hi, I have no issues with these changes. Cheers Magnus On 2013-09-15 11:50, 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 Extensions Working Group of the IETF. > > Title : Support for Multiple Clock Rates in an RTP Session > Author(s) : Marc Petit-Huguenin > Glen Zorn > Filename : draft-ietf-avtext-multiple-clock-rates-10.txt > Pages : 12 > Date : 2013-09-15 > > Abstract: > This document clarifies the RTP specification when different clock > rates are used in an RTP session. It also provides guidance on how > to interoperate with legacy RTP implementations that use multiple > clock rates. It updates RFC 3550. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-multiple-clock-rates-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-multiple-clock-rates-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > -- 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 bo.burman@ericsson.com Thu Sep 19 08:23:31 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9B421F9433 for ; Thu, 19 Sep 2013 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 G9o8NEp0f-lx for ; Thu, 19 Sep 2013 08:23:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CA5CF21F991F for ; Thu, 19 Sep 2013 08:23:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-ca-523b16eb0cf1 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 77.41.22048.BE61B325; Thu, 19 Sep 2013 17:23:23 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.148]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 17:23:22 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt Thread-Index: AQHOtUhLxbriv+AGmEGXUMBNLtX4gZnNJwMw Date: Thu, 19 Sep 2013 15:23:22 +0000 Message-ID: References: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> In-Reply-To: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje5rMesgg3fzhCw+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmts5kKZopXvO9+x9LAeEKoi5GTQ0LAROLZwi4mCFtM4sK9 9WxdjFwcQgKHGSVeNK5kgXCWMErcnLKAHaSKTUBDYv6Ou4wgtoiAusSd6RfYQGxhAS+J1ier mSDi3hJXeu+wQthGEvvP3wazWQRUJRb0dIDV8Ar4Spy7fAhsjpCAo8TxF2+ZQWxOASeJY70X wGxGAVmJ+9/vsYDYzALiEreezIe6VEBiyZ7zzBC2qMTLx/9YIWxFiavTlzNB1OtILNj9iQ3C 1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOern5JkZg4B/c8ttg B+Om+2KHGKU5WJTEeTfrnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBjbYzJhoa/Q46vv L71friHc4Fz85Mep/RGlChrz1khbtXjacW9e+jMr4M5ztctLU5KmB5zeaul3eUJKxoNnBxWX /Zx332Xz3C0Bffvj/tnP9NA2lJtwvc07wnD3px3SbDJH8moL3n9tlengtL0g9Sx4EU+N0soE /faXE7o3TRaccfmvwdSjf+8osRRnJBpqMRcVJwIAgQvuxEoCAAA= Subject: [avtext] FW: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:23:31 -0000 This draft is significantly revised compared to the previous one, including= a section (2) with a conceptual "media chain" including both stream concep= ts and transformation concepts for both sender and receiver, as was request= ed at IETF 87 in Berlin. There is also a section (3) that discusses relatio= nships between concepts, including simulcast, layered encoding and stream p= rotection (FEC and retransmission), which was also requested. Section 4 and onward is not changed much and quite some work will still be = needed to align and further improve it. There should however already be eno= ugh information in sections 2 and 3 to start discussing applicability and u= sefulness of this taxonomy proposal and comments are of course welcome and = encouraged. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: den 19 september 2013 16:55 To: i-d-announce@ietf.org Subject: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Taxonomy of Grouping Semantics and Mechanisms for Real= -Time Transport Protocol (RTP) Sources Author(s) : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt Pages : 40 Date : 2013-09-19 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. This document is still very rough, but is submitted in the hopes of making future discussion productive. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy There's also a htmlized version available at: http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-lennox-raiarea-rtp-grouping-taxono= my-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From magnus.westerlund@ericsson.com Thu Sep 19 23:26:46 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C563F21F84B7 for ; Thu, 19 Sep 2013 23:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.580, 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 QFCKU0DpaqSC for ; Thu, 19 Sep 2013 23:26:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 366C421F84B1 for ; Thu, 19 Sep 2013 23:26:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-0e-523bea9eda6c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 75.CF.22048.E9AEB325; Fri, 20 Sep 2013 08:26:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 08:26:38 +0200 Message-ID: <523BEAB8.60300@ericsson.com> Date: Fri, 20 Sep 2013 08:27:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Colin Perkins References: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> In-Reply-To: <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvje78V9ZBBhvnsll8vHeD1WL5yxOM Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGpAVhBbs0Kva82MvcwLhXoYuRk0NCwETi 9bRZLBC2mMSFe+vZuhi5OIQEDjNKtCzfwgjhLGOU+HdxNjtIFa+ApsT9CefBOlgEVCVe/l4P ZrMJWEjc/NHIBmKLCgRLtG//ygZRLyhxcuYTsBoRoPodx/8xgtjMAuoSh/ctAbOFBeQkLm36 CbWsn1Fi27b7YA2cAo4SvctPMkOcJymxbdExdohmPYkpV1ugBslLNG+dDVYjJKAt0dDUwTqB UWgWkt2zkLTMQtKygJF5FSN7bmJmTnq5+SZGYLAe3PLbYAfjpvtihxilOViUxHk3650JFBJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cB40Mrm5Vcer2Ont65PfX9o3emkXzNT1L6ypUeHFDWx lFnu8TbqPXLjxXn302k1h/N1e8VcXu0/rOKxJshb5Noiib3Py+rvnGL63NH4/r+S9J3FG05v WLjoZEaWk0DuhtBCnYMc0ozuaiUbNgt8n9dXf3RT4MzKSxuOHtujv1LkJfusW7FrtrhPUmIp zkg01GIuKk4EAEKuvz8kAgAA Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 06:26:46 -0000 Hi Colin, I just wanted to comment on what have and have not been addressed in the new version of the taxonomy draft. Me and Bo forgot about this email until after we had done our submission, sorry about that. On 2013-07-19 22:34, Colin Perkins wrote: > On 16 Jul 2013, at 15:53, wrote: >> (As AVTEXT WG cochair) >> >> The latest version of the taxonomy draft has been submitted >> >> https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/ >> >> >> This document was allocated to AVTEXT by dispatch, and we have >> created a milestone for it in AVTEXT. >> >> This draft is not yet a working group document. >> >> We do expect to spend some significant time discussing the contents >> in the AVTEXT meeting in Berlin, so please start raising your >> issues on the AVTEXT list. > > > This looks like a very useful document, that will hopefully avoid > some confusion in future. Some brief comments: > > - Section 2.4.2 incorrectly expands RTCP as "Real-time Transport > Control Protocol", and should be "RTP Control Protocol". Not addressed, but I have entered it into the source so that it will be addressed in the next version. > > - Section 2.6.2, 2nd bullet: it might be useful to explain that > multiple RTP sessions can only be multiplexed over a single transport > flow if some sort of shim is included in the packets to distinguish > the sessions (the referenced > draft-westerlund-avtcore-transport-multiplexing describes why this > has to be the case in detail, but I think the high-level point is > important to cover in this draft too). I also think the term "session > multiplexing" is unclear about what is multiplexed, and would prefer > it not be used. This has been substantially rewritten and split appart. And I agree that Session multiplexing is not a good term and the new document discusses both RTP Session based separation of RTP Packet Streams and Multiple RTP sessions over one Media Transport. See section 3.3.4.2 and 3.4. > > - Section 2.9.1: I'm not sure an m= line description the > configuration required to decode a media stream. It might be better > to say the combination of an m= line, the associated payload format > mapping in the associated a=rtpmap: lines, and the payload format > parameters in a=fmtp: lines define the configuration required to > decode a media stream. Just the m= line is only sufficient for the > trivial static payload types. Also this has ceased to exist in the form you protested. > > - Section 2.10: what's the relationship between a "participant" and > an "end point"? In most cases a one to one as the end point is this addressable entity for the media chain and the participant is what is addressable on the signaling plane. However, this is not always true if we take SIP forking or other cases where a signalling entity has multiple points of presence. This will need to be better explored and the place to do it is likely in the Section 4 rewrite. This section is intended to cover how the RTP session, transport topologies and signaling interact to cause difficult situations. > > - Section 2.11.2: I'm not sure an RTCP CNAME can identify a > participant in an RTP multimedia session; the RTCP CNAME describes a > synchronisation context, but a participant can generate multiple > unsynchronised media streams. This is now Section 2.2.4.2, however the question remains. I think I agree that Participant is likely to go to far in the bindings, however CNAME clearly has an overload functionality of being both an end point identifier and a synchronization context. I think the synchronization context is the one that must prevail and the end point usage discontinued. For the next version I have removed this bullet. Discussion of identification is likely needed but likely in a better context. I think this do applies for exploration in the Section 4 rewrite. > > - Section 3.1.1: note that RTP uses NTP-format timestamps, but > doesn't require the clock be synchronised to NTP. This section can be > mis-read as requiring the use of NTP, rather than just the timestamp > format of NTP. Section 3.1.1.1. now says: RFC3550 [RFC3550] describes Inter-media synchronization between RTP Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP) [RFC5905] formatted timestamps of a reference clock. > > - Section 4: it might be appropriate to highlight the confusion > between RTCP SDES and RTP security descriptions, since both are > referred to as "SDES" frequently. > > > No usage of SDES is the submitted draft. Cheers 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 internet-drafts@ietf.org Fri Sep 20 05:24:13 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82821F89F7; Fri, 20 Sep 2013 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, 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 f9eUHXy57P5o; Fri, 20 Sep 2013 05:24:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F121F853A; Fri, 20 Sep 2013 05:24:12 -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.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130920122412.15466.29256.idtracker@ietfa.amsl.com> Date: Fri, 20 Sep 2013 05:24:12 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-duplication-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:24:13 -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 Extensions Working = Group of the IETF. Title : Duplicating RTP Streams Author(s) : Ali Begen Colin Perkins Filename : draft-ietf-avtext-rtp-duplication-03.txt Pages : 10 Date : 2013-09-20 Abstract: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-duplication-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Fri Sep 20 05:28:20 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB7321F999B for ; Fri, 20 Sep 2013 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 ctqWrSNKEvDa for ; Fri, 20 Sep 2013 05:28:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2D21F99B0 for ; Fri, 20 Sep 2013 05:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2091; q=dns/txt; s=iport; t=1379680095; x=1380889695; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=dTpbxrlXoYiww58UZmZBgBrTooV3AyDv3Zzi5apRqA8=; b=HV1LeHSwJM69eK+TbQy6X6nftVY0r5iFfiNpDdVbPRJ104KZHbSuBL7r 3dgdhlEVOnbB66y768EyqcEoHonzMAbZFLzKbraBnQNMmokiXOnW4sAi9 tVAqAeW7rXim7IzR5C3YC84G4qV12sA/Ya9IdFezI7cNXe3bgpSIGYKue I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPY9PFKtJXHB/2dsb2JhbABagmYhOEwGwTmBHBZ0giUBAQEDATo9BwsCARkDAQILFBAyGwIIAgQBEggBh3YGAQYFumSPND6DGIEAA5krkEeDJIIq X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="259361799" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 20 Sep 2013 12:28:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8KCSEIq010928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 12:28:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 07:28:14 -0500 From: "Ali C. Begen (abegen)" To: "avtext@ietf.org" , Jonathan Lennox Thread-Topic: New Version Notification for draft-ietf-avtext-rtp-duplication-03.txt Thread-Index: AQHOtfxSgB7+C6qrbUSimqP6bIKsug== Date: Fri, 20 Sep 2013 12:28:13 +0000 Message-ID: References: <20130920122413.15466.87102.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] Fwd: New Version Notification for draft-ietf-avtext-rtp-duplication-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:28:20 -0000 This was just a refresh submission to keep the draft alive. The WGLC had en= ded a week ago or so and I will be trying to address the comments sent to t= he list (mostly by Magnus).=20 -acbegen Begin forwarded message: > From: > Subject: New Version Notification for draft-ietf-avtext-rtp-duplication-0= 3.txt > Date: September 20, 2013 3:24:13 PM GMT+03:00 > To: "Dr. Colin Perkins" , Colin Perkins , Ali Begen >=20 >=20 > A new version of I-D, draft-ietf-avtext-rtp-duplication-03.txt > has been successfully submitted by Ali Begen and posted to the > IETF repository. >=20 > Filename: draft-ietf-avtext-rtp-duplication > Revision: 03 > Title: Duplicating RTP Streams > Creation date: 2013-09-20 > Group: avtext > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-ietf-avtext-rt= p-duplication-03.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-du= plication > Htmlized: http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplica= tion-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp= -duplication-03 >=20 > Abstract: > Packet loss is undesirable for real-time multimedia sessions, but can > occur due to congestion, or other unplanned network outages. This is > especially true for IP multicast networks, where packet loss patterns > can vary greatly between receivers. One technique that can be used > to recover from packet loss without incurring unbounded delay for all > the receivers is to duplicate the packets and send them in separate > redundant streams. This document explains how Real-time Transport > Protocol (RTP) streams can be duplicated without breaking RTP or RTP > Control Protocol (RTCP) rules. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From csp@csperkins.org Sun Sep 22 08:58:44 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9BA21F9E98 for ; Sun, 22 Sep 2013 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 zETkXFGNVXgN for ; Sun, 22 Sep 2013 08:58:33 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 31C9421F9E9D for ; Sun, 22 Sep 2013 08:58:29 -0700 (PDT) Received: from [81.187.2.149] (port=46160 helo=[192.168.0.14]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VNm3A-0008UT-RL; Sun, 22 Sep 2013 16:58:24 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <523BEAB8.60300@ericsson.com> Date: Sun, 22 Sep 2013 16:58:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <766FC0D4-D33C-4B49-941A-1C442DF1E456@csperkins.org> References: <949EF20990823C4C85C18D59AA11AD8B06AD4E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <381F511C-3377-4D3E-848F-50CC1D7DD017@csperkins.org> <523BEAB8.60300@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 15:58:44 -0000 Hi Magnus, On 20 Sep 2013, at 07:27, Magnus Westerlund = wrote: > I just wanted to comment on what have and have not been addressed in = the > new version of the taxonomy draft. Me and Bo forgot about this email > until after we had done our submission, sorry about that. No problem; the new draft looks to address many of my concerns.=20 A comment on the latest version: I find it difficult to read in places, = due to the excessive use of sub-section numbering. The might would be = easier to read if the 4th level headings were removed, and replaced by = prose. > On 2013-07-19 22:34, Colin Perkins wrote: >> On 16 Jul 2013, at 15:53, wrote: >>> (As AVTEXT WG cochair) >>>=20 >>> The latest version of the taxonomy draft has been submitted >>>=20 >>> = https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonom= y/ >>>=20 >>>=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 time discussing the contents >>> in the AVTEXT meeting in Berlin, so please start raising your >>> issues on the AVTEXT list. >>=20 >>=20 >> This looks like a very useful document, that will hopefully avoid >> some confusion in future. Some brief comments: >>=20 >> - Section 2.4.2 incorrectly expands RTCP as "Real-time Transport >> Control Protocol", and should be "RTP Control Protocol". >=20 > Not addressed, but I have entered it into the source so that it will = be > addressed in the next version. Okay. >> - Section 2.6.2, 2nd bullet: it might be useful to explain that >> multiple RTP sessions can only be multiplexed over a single transport >> flow if some sort of shim is included in the packets to distinguish >> the sessions (the referenced >> draft-westerlund-avtcore-transport-multiplexing describes why this >> has to be the case in detail, but I think the high-level point is >> important to cover in this draft too). I also think the term "session >> multiplexing" is unclear about what is multiplexed, and would prefer >> it not be used. >=20 > This has been substantially rewritten and split appart. And I agree = that > Session multiplexing is not a good term and the new document discusses > both RTP Session based separation of RTP Packet Streams and Multiple = RTP > sessions over one Media Transport. See section 3.3.4.2 and 3.4. The new version is better. I would suggest that Sections 3.3.4.1 and = 3.3.4.2 should also mention how the streams can be explicitly related = (i.e., using a common RTCP CNAME, or other means).=20 >> - Section 2.9.1: I'm not sure an m=3D line description the >> configuration required to decode a media stream. It might be better >> to say the combination of an m=3D line, the associated payload format >> mapping in the associated a=3Drtpmap: lines, and the payload format >> parameters in a=3Dfmtp: lines define the configuration required to >> decode a media stream. Just the m=3D line is only sufficient for the >> trivial static payload types. >=20 > Also this has ceased to exist in the form you protested. >=20 >>=20 >> - Section 2.10: what's the relationship between a "participant" and >> an "end point"? >=20 > In most cases a one to one as the end point is this addressable entity > for the media chain and the participant is what is addressable on the > signaling plane. However, this is not always true if we take SIP = forking > or other cases where a signalling entity has multiple points of > presence. This will need to be better explored and the place to do it = is > likely in the Section 4 rewrite. This section is intended to cover how > the RTP session, transport topologies and signaling interact to cause > difficult situations. Decomposed endpoints would be another, presumably.=20 >> - Section 2.11.2: I'm not sure an RTCP CNAME can identify a >> participant in an RTP multimedia session; the RTCP CNAME describes a >> synchronisation context, but a participant can generate multiple >> unsynchronised media streams. >=20 > This is now Section 2.2.4.2, however the question remains. >=20 > I think I agree that Participant is likely to go to far in the = bindings, > however CNAME clearly has an overload functionality of being both an = end > point identifier and a synchronization context. I think the > synchronization context is the one that must prevail and the end point > usage discontinued. Agree. > For the next version I have removed this bullet. Discussion of > identification is likely needed but likely in a better context. I = think > this do applies for exploration in the Section 4 rewrite. That makes sense. >> - Section 3.1.1: note that RTP uses NTP-format timestamps, but >> doesn't require the clock be synchronised to NTP. This section can be >> mis-read as requiring the use of NTP, rather than just the timestamp >> format of NTP. >=20 > Section 3.1.1.1. now says: >=20 > RFC3550 [RFC3550] describes Inter-media synchronization between RTP > Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP) > [RFC5905] formatted timestamps of a reference clock. Better, although an explicit statement that the NTP-format timestamps = don't need to be NTP synchronised would still be useful. Also, it might = help to reference the clksrc draft? --=20 Colin Perkins http://csperkins.org/