From magnus.westerlund@ericsson.com Mon Apr 2 05:43:09 2012 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 27DC921F851E; Mon, 2 Apr 2012 05:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 brZNDpyChTIN; Mon, 2 Apr 2012 05:43:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D09C121F8513; Mon, 2 Apr 2012 05:43:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-1f-4f799edae896 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D6.32.25560.ADE997F4; Mon, 2 Apr 2012 14:43:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 14:43:06 +0200 Message-ID: <4F799ED9.4040400@ericsson.com> Date: Mon, 2 Apr 2012 14:43:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <4F546EDF.10203@ericsson.com> In-Reply-To: <4F546EDF.10203@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "xrblock@ietf.org" Subject: Re: [AVTCORE] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) 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, 02 Apr 2012 12:43:09 -0000 WG, The date set as end for this WG last call has passed. However, I will keep it open until the end of the week to let some more people comment on it. I do hope that the XR block people will provide some feedback on it. Thanks, Magnus On 2012-03-05 08:44, Magnus Westerlund wrote: > WG, > > This initiates the Working group last call on Monitoring Architecture > for RTP (draft-ietf-avtcore-monarch-11) to be published as Informational > RFC. The WG last call will run for three weeks and end Monday the 26th. > > The draft can be retrieved from here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ > > Please provide feedback if you have read it, even if you have no > comments or think it is good enough, this is important information in > judging the support and readiness for publication. > > Thanks > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 ray.vanbrandenburg@tno.nl Mon Apr 2 05:47:39 2012 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 949BF21F8598; Mon, 2 Apr 2012 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QHsnBl4yKEod; Mon, 2 Apr 2012 05:47:39 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8552A21F8565; Mon, 2 Apr 2012 05:47:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,357,1330902000"; d="scan'208";a="66935167" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 02 Apr 2012 14:47:37 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.35]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0283.003; Mon, 2 Apr 2012 14:47:36 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund Thread-Topic: [xrblock] [AVTCORE] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) Thread-Index: AQHNEM4sllWnHaHKjEmdgw5tTVdQCpaHe/Mb Date: Mon, 2 Apr 2012 12:47:36 +0000 Message-ID: <9DBFA6A2-6EDA-41DB-A0EA-616ABE5EA71D@tno.nl> References: <4F546EDF.10203@ericsson.com>,<4F799ED9.4040400@ericsson.com> In-Reply-To: <4F799ED9.4040400@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" , "xrblock@ietf.org" Subject: Re: [AVTCORE] [xrblock] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) 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, 02 Apr 2012 12:47:39 -0000 Hi, I thought I had already send a mail before, but that mail seems to have nev= er arrived. = Anyway, I have read the document and I think it is ready. = Ray On 2 apr. 2012, at 14:43, "Magnus Westerlund" wrote: > WG, > = > The date set as end for this WG last call has passed. However, I will > keep it open until the end of the week to let some more people comment > on it. I do hope that the XR block people will provide some feedback on i= t. > = > Thanks, > = > Magnus > = > On 2012-03-05 08:44, Magnus Westerlund wrote: >> WG, >> = >> This initiates the Working group last call on Monitoring Architecture >> for RTP (draft-ietf-avtcore-monarch-11) to be published as Informational >> RFC. The WG last call will run for three weeks and end Monday the 26th. >> = >> The draft can be retrieved from here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ >> = >> Please provide feedback if you have read it, even if you have no >> comments or think it is good enough, this is important information in >> judging the support and readiness for publication. >> = >> Thanks >> = >> 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 >> = > = > = > -- = > = > 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 > ---------------------------------------------------------------------- > = > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From csp@csperkins.org Mon Apr 2 08:09:25 2012 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 15D2D21F8603; Mon, 2 Apr 2012 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 xdvAWBHcheDc; Mon, 2 Apr 2012 08:09:24 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 490E621F85FF; Mon, 2 Apr 2012 08:09:24 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SEisl-0007Dd-aH; Mon, 02 Apr 2012 15:09:23 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4F799ED9.4040400@ericsson.com> Date: Mon, 2 Apr 2012 16:09:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EA6713E-B557-419E-850F-255444E027A0@csperkins.org> References: <4F546EDF.10203@ericsson.com> <4F799ED9.4040400@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: avt@ietf.org, "xrblock@ietf.org" Subject: Re: [AVTCORE] [xrblock] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) 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, 02 Apr 2012 15:09:25 -0000 Magnus, I think this draft is in good shape, but there are two issues that came = up at IETF83 that should be addressed: - In the discussion about QoE metrics, it became clear that there are = some classes of metric that can only be interpreted with knowledge of = the media codec that is being used (MOS score was the triggering = example, but there may be others). It might be worth adding a short = section between the current Sections 5.1 and 5.2 on "Correlating RTCP XR = with RTP Data", to mention that in some cases this correlation is = needed, and note that it's necessary to include both the payload type of = the reported media in such reports, and signal details of the payload = format and parameters to which that payload type is bound. - Section 5.1 talks about the need to use single metrics blocks. This is = fine as far as it goes, but it would be appropriate to highlight that it = is appropriate to not-only define metrics separately, but also to do so = in separate drafts where possible, since this makes it easier to evolve = the metrics (update each block separately), and also makes it easier to = require compliance with particular reports. Colin On 2 Apr 2012, at 13:43, Magnus Westerlund wrote: > WG, >=20 > The date set as end for this WG last call has passed. However, I will > keep it open until the end of the week to let some more people comment > on it. I do hope that the XR block people will provide some feedback = on it. >=20 > Thanks, >=20 > Magnus >=20 > On 2012-03-05 08:44, Magnus Westerlund wrote: >> WG, >>=20 >> This initiates the Working group last call on Monitoring Architecture >> for RTP (draft-ietf-avtcore-monarch-11) to be published as = Informational >> RFC. The WG last call will run for three weeks and end Monday the = 26th. >>=20 >> The draft can be retrieved from here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ >>=20 >> Please provide feedback if you have read it, even if you have no >> comments or think it is good enough, this is important information in >> judging the support and readiness for publication. >>=20 >> Thanks >>=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 >=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 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock --=20 Colin Perkins http://csperkins.org/ From p.ohanlon@gmail.com Tue Apr 3 05:15:07 2012 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 2921321F8771 for ; Tue, 3 Apr 2012 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4GOGkkCPUiC3 for ; Tue, 3 Apr 2012 05:15:06 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C16721F8767 for ; Tue, 3 Apr 2012 05:15:05 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3278161wgb.1 for ; Tue, 03 Apr 2012 05:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+w0uHJMhwVuEfuZT52qaqQ1eYH3yAyeoK5JnDiviyrI=; b=pRvNDSGvOhoc/N9drMS9HQn9NWdVpU6cW1Q78yUvXKSah/40vayWOODospfk4Prsqc /WYSlz5CBHjZWesq82gmcgvz+54mZP8eZ3HJWi4gXUdCKVVIKasbkn7C3WKoGTn6Zttc oPawbngY8SIgmqreQ7pDHVnqrbIZhR3Zc3fdsaPPFhn4w+ZM9m89cJpsc+QmsSoxpoha ULOMwzj8aPHotGPvu0iR52+21XuzaNrabXBrI3vrfYQPBjsswcQ6thehKM++1XbbzTsG d4VGgWPUll8+pUZZCrevFOJe9qwIIL1LfjU7+wGv1zJVab1xA5ERBNta/WbRZcvhdHrT Eziw== Received: by 10.180.76.240 with SMTP id n16mr35909093wiw.10.1333455304707; Tue, 03 Apr 2012 05:15:04 -0700 (PDT) Received: from black.lan (94-194-17-167.zone8.bethere.co.uk. [94.194.17.167]) by mx.google.com with ESMTPS id 17sm51772774wis.0.2012.04.03.05.15.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 05:15:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: <4F7446B8.4060509@ericsson.com> Date: Tue, 3 Apr 2012 13:14:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91C26CB6-03CB-4127-8B0F-B9517AABBE0B@gmail.com> References: <4F7446B8.4060509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 03 Apr 2012 12:15:07 -0000 I support adoption by the WG - it would be useful to have such circuit = breakers available sooner than later. Piers O'Hanlon On 29 Mar 2012, at 13:25, Magnus Westerlund wrote: > WG, >=20 > At the IETF 83 there was a presentation in the AVTCORE and also in the > ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast = Sessions" >=20 > = https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breaker= s/ >=20 > This was well received and there was support for adopting this as WG > item. Thus I would like to confirm on the mailing list that we should > adopt a WG item that works on providing RTP congestion control circuit > breakers for unicast transport flows. >=20 > WG, please comment if you support or disagree of such adaptation. The = WG > chairs will call a consensus after Friday the 13th. >=20 > Cheers >=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 magnus.westerlund@ericsson.com Tue Apr 3 07:00:26 2012 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 E15BD11E809F for ; Tue, 3 Apr 2012 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 UUTn1jLrnchj for ; Tue, 3 Apr 2012 07:00:26 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFF4A11E8093 for ; Tue, 3 Apr 2012 07:00:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-82-4f7b0277dcf5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.CD.25560.7720B7F4; Tue, 3 Apr 2012 16:00:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012 16:00:23 +0200 Message-ID: <4F7B0277.3040808@ericsson.com> Date: Tue, 3 Apr 2012 16:00:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "James M. Polk" References: <4F7446B8.4060509@ericsson.com> <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com> In-Reply-To: <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 03 Apr 2012 14:00:27 -0000 On 2012-03-30 02:53, James M. Polk wrote: > While I generally think this draft is > interesting, even the author admits it's awfully > drafty at this point (both in AVTCORE and > TSV-Dir). And I think perhaps too much so in this > version. In other words, I'd like to see more meat on them bones. James, do you think the draft is so drafty that you don't understand the intent on what is to be defined? I did ask for adoption of the WG item, i.e. the task to provide a specific functionality rather than a specific document. I do find it most likely that we adopt the referenced document, but step one is to create a milestone. 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 jmpolk@cisco.com Tue Apr 3 17:52:53 2012 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 F369B21F852C for ; Tue, 3 Apr 2012 17:52:52 -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 0U4JXWkyHTHJ for ; Tue, 3 Apr 2012 17:52:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 49BCA21F8523 for ; Tue, 3 Apr 2012 17:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1717; q=dns/txt; s=iport; t=1333500772; x=1334710372; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=ExIpaOGasdWsdhADHOOiWVlgBpcwIvEKyI+vQm7fEGw=; b=Teb1i+Cvlobr7JVzl6P+nTa0Og1/+SgRXBB9AE3joW0ptnSuMN+IQ5YU cDA8hD0h9OiJoJRi5Ob72j7R5cz9r2s50o0TOpSojX1Mn56r0kxgS74d+ nnXq0gNCIlolyt/It29802AqgLWD4BnpHI4erVIiJYzpdV3SqJratmMZw w=; X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208";a="35831558" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 04 Apr 2012 00:52:50 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q340qo6S030149; Wed, 4 Apr 2012 00:52:50 GMT Message-Id: <201204040052.q340qo6S030149@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Apr 2012 19:52:55 -0500 To: Magnus Westerlund , "James M. Polk" From: "James M. Polk" In-Reply-To: <4F7B0277.3040808@ericsson.com> References: <4F7446B8.4060509@ericsson.com> <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com> <4F7B0277.3040808@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 04 Apr 2012 00:52:53 -0000 At 09:00 AM 4/3/2012, Magnus Westerlund wrote: >On 2012-03-30 02:53, James M. Polk wrote: > > While I generally think this draft is > > interesting, even the author admits it's awfully > > drafty at this point (both in AVTCORE and > > TSV-Dir). And I think perhaps too much so in this > > version. In other words, I'd like to see more meat on them bones. > >James, do you think the draft is so drafty that you don't understand the >intent on what is to be defined? I did ask for adoption of the WG item, >i.e. the task to provide a specific functionality rather than a specific >document. I do find it most likely that we adopt the referenced >document, but step one is to create a milestone. I support the milestone. I think the draft is going in the right=20 direction, but needs a bit more meat on them=20 bones before I support adoption of this draft to=20 fulfill the milestone. In other words, I don't=20 believe the authors will take a wrong turn when=20 filling in the rest of the draft, but want to=20 have some more there so we know one or more of=20 the existing thin areas doesn't do just that. I=20 believe Colin will do a good job. Does this explain where I'm coming from? James >cheers > >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 >---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Apr 3 23:27:20 2012 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 80E1621F86E4 for ; Tue, 3 Apr 2012 23:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 WB3UozhPNTJu for ; Tue, 3 Apr 2012 23:27:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A09CC21F86A5 for ; Tue, 3 Apr 2012 23:27:19 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-81-4f7be9c50a4b Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7C.DF.03534.5C9EB7F4; Wed, 4 Apr 2012 08:27:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 08:27:16 +0200 Message-ID: <4F7BE9C4.7010201@ericsson.com> Date: Wed, 4 Apr 2012 08:27:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "James M. Polk" References: <4F7446B8.4060509@ericsson.com> <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com> <4F7B0277.3040808@ericsson.com> <201204040052.q340qo6S030149@mtv-core-2.cisco.com> In-Reply-To: <201204040052.q340qo6S030149@mtv-core-2.cisco.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 04 Apr 2012 06:27:20 -0000 On 2012-04-04 02:52, James M. Polk wrote: > At 09:00 AM 4/3/2012, Magnus Westerlund wrote: >> On 2012-03-30 02:53, James M. Polk wrote: >>> While I generally think this draft is >>> interesting, even the author admits it's awfully >>> drafty at this point (both in AVTCORE and >>> TSV-Dir). And I think perhaps too much so in this >>> version. In other words, I'd like to see more meat on them bones. >> >> James, do you think the draft is so drafty that you don't understand the >> intent on what is to be defined? I did ask for adoption of the WG item, >> i.e. the task to provide a specific functionality rather than a specific >> document. I do find it most likely that we adopt the referenced >> document, but step one is to create a milestone. > > I support the milestone. > > I think the draft is going in the right > direction, but needs a bit more meat on them > bones before I support adoption of this draft to > fulfill the milestone. In other words, I don't > believe the authors will take a wrong turn when > filling in the rest of the draft, but want to > have some more there so we know one or more of > the existing thin areas doesn't do just that. I > believe Colin will do a good job. > > Does this explain where I'm coming from? > Yes, and I think it is a very valid opinion. My plan is if there is sufficient support for the milestone to go ahead and create it. Then we can do the adoption of the document at a somewhat later stage. However, I do intended to be aggressive time wise on this item to ensure that we have something sufficiently along the publication process that RTCWEB will not hesitate to normatively reference it in their first set of RTP usage specification. I do hope the authors will be diligent and responsive on this draft to make fast progress. 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 csp@csperkins.org Wed Apr 4 00:36:07 2012 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 1685E21F870F for ; Wed, 4 Apr 2012 00:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 tttqIR7+crUq for ; Wed, 4 Apr 2012 00:36:06 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 388C021F870E for ; Wed, 4 Apr 2012 00:36:06 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SFKlA-0005ca-mJ; Wed, 04 Apr 2012 07:36:05 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Wed, 4 Apr 2012 08:36:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07D2C7A5-389A-413A-AAA7-FFE702AE63C1@csperkins.org> References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> To: Mark Handley X-Mailer: Apple Mail (2.1257) Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" Subject: Re: [AVTCORE] I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-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: Wed, 04 Apr 2012 07:36:07 -0000 Mark, So far, we haven't really considered RTP/AVPF rapid feedback (Section 5 = of the draft is essentially a placeholder, and the mechanisms in Section = 4 are specifically for baseline RTCP). As you've noticed, it changes the = dynamics significantly, and we need to think carefully on how the = various rapid feedback modes interact with the circuit breaker = conditions before we define anything. Colin On 4 Apr 2012, at 02:55, Mark Handley wrote: > Colin, Varun, >=20 > Can you clarify how the circuit breaker mechanism would work with RFC > 4585 extended feedback. To make things concrete, I'm thinking about > the following scenario: >=20 > - Sender is sending 2Mb/s video into a 4Mb/s DSL line. RTT is 100ms. > - Receiver is allowed to send up to 2.5% of this as RTCP feedback in > ACK mode, so that's 6.5 packets per RTT if I got the maths right. > - A TCP flow slowstarts, doubles the window for the last time and > collides with the RTP flow in the wonderful way slowstart sometimes > does. If you're unlucky, you'll get 33% packet loss for one full RTT > before TCP backs off. > - The RTCP receiver sends 6 successive RTCP reports over one RTT > indicating 33% loss. If doesn't really matter if ACKs or NACKs are > sent in this scenario. >=20 > The calculated TCP rate would be ~18Kb/s for those parameters, so the > circuit breaker would kick in if I understood the draft correctly > because that's more than two reporting intervals with excessively high > loss. >=20 > This is the main reason for loss event rate in the TFRC specification > - you avoid responding to such transients too strongly. >=20 > Cheers, > Mark >=20 >=20 >=20 > On 5 March 2012 23:32, Colin Perkins wrote: >> Here's our initial attempt at a "circuit breakers" draft for RTCWeb. = Comments welcome - this is very much a straw-man for discussion, rather = than a final solution. >>=20 >> Colin >>=20 >>=20 >>=20 >> Begin forwarded message: >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: = draft-perkins-avtcore-rtp-circuit-breakers-00.txt >>> Date: 5 March 2012 20:17:59 GMT >>> To: i-d-announce@ietf.org >>> Reply-To: internet-drafts@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>> Title : RTP Congestion Control: Circuit Breakers for = Unicast Sessions >>> Author(s) : Colin Perkins >>> Varun Singh >>> Filename : = draft-perkins-avtcore-rtp-circuit-breakers-00.txt >>> Pages : 14 >>> Date : 2012-03-05 >>>=20 >>> The Real-time Transport Protocol (RTP) is widely used for = telephony, >>> video conferencing, and telepresence applications. These >>> applications are often used over best-effort UDP/IP networks. If >>> congestion control is not implemented then network congestion will >>> deteriorate the user's multimedia experience. This document does = not >>> propose a congestion control algorithm. Instead, it specifies a >>> minimal set of "circuit-breakers". Circuit-breakers are = conditions >>> under which an RTP flow should cease to transmit media to protect = the >>> network from excessive congestion. It is expected that all RTP >>> applications running on best-effort networks will be able to run >>> without triggering these circuit breakers in normal operation. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-brea= kers-00.txt >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=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 Wed Apr 4 01:41:14 2012 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 DDE9521F849B for ; Wed, 4 Apr 2012 01:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kxRVUnNI6u1l for ; Wed, 4 Apr 2012 01:41:14 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0979521F8498 for ; Wed, 4 Apr 2012 01:41:14 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SFLmD-0005Uk-aE; Wed, 04 Apr 2012 08:41:13 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4F7BE9C4.7010201@ericsson.com> Date: Wed, 4 Apr 2012 09:41:12 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4F7446B8.4060509@ericsson.com> <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com> <4F7B0277.3040808@ericsson.com> <201204040052.q340qo6S030149@mtv-core-2.cisco.com> <4F7BE9C4.7010201@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: "James M. Polk" , IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 04 Apr 2012 08:41:15 -0000 On 4 Apr 2012, at 07:27, Magnus Westerlund wrote: > On 2012-04-04 02:52, James M. Polk wrote: >> At 09:00 AM 4/3/2012, Magnus Westerlund wrote: >>> On 2012-03-30 02:53, James M. Polk wrote: >>>> While I generally think this draft is >>>> interesting, even the author admits it's awfully >>>> drafty at this point (both in AVTCORE and >>>> TSV-Dir). And I think perhaps too much so in this >>>> version. In other words, I'd like to see more meat on them bones. >>> >>> James, do you think the draft is so drafty that you don't understand the >>> intent on what is to be defined? I did ask for adoption of the WG item, >>> i.e. the task to provide a specific functionality rather than a specific >>> document. I do find it most likely that we adopt the referenced >>> document, but step one is to create a milestone. >> >> I support the milestone. >> >> I think the draft is going in the right >> direction, but needs a bit more meat on them >> bones before I support adoption of this draft to >> fulfill the milestone. In other words, I don't >> believe the authors will take a wrong turn when >> filling in the rest of the draft, but want to >> have some more there so we know one or more of >> the existing thin areas doesn't do just that. I >> believe Colin will do a good job. >> >> Does this explain where I'm coming from? >> > > Yes, and I think it is a very valid opinion. My plan is if there is > sufficient support for the milestone to go ahead and create it. Then we > can do the adoption of the document at a somewhat later stage. However, > I do intended to be aggressive time wise on this item to ensure that we > have something sufficiently along the publication process that RTCWEB > will not hesitate to normatively reference it in their first set of RTP > usage specification. I do hope the authors will be diligent and > responsive on this draft to make fast progress. I'm hoping to... -- Colin Perkins http://csperkins.org/ From vsingh.ietf@gmail.com Wed Apr 4 06:08:37 2012 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 B993421F8690 for ; Wed, 4 Apr 2012 06:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DMyextHRqNkN for ; Wed, 4 Apr 2012 06:08:37 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4D21F8604 for ; Wed, 4 Apr 2012 06:08:36 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so203637wib.13 for ; Wed, 04 Apr 2012 06:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=wv86R7nnuQPDXs7+zDQ9zfF4TY3b1hCLnNFpr1NmyzU=; b=qPi8hAONBD7ftalltcCdsA4GGys+CGeL2Tuufw8NzwqdZJZ0bTdB16OFTcWMrwKzFV v5+XeIM9vHQPFcMS7G4uDNNhxu3Uh8ipkuyT4Ve5JWfETZSJ/z5NayhZ2jPgIZllqfXL PPy5en5V0XREB18FMMbMEsSzxnnFlCc8191SPsQ/mWk217Oq9xsZD3btgn/lJ8Hy0TOY aQKTq21UoYwqZFu4V9YpGb3RyLsMXHWu5Z0XS5yKXAq1c/P/aTWwbtNz9RLsSGNhERrM KZ548RtWIYCBtbZCiLdDOiwtAC1m+9NyWvq/k5BzFkf+Fmy9vyUEMngWElXwgvkCsNsK yXqg== Received: by 10.180.106.9 with SMTP id gq9mr5178966wib.17.1333544915342; Wed, 04 Apr 2012 06:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.2.10 with HTTP; Wed, 4 Apr 2012 06:08:15 -0700 (PDT) In-Reply-To: <07D2C7A5-389A-413A-AAA7-FFE702AE63C1@csperkins.org> References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <07D2C7A5-389A-413A-AAA7-FFE702AE63C1@csperkins.org> From: Varun Singh Date: Wed, 4 Apr 2012 16:08:15 +0300 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtp-congestion@alvestrand.no, Mark Handley , "avt@ietf.org WG" Subject: Re: [AVTCORE] [R-C] I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-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: Wed, 04 Apr 2012 13:08:37 -0000 Hi Mark, As Colin pointed out, currently the circuit breakers are defined for baseline RTCP. Just to clarify: the circuit breaker should give sufficient time for a rate-control to operate in. For example, the REMB message should be sent (as a non-compound RTCP) much before the circuit breaker kicks in and at the same time the circuit breaker should not make the receiver send the REMB message prematurely. Varun On Wed, Apr 4, 2012 at 10:36, Colin Perkins wrote: > Mark, > > So far, we haven't really considered RTP/AVPF rapid feedback (Section 5 o= f the draft is essentially a placeholder, and the mechanisms in Section 4 a= re specifically for baseline RTCP). As you've noticed, it changes the dynam= ics significantly, and we need to think carefully on how the various rapid = feedback modes interact with the circuit breaker conditions before we defin= e anything. > > Colin > > > > On 4 Apr 2012, at 02:55, Mark Handley wrote: >> Colin, Varun, >> >> Can you clarify how the circuit breaker mechanism would work with RFC >> 4585 extended feedback. =A0To make things concrete, I'm thinking about >> the following scenario: >> >> - Sender is sending 2Mb/s video into a 4Mb/s DSL line. =A0RTT is 100ms. >> - Receiver is allowed to send up to 2.5% of this as RTCP feedback in >> ACK mode, so that's 6.5 packets per RTT if I got the maths right. >> - A TCP flow slowstarts, doubles the window for the last time and >> collides with the RTP flow in the wonderful way slowstart sometimes >> does. =A0If you're unlucky, you'll get 33% packet loss for one full RTT >> before TCP backs off. >> - The RTCP receiver sends 6 successive RTCP reports over one RTT >> indicating 33% loss. =A0If doesn't really matter if ACKs or NACKs are >> sent in this scenario. >> >> The calculated TCP rate would be ~18Kb/s for those parameters, so the >> circuit breaker would kick in if I understood the draft correctly >> because that's more than two reporting intervals with excessively high >> loss. >> >> This is the main reason for loss event rate in the TFRC specification >> - you avoid responding to such transients too strongly. >> >> Cheers, >> Mark >> >> >> >> On 5 March 2012 23:32, Colin Perkins wrote: >>> Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Co= mments welcome - this is very much a straw-man for discussion, rather than = a final solution. >>> >>> Colin >>> >>> >>> >>> Begin forwarded message: >>>> From: internet-drafts@ietf.org >>>> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt >>>> Date: 5 March 2012 20:17:59 GMT >>>> To: i-d-announce@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> >>>> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Congestion Control: Circui= t Breakers for Unicast Sessions >>>> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Colin Perkins >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Varun Singh >>>> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-perkins-avtcore-rtp-circui= t-breakers-00.txt >>>> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14 >>>> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-05 >>>> >>>> =A0 The Real-time Transport Protocol (RTP) is widely used for telephon= y, >>>> =A0 video conferencing, and telepresence applications. =A0These >>>> =A0 applications are often used over best-effort UDP/IP networks. =A0I= f >>>> =A0 congestion control is not implemented then network congestion will >>>> =A0 deteriorate the user's multimedia experience. =A0This document doe= s not >>>> =A0 propose a congestion control algorithm. =A0Instead, it specifies a >>>> =A0 minimal set of "circuit-breakers". =A0Circuit-breakers are conditi= ons >>>> =A0 under which an RTP flow should cease to transmit media to protect = the >>>> =A0 network from excessive congestion. =A0It is expected that all RTP >>>> =A0 applications running on best-effort networks will be able to run >>>> =A0 without triggering these circuit breakers in normal operation. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-= breakers-00.txt >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion --=20 http://www.netlab.tkk.fi/~varun/ From mark.j.handley@gmail.com Tue Apr 3 18:55:54 2012 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 6C35E21F8602 for ; Tue, 3 Apr 2012 18:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 B4OP7vay+qBc for ; Tue, 3 Apr 2012 18:55:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 884F721F8601 for ; Tue, 3 Apr 2012 18:55:53 -0700 (PDT) Received: by ghbg16 with SMTP id g16so193920ghb.31 for ; Tue, 03 Apr 2012 18:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RQgvr7jqGxDVAa8S2Ol+wq95vODk8pBArfosFm0PERA=; b=go+cd+s8t95ld0sRllBIQMwxzPuDtZEdR9rvfTaqwkusJoAojpYvLUbYmLcbRJP/8h OiCyrluOBFIJBAPuENC8taj7PVonQU5G6fBf0R395qYXtRh2buvEpn8uE+mJfGbvNa/s WzYT9wB5tJWQee2jLn0TAxF8gm2kdOQjj670WO5qXty3nAuau5lnRk2vxO4fyuXaVP+q sQ+0J3lwf8gF5aLs8pzs2TnmHyaEeK60z48BTQrZuqad5zqqs/L+a2gLbBZzaJ+vB7WO M21QdSe7uLKVvrN8vnHgGdxXAREwDEgysJO9OL7cpbLHlmAdbDa0NcfNB3MXAgHCkL7Z 0GcA== Received: by 10.236.79.234 with SMTP id i70mr12979150yhe.88.1333504553119; Tue, 03 Apr 2012 18:55:53 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.103.4 with HTTP; Tue, 3 Apr 2012 18:55:32 -0700 (PDT) In-Reply-To: <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> From: Mark Handley Date: Wed, 4 Apr 2012 02:55:32 +0100 X-Google-Sender-Auth: nyaxkQSUeAx0Hv83pwjoaNStBF0 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Apr 2012 08:20:12 -0700 Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" Subject: Re: [AVTCORE] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-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: Wed, 04 Apr 2012 01:55:54 -0000 Colin, Varun, Can you clarify how the circuit breaker mechanism would work with RFC 4585 extended feedback. To make things concrete, I'm thinking about the following scenario: - Sender is sending 2Mb/s video into a 4Mb/s DSL line. RTT is 100ms. - Receiver is allowed to send up to 2.5% of this as RTCP feedback in ACK mode, so that's 6.5 packets per RTT if I got the maths right. - A TCP flow slowstarts, doubles the window for the last time and collides with the RTP flow in the wonderful way slowstart sometimes does. If you're unlucky, you'll get 33% packet loss for one full RTT before TCP backs off. - The RTCP receiver sends 6 successive RTCP reports over one RTT indicating 33% loss. If doesn't really matter if ACKs or NACKs are sent in this scenario. The calculated TCP rate would be ~18Kb/s for those parameters, so the circuit breaker would kick in if I understood the draft correctly because that's more than two reporting intervals with excessively high loss. This is the main reason for loss event rate in the TFRC specification - you avoid responding to such transients too strongly. Cheers, Mark On 5 March 2012 23:32, Colin Perkins wrote: > Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comm= ents welcome - this is very much a straw-man for discussion, rather than a = final solution. > > Colin > > > > Begin forwarded message: >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt >> Date: 5 March 2012 20:17:59 GMT >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Congestion Control: Circuit = Breakers for Unicast Sessions >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Colin Perkins >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Varun Singh >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-perkins-avtcore-rtp-circuit-= breakers-00.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-05 >> >> =A0 The Real-time Transport Protocol (RTP) is widely used for telephony, >> =A0 video conferencing, and telepresence applications. =A0These >> =A0 applications are often used over best-effort UDP/IP networks. =A0If >> =A0 congestion control is not implemented then network congestion will >> =A0 deteriorate the user's multimedia experience. =A0This document does = not >> =A0 propose a congestion control algorithm. =A0Instead, it specifies a >> =A0 minimal set of "circuit-breakers". =A0Circuit-breakers are condition= s >> =A0 under which an RTP flow should cease to transmit media to protect th= e >> =A0 network from excessive congestion. =A0It is expected that all RTP >> =A0 applications running on best-effort networks will be able to run >> =A0 without triggering these circuit breakers in normal operation. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-br= eakers-00.txt > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Tue Apr 10 23:23:51 2012 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 67BC821F86D6 for ; Tue, 10 Apr 2012 23:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 wEVMTgsRl13b for ; Tue, 10 Apr 2012 23:23:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8021F86D3 for ; Tue, 10 Apr 2012 23:23:50 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-2b-4f852374e8ff Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.8A.26681.473258F4; Wed, 11 Apr 2012 08:23:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Apr 2012 08:23:47 +0200 Message-ID: <4F852370.7040802@ericsson.com> Date: Wed, 11 Apr 2012 08:23:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Have you or plan to implement draft-ietf-avtcore-feedback-supression-rtp 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, 11 Apr 2012 06:23:51 -0000 WG, IESG is asking about implementations or at least plans to implement RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-16). I had in the write up simple indicated that I didn't know about any. But I didn't ask the list. So if you are implementing or plan to implement can you please send a statement to the list or at least me privately so that I can more accurately represent the situation. That will hopefully reduce the concerns from the IESG. 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 magnus.westerlund@ericsson.com Fri Apr 13 01:10:00 2012 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 204AE21F8762 for ; Fri, 13 Apr 2012 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 aZm1cx4Fcu6t for ; Fri, 13 Apr 2012 01:09:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 39FF221F8754 for ; Fri, 13 Apr 2012 01:09:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-a7-4f87df561962 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 64.11.25560.65FD78F4; Fri, 13 Apr 2012 10:09:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012 10:09:57 +0200 Message-ID: <4F87DF55.2050401@ericsson.com> Date: Fri, 13 Apr 2012 10:09:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] IESG comment regarding draft-ietf-avtcore-feedback-supression-rtp-16 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: Fri, 13 Apr 2012 08:10:00 -0000 WG, A comment from the IESG (Brian Haberman) said the following regarding the second paragraph of section 3: 1. The Protocol Overview section states : "Intermediaries in the network that receive a RTCP TPLR SHOULD NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers." Why is this not a MUST? Is it simply to handle intermediate devices that don't support this function? If there is another scenario where a device may send a TPLR that overlaps, it would be good to spell that out. The document editor has agreed with the IESG that it appears suitable to change this SHOULD NOT to a MUST NOT. Before that goes into the specification that will be approved I want to give the WG a chance to comment on this change. Please provide any feedback on this change no later than April the 20th. Regards 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 Apr 13 02:29:48 2012 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 F044521F8797; Fri, 13 Apr 2012 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 V6OYSphOwJ3I; Fri, 13 Apr 2012 02:29:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB3C21F8628; Fri, 13 Apr 2012 02:29: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.00 Message-ID: <20120413092947.13599.84500.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 02:29:47 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-17.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: Fri, 13 Apr 2012 09:29:48 -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 Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-17.txt Pages : 19 Date : 2012-04-13 In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signaling is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-17.txt From bill.wu@huawei.com Fri Apr 13 02:53:09 2012 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 DC17421F863F for ; Fri, 13 Apr 2012 02:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 w1mCRm7b2OhA for ; Fri, 13 Apr 2012 02:53:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBF021F863D for ; Fri, 13 Apr 2012 02:53:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW60354; Fri, 13 Apr 2012 05:53:09 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 02:50:43 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 02:50:41 -0700 Received: from w53375 (10.138.41.149) by szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 17:50:32 +0800 Message-ID: <796225293DBB4D4EB9F3B7BA818094F6@china.huawei.com> From: Qin Wu To: References: <20120413092947.13599.84500.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 17:50:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-17.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: Fri, 13 Apr 2012 09:53:10 -0000 T24gMTMgQXByaWwgLCAyMDEyIDU6MjkgUE0sIEludGVybmV0LURyYWZ0c0BpZXRmLm9yZyB3cm90 ZTo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQo+IA0KPiBUaXRsZSAgICAgICAgICAgOiBSVENQIEV4dGVuc2lvbiBm b3IgVGhpcmQtcGFydHkgTG9zcyBSZXBvcnQNCj4gQXV0aG9yKHMpICAgICAgIDogUWluIFd1DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuayBYaWENCj4gICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbmkgRXZlbg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNvcmUt ZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMTcudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDE5DQo+ IERhdGUgICAgICAgICAgICA6IDIwMTItMDQtMTMNCj4gDQo+ICAgSW4gYSBsYXJnZSBSVFAgc2Vz c2lvbiB1c2luZyB0aGUgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIGZlZWRiYWNrDQo+ICAg bWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDQ1ODUsIGEgZmVlZGJhY2sgdGFyZ2V0IG1heSBleHBl cmllbmNlDQo+ICAgdHJhbnNpZW50IG92ZXJsb2FkIGlmIHNvbWUgZXZlbnQgY2F1c2VzIGEgbGFy Z2UgbnVtYmVyIG9mIHJlY2VpdmVycw0KPiAgIHRvIHNlbmQgZmVlZGJhY2sgYXQgb25jZS4gIFRo aXMgb3ZlcmxvYWQgaXMgdXN1YWxseSBhdm9pZGVkIGJ5DQo+ICAgZW5zdXJpbmcgdGhhdCBmZWVk YmFjayByZXBvcnRzIGFyZSBmb3J3YXJkZWQgdG8gYWxsIHJlY2VpdmVycywNCj4gICBhbGxvd2lu ZyB0aGVtIHRvIGF2b2lkIHNlbmRpbmcgZHVwbGljYXRlIGZlZWRiYWNrIHJlcG9ydHMuICBIb3dl dmVyLA0KPiAgIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8g Zm9yd2FyZCBmZWVkYmFjaw0KPiAgIHJlcG9ydHMsIGFuZCB0aGlzIG1heSBhbGxvdyBmZWVkYmFj ayBpbXBsb3Npb24uICBUaGlzIG1lbW8gZGlzY3Vzc2VzDQo+ICAgdGhlc2UgY2FzZXMgYW5kIGRl ZmluZXMgYSBuZXcgUlRDUCB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydCB0aGF0IGNhbg0KPiAgIGJl IHVzZWQgdG8gaW5mb3JtIHJlY2VpdmVycyB0aGF0IHRoZSBmZWVkYmFjayB0YXJnZXQgaXMgYXdh cmUgb2Ygc29tZQ0KPiAgIGxvc3MgZXZlbnQsIGFsbG93aW5nIHRoZW0gdG8gc3VwcHJlc3MgZmVl ZGJhY2suICBBc3NvY2lhdGVkIFNEUA0KPiAgIHNpZ25hbGluZyBpcyBhbHNvIGRlZmluZWQuDQo+ IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBy ZXNzaW9uLXJ0cC0xNy50eHQNCg0KSGVyZSBpcyBvbmUgbWlub3IgdXBkYXRlIHRvIGZlZWRiYWNr IHN1cHByZXNzaW9uIGRyYWZ0IGJhc2VkIG9uIGNvbW1lbnRzIGR1cmluZyBJRVRGIExDIGFuZCBm cm9tIEdlbi1BcnQgUmV2aWV3Og0KICAgbyAgRWRpdG9yaWFsIGNoYW5nZXMgYmFzZWQgb24gR2Vu LUFSVCByZXZpZXcuDQoNCiAgIG8gIFJlbW92ZSB0aGUgZGlzY3Vzc2lvbiBvZiBpbXByb3BlciBk aXRoZXJpbmcgdGhhdCBpcyBsZXNzIG9mDQogICAgICBtb3RpdmF0aW9uIG9mIHRoZSBjdXJyZW50 IHZlcnNpb24uDQoNCiAgIG8gIENoYW5nZSBvZiB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGZyb20g U0hPVUxEIE5PVCB0byBNVVNUIE5PVCBpbg0KICAgICAgdGhlIHByb3RvY29sIG92ZXJ2aWV3IHNl Y3Rpb24uDQoNCiAgIG8gIE1vdmUgRXhhbXBsZSB1c2UgY2FzZSBzZWN0aW9uIGFmdGVyIEludHJv ZHVjdGlvbiBzZWN0aW9uLiA= From bill.wu@huawei.com Fri Apr 13 02:56:57 2012 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 0498121F87D5 for ; Fri, 13 Apr 2012 02:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 GUnEj-Gv20dm for ; Fri, 13 Apr 2012 02:56:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F34DB21F87D0 for ; Fri, 13 Apr 2012 02:56:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE61431; Fri, 13 Apr 2012 05:56:40 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 02:53:12 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 02:53:10 -0700 Received: from w53375 (10.138.41.149) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 17:53:06 +0800 Message-ID: <55C2A6D92BB742ECACF7AF46BB3355E8@china.huawei.com> From: Qin Wu To: References: <20120413092947.13599.84500.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 17:53:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-17.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: Fri, 13 Apr 2012 09:56:57 -0000 T24gMTMgQXByaWwgLCAyMDEyIDU6MjkgUE0sIEludGVybmV0LURyYWZ0c0BpZXRmLm9yZyB3cm90 ZTo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQo+IA0KPiBUaXRsZSAgICAgICAgICAgOiBSVENQIEV4dGVuc2lvbiBm b3IgVGhpcmQtcGFydHkgTG9zcyBSZXBvcnQNCj4gQXV0aG9yKHMpICAgICAgIDogUWluIFd1DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuayBYaWENCj4gICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbmkgRXZlbg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNvcmUt ZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMTcudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDE5DQo+ IERhdGUgICAgICAgICAgICA6IDIwMTItMDQtMTMNCj4gDQo+ICAgSW4gYSBsYXJnZSBSVFAgc2Vz c2lvbiB1c2luZyB0aGUgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIGZlZWRiYWNrDQo+ICAg bWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDQ1ODUsIGEgZmVlZGJhY2sgdGFyZ2V0IG1heSBleHBl cmllbmNlDQo+ICAgdHJhbnNpZW50IG92ZXJsb2FkIGlmIHNvbWUgZXZlbnQgY2F1c2VzIGEgbGFy Z2UgbnVtYmVyIG9mIHJlY2VpdmVycw0KPiAgIHRvIHNlbmQgZmVlZGJhY2sgYXQgb25jZS4gIFRo aXMgb3ZlcmxvYWQgaXMgdXN1YWxseSBhdm9pZGVkIGJ5DQo+ICAgZW5zdXJpbmcgdGhhdCBmZWVk YmFjayByZXBvcnRzIGFyZSBmb3J3YXJkZWQgdG8gYWxsIHJlY2VpdmVycywNCj4gICBhbGxvd2lu ZyB0aGVtIHRvIGF2b2lkIHNlbmRpbmcgZHVwbGljYXRlIGZlZWRiYWNrIHJlcG9ydHMuICBIb3dl dmVyLA0KPiAgIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8g Zm9yd2FyZCBmZWVkYmFjaw0KPiAgIHJlcG9ydHMsIGFuZCB0aGlzIG1heSBhbGxvdyBmZWVkYmFj ayBpbXBsb3Npb24uICBUaGlzIG1lbW8gZGlzY3Vzc2VzDQo+ICAgdGhlc2UgY2FzZXMgYW5kIGRl ZmluZXMgYSBuZXcgUlRDUCB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydCB0aGF0IGNhbg0KPiAgIGJl IHVzZWQgdG8gaW5mb3JtIHJlY2VpdmVycyB0aGF0IHRoZSBmZWVkYmFjayB0YXJnZXQgaXMgYXdh cmUgb2Ygc29tZQ0KPiAgIGxvc3MgZXZlbnQsIGFsbG93aW5nIHRoZW0gdG8gc3VwcHJlc3MgZmVl ZGJhY2suICBBc3NvY2lhdGVkIFNEUA0KPiAgIHNpZ25hbGluZyBpcyBhbHNvIGRlZmluZWQuDQo+ IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBy ZXNzaW9uLXJ0cC0xNy50eHQNCg0KSGVyZSBpcyBvbmUgbWlub3IgdXBkYXRlIHRvIGZlZWRiYWNr IHN1cHByZXNzaW9uIGRyYWZ0IGJhc2VkIG9uIGNvbW1lbnRzIGR1cmluZyBJRVRGIExDIGFuZCBm cm9tIEdlbi1BcnQgUmV2aWV3Og0KICAgIG8gIFJlbW92ZSB0aGUgZGlzY3Vzc2lvbiBvZiBpbXBy b3BlciBkaXRoZXJpbmcgaW4gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uLg0KICAgIG8gIENoYW5n ZSBvZiB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGZyb20gU0hPVUxEIE5PVCB0byBNVVNUIE5PVCBp bg0KICAgICAgICB0aGUgcHJvdG9jb2wgb3ZlcnZpZXcgc2VjdGlvbi4NCiAgICBvICBFZGl0b3Jp YWwgY2hhbmdlcyBiYXNlZCBvbiBHZW4tQVJUIHJldmlldy4NCiAgICBvICBNb3ZlIEV4YW1wbGUg dXNlIGNhc2Ugc2VjdGlvbiBiZWZvcmUgUHJvdG9jb2wgb3ZlcnZpZXcgc2VjdGlvbi4= From magnus.westerlund@ericsson.com Fri Apr 13 07:20:14 2012 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 65BDE21F8620 for ; Fri, 13 Apr 2012 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 waRuoFD6PrrN for ; Fri, 13 Apr 2012 07:20:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0471721F861D for ; Fri, 13 Apr 2012 07:20:12 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-f0-4f88361bbb28 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A9.71.26681.B16388F4; Fri, 13 Apr 2012 16:20:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012 16:20:10 +0200 Message-ID: <4F88361A.6090507@ericsson.com> Date: Fri, 13 Apr 2012 16:20:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120413092947.13599.84500.idtracker@ietfa.amsl.com> <55C2A6D92BB742ECACF7AF46BB3355E8@china.huawei.com> In-Reply-To: <55C2A6D92BB742ECACF7AF46BB3355E8@china.huawei.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-17.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: Fri, 13 Apr 2012 14:20:14 -0000 WG, This version will not be approved for publication by the AD until after the previous stated dead line of next Friday (20th of April). This way you have the opportunity to review all the proposed changes resulting from the IESG review. Cheers Magnus Westerlund On 2012-04-13 11:53, Qin Wu wrote: > On 13 April , 2012 5:29 PM, 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 : RTCP Extension for Third-party Loss Report >> Author(s) : Qin Wu >> Frank Xia >> Roni Even >> Filename : draft-ietf-avtcore-feedback-supression-rtp-17.txt >> Pages : 19 >> Date : 2012-04-13 >> >> In a large RTP session using the RTP Control Protocol (RTCP) feedback >> mechanism defined in RFC 4585, a feedback target may experience >> transient overload if some event causes a large number of receivers >> to send feedback at once. This overload is usually avoided by >> ensuring that feedback reports are forwarded to all receivers, >> allowing them to avoid sending duplicate feedback reports. However, >> there are cases where it is not recommended to forward feedback >> reports, and this may allow feedback implosion. This memo discusses >> these cases and defines a new RTCP third-party loss report that can >> be used to inform receivers that the feedback target is aware of some >> loss event, allowing them to suppress feedback. Associated SDP >> signaling is also defined. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-17.txt > > Here is one minor update to feedback suppression draft based on comments during IETF LC and from Gen-Art Review: > o Remove the discussion of improper dithering in the introduction section. > o Change of the normative language from SHOULD NOT to MUST NOT in > the protocol overview section. > o Editorial changes based on Gen-ART review. > o Move Example use case section before Protocol overview section. > _______________________________________________ > 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 magnus.westerlund@ericsson.com Mon Apr 16 07:45:13 2012 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 ABA5821F8687; Mon, 16 Apr 2012 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 3w1eg2YruJdj; Mon, 16 Apr 2012 07:45:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84821F8685; Mon, 16 Apr 2012 07:45:12 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-ac-4f8c3077025b Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.CB.25560.7703C8F4; Mon, 16 Apr 2012 16:45:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 16:45:11 +0200 Message-ID: <4F8C3076.3040200@ericsson.com> Date: Mon, 16 Apr 2012 16:45:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-monarch@tools.ietf.org References: <4F546EDF.10203@ericsson.com> In-Reply-To: <4F546EDF.10203@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "xrblock@ietf.org" Subject: Re: [AVTCORE] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) 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, 16 Apr 2012 14:45:13 -0000 WGs, Authors This WG last call has ended. I had wished for even more reviews but at least four has stated that they have reviewed the document. There has also been a number of comments on the drafts that should be addressed prior to publication. Authors, please start addressing the comments and submit a new version when ready. Cheers Magnus Westerlund On 2012-03-05 08:44, Magnus Westerlund wrote: > WG, > > This initiates the Working group last call on Monitoring Architecture > for RTP (draft-ietf-avtcore-monarch-11) to be published as Informational > RFC. The WG last call will run for three weeks and end Monday the 26th. > > The draft can be retrieved from here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ > > Please provide feedback if you have read it, even if you have no > comments or think it is good enough, this is important information in > judging the support and readiness for publication. > > Thanks > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 versteb@cisco.com Tue Apr 17 10:11:30 2012 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 9157E11E8074 for ; Tue, 17 Apr 2012 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 5zTqzi-v-prH for ; Tue, 17 Apr 2012 10:11:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA3311E80BD for ; Tue, 17 Apr 2012 10:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=versteb@cisco.com; l=1961; q=dns/txt; s=iport; t=1334682685; x=1335892285; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YFj2FCGWI4CMt9Ml/wHpaiJT/Tn3jeCikY9kJc+7jcg=; b=aLvgDhCxDaOLuSPX/EoC/zToeuzc1UyioKRgQ/2FJ3CNiTKOArsastgu 3fffXCCFhcfC+pwdQGYAmEe7jY54ez6iyzQcZTIsJuCzDpiGBKrMaHMle rVhG0qpT8mKcV+iPcPLq64AGZfGzz1pdaega/gfCVoCLzXV+A8VbG5yMh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA+kjU+tJV2a/2dsb2JhbABEsT2BB4IJAQEBBAEBAQkGAR0+FwICAgEIEQQBAQsGFwEGARoMHwkIAQEEARIIGodsC5oRoAUEBJAQYwSIKTObYIFpgwU X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="75439399" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 17 Apr 2012 17:11:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3HHBOJV012090; Tue, 17 Apr 2012 17:11:24 GMT Received: from xmb-rcd-312.cisco.com ([72.163.63.27]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 12:11:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 12:11:23 -0500 Message-ID: <117602CF2B17DB4F9001427FA6D905390196D2B9@XMB-RCD-312.cisco.com> In-Reply-To: <4F7446B8.4060509@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers Thread-Index: Ac0NnrVDLwP2ni6zTUuvUWPMRullogPHgYSg References: <4F7446B8.4060509@ericsson.com> From: "Bill Ver Steeg (versteb)" To: "Magnus Westerlund" , "IETF AVTCore WG" X-OriginalArrivalTime: 17 Apr 2012 17:11:24.0512 (UTC) FILETIME=[1E39E600:01CD1CBD] Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 17 Apr 2012 17:11:30 -0000 Sorry for the tardy input, but I support the topic as a WG item. I do = agree that the draft is a bit thin in some crucial areas, but it is a = good start. I will try to find time to contribute to the process on this = one, as it is quite important work. In fact, circuit breakers are just the first requirement and we need to = finish that up and address congestion control in all of its glory, IMHO. = First things first, though. Bill VerSteeg -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund Sent: Thursday, March 29, 2012 7:26 AM To: IETF AVTCore WG Subject: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers WG, At the IETF 83 there was a presentation in the AVTCORE and also in the ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Sessions" https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breake= rs/ This was well received and there was support for adopting this as WG item. Thus I would like to confirm on the mailing list that we should adopt a WG item that works on providing RTP congestion control circuit breakers for unicast transport flows. WG, please comment if you support or disagree of such adaptation. The WG chairs will call a consensus after Friday the 13th. Cheers 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 From kevin.gross@avanw.com Tue Apr 17 10:21:45 2012 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 7D8D211E80BE for ; Tue, 17 Apr 2012 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.504 X-Spam-Level: X-Spam-Status: No, score=0.504 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 GcaEfrtEd8LA for ; Tue, 17 Apr 2012 10:21:41 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 156EE21F84B5 for ; Tue, 17 Apr 2012 10:21:40 -0700 (PDT) Received: (qmail 11029 invoked by uid 0); 17 Apr 2012 17:21:39 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 17 Apr 2012 17:21:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=ZF4ljW+yX7f4N9R8qK70qyA/kicZSXPiiONWJrRAqWo=; b=KqgGI/YOBFUNWqZpLTUoS+ETeFNJXfZlKAI5PGuxn+13uZoFLvc7ymGJs2zCUSIB9s1b37DLiMAW+ZqgTvHyFcNEEJ2RPdSXcQ/VcWyTInZdLZ/uZoK10feraPgSrvri; Received: from mail-we0-f172.google.com ([74.125.82.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SKC5y-0005y2-Pc for avt@ietf.org; Tue, 17 Apr 2012 11:21:39 -0600 Received: by werb10 with SMTP id b10so5093875wer.31 for ; Tue, 17 Apr 2012 10:21:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr17728991wib.13.1334683297349; Tue, 17 Apr 2012 10:21:37 -0700 (PDT) Received: by 10.223.145.76 with HTTP; Tue, 17 Apr 2012 10:21:37 -0700 (PDT) In-Reply-To: <117602CF2B17DB4F9001427FA6D905390196D2B9@XMB-RCD-312.cisco.com> References: <4F7446B8.4060509@ericsson.com> <117602CF2B17DB4F9001427FA6D905390196D2B9@XMB-RCD-312.cisco.com> Date: Tue, 17 Apr 2012 11:21:37 -0600 Message-ID: From: Kevin Gross To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=f46d044268e6d381bb04bde32b9e X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers 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, 17 Apr 2012 17:21:45 -0000 --f46d044268e6d381bb04bde32b9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Congestion is a topic of interest for me. I will find time to review and contribute. Kevin Gross On Tue, Apr 17, 2012 at 11:11 AM, Bill Ver Steeg (versteb) < versteb@cisco.com> wrote: > Sorry for the tardy input, but I support the topic as a WG item. I do > agree that the draft is a bit thin in some crucial areas, but it is a goo= d > start. I will try to find time to contribute to the process on this one, = as > it is quite important work. > > In fact, circuit breakers are just the first requirement and we need to > finish that up and address congestion control in all of its glory, IMHO. > First things first, though. > > Bill VerSteeg > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Thursday, March 29, 2012 7:26 AM > To: IETF AVTCore WG > Subject: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers > > WG, > > At the IETF 83 there was a presentation in the AVTCORE and also in the > ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Sessions" > > > https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breake= rs/ > > This was well received and there was support for adopting this as WG > item. Thus I would like to confirm on the mailing list that we should > adopt a WG item that works on providing RTP congestion control circuit > breakers for unicast transport flows. > > WG, please comment if you support or disagree of such adaptation. The WG > chairs will call a consensus after Friday the 13th. > > Cheers > > 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 > --f46d044268e6d381bb04bde32b9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Congestion is a topic of interest for me. I will find time to review and co= ntribute.

Kevin Gross

On Tue, Apr 17, 2012 at 11:11 AM, Bill Ver Steeg (versteb) <versteb@cisco.com<= /a>> wrote:
Sorry for the tardy input, but I support the= topic as a WG item. I do agree that the draft is a bit thin in some crucia= l areas, but it is a good start. I will try to find time to contribute to t= he process on this one, as it is quite important work.

In fact, circuit breakers are just the first requirement and we need to fin= ish that up and address congestion control in all of its glory, IMHO. First= things first, though.

Bill VerSteeg

-----Original Message-----
From: avt-bounces@ietf.org [mai= lto:avt-bounces@ietf.org] On Be= half Of Magnus Westerlund
Sent: Thursday, March 29, 2012 7:26 AM
To: IETF AVTCore WG
Subject: [AVTCORE] Adopting n= ew work on RTP Congestion Circuit Breakers

WG,

At the IETF 83 there was a presentation in the AVTCORE and also in the
ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Session= s"

https://datatracker.ietf.org/doc/draft-perk= ins-avtcore-rtp-circuit-breakers/

This was well received and there was support for adopting this as WG
item. Thus I would like to confirm on the mailing list that we should
adopt a WG item that works on providing RTP congestion control circuit
breakers for unicast transport flows.

WG, please comment if you support or disagree of such adaptation. The WG chairs will call a consensus after Friday the 13th.

Cheers

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
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d044268e6d381bb04bde32b9e-- From internet-drafts@ietf.org Tue Apr 17 20:58:35 2012 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 4E41121F852E; Tue, 17 Apr 2012 20:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 ClDavvd282GX; Tue, 17 Apr 2012 20:58:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FEF21F84FD; Tue, 17 Apr 2012 20:58:30 -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.00 Message-ID: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 20:58:30 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 18 Apr 2012 03:58:35 -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 Maintenanc= e Working Group of the IETF. Title : Monitoring Architecture for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-12.txt Pages : 29 Date : 2012-04-17 This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt From bill.wu@huawei.com Tue Apr 17 21:41:04 2012 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 80B2311E8093; Tue, 17 Apr 2012 21:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_BASE64_TEXT=1.753] 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 3Ub3-DXzvw2F; Tue, 17 Apr 2012 21:41:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7507611E8087; Tue, 17 Apr 2012 21:40:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH80480; Wed, 18 Apr 2012 00:40:56 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 21:37:02 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 21:37:01 -0700 Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 12:36:55 +0800 Message-ID: <01BE824C5A784037A5FDE527F76DCA5B@china.huawei.com> From: Qin Wu To: Magnus Westerlund , IETF AVTCore WG , References: <4F546EDF.10203@ericsson.com> <4F8C3076.3040200@ericsson.com> Date: Wed, 18 Apr 2012 12:36:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] WG last call on Monitoring Architecture forRTP (draft-ietf-avtcore-monarch-11) 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, 18 Apr 2012 04:41:04 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPkZyb206ICJNYWdudXMgV2VzdGVy bHVuZCIgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCj5UbzogIklFVEYgQVZUQ29y ZSBXRyIgPGF2dEBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaEB0b29scy5p ZXRmLm9yZz4NCj5DYzogPHhyYmxvY2tAaWV0Zi5vcmc+DQo+U2VudDogTW9uZGF5LCBBcHJpbCAx NiwgMjAxMiAxMDo0NSBQTQ0KPlN1YmplY3Q6IFJlOiBbeHJibG9ja10gW0FWVENPUkVdIFdHIGxh c3QgY2FsbCBvbiBNb25pdG9yaW5nIEFyY2hpdGVjdHVyZSBmb3JSVFAgKGRyYWZ0LWlldGYtYXZ0 Y29yZS1tb25hcmNoLTExKQ0KDQoNCj5XR3MsIEF1dGhvcnMNCg0KPlRoaXMgV0cgbGFzdCBjYWxs IGhhcyBlbmRlZC4gSSBoYWQgd2lzaGVkIGZvciBldmVuIG1vcmUgcmV2aWV3cyBidXQgYXQNCj5s ZWFzdCBmb3VyIGhhcyBzdGF0ZWQgdGhhdCB0aGV5IGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50 LiBUaGVyZSBoYXMNCj5hbHNvIGJlZW4gYSBudW1iZXIgb2YgY29tbWVudHMgb24gdGhlIGRyYWZ0 cyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQNCj5wcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KW1Fp bl06IE9rYXksVGhhbmsgZm9yIHRoZXNlIHJldmlld2VyIGFuZCBzcGVjaWFsIHRoYW5rcyB0byBD b2xpbiBhbmQgQ2hhcmxlcy4NCg0KPkF1dGhvcnMsIHBsZWFzZSBzdGFydCBhZGRyZXNzaW5nIHRo ZSBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24NCj53aGVuIHJlYWR5Lg0KDQpbUWlu XTogRG9uZSwgaGVyZSBpcyB0aGUgdXBkYXRlLiBUaGUgVVJMIGZvciB0aGlzIHVwZGF0ZSBpczoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1t b25hcmNoLTEyLnR4dA0KDQpUaGUgbWFpbiBjaGFuZ2VzIGFyZSA6DQogICBvICBBZGQgb25lIG5l dyBzZWN0aW9uIGFmdGVyIHNlY3Rpb24gNS4xIHRvIGRpc2N1c3MgQ29ycmVsYXRpbmcgUlRDUCBY UiB3aXRoIFJUUA0KICAgICAgZGF0YS4NCg0KICAgbyAgQWRkIHRleHQgaW4gc2VjdGlvbiA1LjEg dG8gaGlnaGxpZ2h0IGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8NCiAgICAgIGRlZmluZSBlYWNo IGJsb2NrIGluIGEgc2VwYXJhdGUgZHJhZnQuDQoNCiAgIG8gIEVkaXRvcmlhbCBDaGFuZ2VzIGJh c2VkIG9uIENoYXJsZXMnIENvbW1lbnRzLg0KDQogICBvICBSZWZlcmVuY2UgdXBkYXRlLg0KDQpU aGUgZGlmZiBpczoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdk aWZmJnVybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTIudHh0DQoNCj5DaGVlcnMNCg0K Pk1hZ251cyBXZXN0ZXJsdW5kDQoNCj5PbiAyMDEyLTAzLTA1IDA4OjQ0LCBNYWdudXMgV2VzdGVy bHVuZCB3cm90ZToNCj4+IFdHLA0KPj4gDQo+PiBUaGlzIGluaXRpYXRlcyB0aGUgV29ya2luZyBn cm91cCBsYXN0IGNhbGwgb24gTW9uaXRvcmluZyBBcmNoaXRlY3R1cmUNCj4+IGZvciBSVFAgKGRy YWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTExKSB0byBiZSBwdWJsaXNoZWQgYXMgSW5mb3JtYXRp b25hbA0KPj4gUkZDLiBUaGUgV0cgbGFzdCBjYWxsIHdpbGwgcnVuIGZvciB0aHJlZSB3ZWVrcyBh bmQgZW5kIE1vbmRheSB0aGUgMjZ0aC4NCj4+IA0KPj4gVGhlIGRyYWZ0IGNhbiBiZSByZXRyaWV2 ZWQgZnJvbSBoZXJlOg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1hdnRjb3JlLW1vbmFyY2gvDQo+PiANCj4+IFBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIGlm IHlvdSBoYXZlIHJlYWQgaXQsIGV2ZW4gaWYgeW91IGhhdmUgbm8NCj4+IGNvbW1lbnRzIG9yIHRo aW5rIGl0IGlzIGdvb2QgZW5vdWdoLCB0aGlzIGlzIGltcG9ydGFudCBpbmZvcm1hdGlvbiBpbg0K Pj4ganVkZ2luZyB0aGUgc3VwcG9ydCBhbmQgcmVhZGluZXNzIGZvciBwdWJsaWNhdGlvbi4NCj4+ IA0KPj4gVGhhbmtzDQo+PiANCj4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+PiANCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIv VFZNDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPj4gRuRy9mdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2Jp bGUgKzQ2IDczIDA5NDkwNzkNCj4+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRv OiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEF1 ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+PiBhdnRAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+PiA= From bill.wu@huawei.com Tue Apr 17 21:42:39 2012 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 ED95221F851D; Tue, 17 Apr 2012 21:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 ZC13JB+9YB4i; Tue, 17 Apr 2012 21:42:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBE21F84FF; Tue, 17 Apr 2012 21:42:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH80564; Wed, 18 Apr 2012 00:42:34 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 21:38:51 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 21:38:49 -0700 Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 12:38:45 +0800 Message-ID: <4840575D310F402A8E859838C8CB219C@china.huawei.com> From: Qin Wu To: Colin Perkins , Magnus Westerlund References: <4F546EDF.10203@ericsson.com> <4F799ED9.4040400@ericsson.com> <2EA6713E-B557-419E-850F-255444E027A0@csperkins.org> Date: Wed, 18 Apr 2012 12:38:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] WG last call on Monitoring Architecture forRTP (draft-ietf-avtcore-monarch-11) 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, 18 Apr 2012 04:42:39 -0000 SGksIENvbGluOg0KU29ycnkgZm9yIGxhdGUuIFlvdXIgcHJvcG9zZWQgY2hhbmdlcyBsb29rcyBn b29kIHRvIG1lIGFuZCBoYXMgYmVlbiBpbmNvcnBvcmF0ZWQgaW50byB2ZXJpb24gKC0xMikuDQpU aGFuayB5b3UgdmVyeSBtdWNoLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCkZyb206ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVya2lucy5vcmc+DQpU bzogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0K Q2M6IDxhdnRAaWV0Zi5vcmc+OyA8eHJibG9ja0BpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgQXBy aWwgMDIsIDIwMTIgMTE6MDkgUE0NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3hyYmxvY2tdIFdH IGxhc3QgY2FsbCBvbiBNb25pdG9yaW5nIEFyY2hpdGVjdHVyZSBmb3JSVFAgKGRyYWZ0LWlldGYt YXZ0Y29yZS1tb25hcmNoLTExKQ0KDQoNCk1hZ251cywNCg0KSSB0aGluayB0aGlzIGRyYWZ0IGlz IGluIGdvb2Qgc2hhcGUsIGJ1dCB0aGVyZSBhcmUgdHdvIGlzc3VlcyB0aGF0IGNhbWUgdXAgYXQg SUVURjgzIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZDoNCg0KLSBJbiB0aGUgZGlzY3Vzc2lvbiBh Ym91dCBRb0UgbWV0cmljcywgaXQgYmVjYW1lIGNsZWFyIHRoYXQgdGhlcmUgYXJlIHNvbWUgY2xh c3NlcyBvZiBtZXRyaWMgdGhhdCBjYW4gb25seSBiZSBpbnRlcnByZXRlZCB3aXRoIGtub3dsZWRn ZSBvZiB0aGUgbWVkaWEgY29kZWMgdGhhdCBpcyBiZWluZyB1c2VkIChNT1Mgc2NvcmUgd2FzIHRo ZSB0cmlnZ2VyaW5nIGV4YW1wbGUsIGJ1dCB0aGVyZSBtYXkgYmUgb3RoZXJzKS4gSXQgbWlnaHQg YmUgd29ydGggYWRkaW5nIGEgc2hvcnQgc2VjdGlvbiBiZXR3ZWVuIHRoZSBjdXJyZW50IFNlY3Rp b25zIDUuMSBhbmQgNS4yIG9uICJDb3JyZWxhdGluZyBSVENQIFhSIHdpdGggUlRQIERhdGEiLCB0 byBtZW50aW9uIHRoYXQgaW4gc29tZSBjYXNlcyB0aGlzIGNvcnJlbGF0aW9uIGlzIG5lZWRlZCwg YW5kIG5vdGUgdGhhdCBpdCdzIG5lY2Vzc2FyeSB0byBpbmNsdWRlIGJvdGggdGhlIHBheWxvYWQg dHlwZSBvZiB0aGUgcmVwb3J0ZWQgbWVkaWEgaW4gc3VjaCByZXBvcnRzLCBhbmQgc2lnbmFsIGRl dGFpbHMgb2YgdGhlIHBheWxvYWQgZm9ybWF0IGFuZCBwYXJhbWV0ZXJzIHRvIHdoaWNoIHRoYXQg cGF5bG9hZCB0eXBlIGlzIGJvdW5kLg0KDQotIFNlY3Rpb24gNS4xIHRhbGtzIGFib3V0IHRoZSBu ZWVkIHRvIHVzZSBzaW5nbGUgbWV0cmljcyBibG9ja3MuIFRoaXMgaXMgZmluZSBhcyBmYXIgYXMg aXQgZ29lcywgYnV0IGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGhpZ2hsaWdodCB0aGF0IGl0 IGlzIGFwcHJvcHJpYXRlIHRvIG5vdC1vbmx5IGRlZmluZSBtZXRyaWNzIHNlcGFyYXRlbHksIGJ1 dCBhbHNvIHRvIGRvIHNvIGluIHNlcGFyYXRlIGRyYWZ0cyB3aGVyZSBwb3NzaWJsZSwgc2luY2Ug dGhpcyBtYWtlcyBpdCBlYXNpZXIgdG8gZXZvbHZlIHRoZSBtZXRyaWNzICh1cGRhdGUgZWFjaCBi bG9jayBzZXBhcmF0ZWx5KSwgYW5kIGFsc28gbWFrZXMgaXQgZWFzaWVyIHRvIHJlcXVpcmUgY29t cGxpYW5jZSB3aXRoIHBhcnRpY3VsYXIgcmVwb3J0cy4NCg0KQ29saW4NCg0KDQoNCk9uIDIgQXBy IDIwMTIsIGF0IDEzOjQzLCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4gV0csDQo+IA0KPiBU aGUgZGF0ZSBzZXQgYXMgZW5kIGZvciB0aGlzIFdHIGxhc3QgY2FsbCBoYXMgcGFzc2VkLiBIb3dl dmVyLCBJIHdpbGwNCj4ga2VlcCBpdCBvcGVuIHVudGlsIHRoZSBlbmQgb2YgdGhlIHdlZWsgdG8g bGV0IHNvbWUgbW9yZSBwZW9wbGUgY29tbWVudA0KPiBvbiBpdC4gSSBkbyBob3BlIHRoYXQgdGhl IFhSIGJsb2NrIHBlb3BsZSB3aWxsIHByb3ZpZGUgc29tZSBmZWVkYmFjayBvbiBpdC4NCj4gDQo+ IFRoYW5rcywNCj4gDQo+IE1hZ251cw0KPiANCj4gT24gMjAxMi0wMy0wNSAwODo0NCwgTWFnbnVz IFdlc3Rlcmx1bmQgd3JvdGU6DQo+PiBXRywNCj4+IA0KPj4gVGhpcyBpbml0aWF0ZXMgdGhlIFdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIE1vbml0b3JpbmcgQXJjaGl0ZWN0dXJlDQo+PiBmb3Ig UlRQIChkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMSkgdG8gYmUgcHVibGlzaGVkIGFzIElu Zm9ybWF0aW9uYWwNCj4+IFJGQy4gVGhlIFdHIGxhc3QgY2FsbCB3aWxsIHJ1biBmb3IgdGhyZWUg d2Vla3MgYW5kIGVuZCBNb25kYXkgdGhlIDI2dGguDQo+PiANCj4+IFRoZSBkcmFmdCBjYW4gYmUg cmV0cmlldmVkIGZyb20gaGVyZToNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLw0KPj4gDQo+PiBQbGVhc2UgcHJvdmlkZSBmZWVk YmFjayBpZiB5b3UgaGF2ZSByZWFkIGl0LCBldmVuIGlmIHlvdSBoYXZlIG5vDQo+PiBjb21tZW50 cyBvciB0aGluayBpdCBpcyBnb29kIGVub3VnaCwgdGhpcyBpcyBpbXBvcnRhbnQgaW5mb3JtYXRp b24gaW4NCj4+IGp1ZGdpbmcgdGhlIHN1cHBvcnQgYW5kIHJlYWRpbmVzcyBmb3IgcHVibGljYXRp b24uDQo+PiANCj4+IFRoYW5rcw0KPj4gDQo+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4gDQo+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFy Y2ggRUFCL1RWTQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAg ICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4+IEbkcvZnYXRhbiA2ICAgICAgICAgICAgICAg IHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58 IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0QGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPj4gDQo+ IA0KPiANCj4gLS0gDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0 NiAxMCA3MTQ4Mjg3DQo+IEbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3 MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4geHJibG9jayBtYWlsaW5n IGxpc3QNCj4geHJibG9ja0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3hyYmxvY2sNCg0KDQotLSANCkNvbGluIFBlcmtpbnMNCmh0dHA6Ly9jc3Blcmtp bnMub3JnLw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 From magnus.westerlund@ericsson.com Sun Apr 22 23:37:03 2012 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 7419B21F85CC for ; Sun, 22 Apr 2012 23:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 yIAK7ek-NCcJ for ; Sun, 22 Apr 2012 23:37:02 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10B21F85B9 for ; Sun, 22 Apr 2012 23:37:02 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-33-4f94f88cf49a Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 11.7E.26681.C88F49F4; Mon, 23 Apr 2012 08:37:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 23 Apr 2012 08:37:00 +0200 Message-ID: <4F94F880.9020701@ericsson.com> Date: Mon, 23 Apr 2012 08:36:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org, Robert Sparks References: <20120413092947.13599.84500.idtracker@ietfa.amsl.com> <55C2A6D92BB742ECACF7AF46BB3355E8@china.huawei.com> <4F88361A.6090507@ericsson.com> In-Reply-To: <4F88361A.6090507@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-17.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, 23 Apr 2012 06:37:03 -0000 WG, I have seen no objections against the changes. Therefore I state that the WG is satisfied with the editors changes in response to the IESG's comments. Robert, from the WG's perspective this is ready for publication. Cheers Magnus On 2012-04-13 16:20, Magnus Westerlund wrote: > WG, > > This version will not be approved for publication by the AD until after > the previous stated dead line of next Friday (20th of April). This way > you have the opportunity to review all the proposed changes resulting > from the IESG review. > > Cheers > > Magnus Westerlund > > > On 2012-04-13 11:53, Qin Wu wrote: >> On 13 April , 2012 5:29 PM, 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 : RTCP Extension for Third-party Loss Report >>> Author(s) : Qin Wu >>> Frank Xia >>> Roni Even >>> Filename : draft-ietf-avtcore-feedback-supression-rtp-17.txt >>> Pages : 19 >>> Date : 2012-04-13 >>> >>> In a large RTP session using the RTP Control Protocol (RTCP) feedback >>> mechanism defined in RFC 4585, a feedback target may experience >>> transient overload if some event causes a large number of receivers >>> to send feedback at once. This overload is usually avoided by >>> ensuring that feedback reports are forwarded to all receivers, >>> allowing them to avoid sending duplicate feedback reports. However, >>> there are cases where it is not recommended to forward feedback >>> reports, and this may allow feedback implosion. This memo discusses >>> these cases and defines a new RTCP third-party loss report that can >>> be used to inform receivers that the feedback target is aware of some >>> loss event, allowing them to suppress feedback. Associated SDP >>> signaling is also defined. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-17.txt >> >> Here is one minor update to feedback suppression draft based on comments during IETF LC and from Gen-Art Review: >> o Remove the discussion of improper dithering in the introduction section. >> o Change of the normative language from SHOULD NOT to MUST NOT in >> the protocol overview section. >> o Editorial changes based on Gen-ART review. >> o Move Example use case section before Protocol overview section. >> _______________________________________________ >> 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 magnus.westerlund@ericsson.com Mon Apr 23 03:57:36 2012 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 5582321F86C1 for ; Mon, 23 Apr 2012 03:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Y6ZD3ebHVDEz for ; Mon, 23 Apr 2012 03:57:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6E93C21F86AF for ; Mon, 23 Apr 2012 03:57:35 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-07-4f95359be7dd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 22.8B.03534.B95359F4; Mon, 23 Apr 2012 12:57:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Mon, 23 Apr 2012 12:57:31 +0200 Message-ID: <4F95358E.2040700@ericsson.com> Date: Mon, 23 Apr 2012 12:57:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Draft minutes 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, 23 Apr 2012 10:57:36 -0000 WG, Draft minutes for Paris are now available. Please review and provide feedback. http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm 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 iesg-secretary@ietf.org Mon Apr 23 12:05:00 2012 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 B89CC21E8012; Mon, 23 Apr 2012 12:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 oQePmrl0OEB4; Mon, 23 Apr 2012 12:05:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2C21E801B; Mon, 23 Apr 2012 12:05:00 -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.00 Message-ID: <20120423190500.11545.87704.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 12:05:00 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'RTCP Extension for Third-party Loss Report' to Proposed Standard (draft-ietf-avtcore-feedback-supression-rtp-17.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, 23 Apr 2012 19:05:00 -0000 The IESG has approved the following document: - 'RTCP Extension for Third-party Loss Report' (draft-ietf-avtcore-feedback-supression-rtp-17.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/ Technical Summary In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. Working Group Summary There is strong consensus among an adequate number of WG participants on this solution. Document Quality There are not yet any reported implementations. The document has had reasonable review. Personnel Magnus Westerlund is the document shepherd. Robert Sparks is the responsible AD From magnus.westerlund@ericsson.com Mon Apr 23 23:34:14 2012 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 CB1AF11E8097 for ; Mon, 23 Apr 2012 23:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.508 X-Spam-Level: X-Spam-Status: No, score=-104.508 tagged_above=-999 required=5 tests=[AWL=-1.588, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, 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 1mVaXrZ1-JIT for ; Mon, 23 Apr 2012 23:34:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BA25511E8081 for ; Mon, 23 Apr 2012 23:34:09 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-78-4f964960b0bf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.2A.03534.069469F4; Tue, 24 Apr 2012 08:34:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Tue, 24 Apr 2012 08:34:08 +0200 Message-ID: <4F964951.6070706@ericsson.com> Date: Tue, 24 Apr 2012 08:33:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <4F95358E.2040700@ericsson.com> In-Reply-To: <4F95358E.2040700@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: multipart/mixed; boundary="------------090303070409090204030205" X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 23 Apr 2012 23:38:46 -0700 Subject: Re: [AVTCORE] Draft minutes 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, 24 Apr 2012 06:34:14 -0000 --------------090303070409090204030205 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit WG, I have received a correction from Jonathan Lennox. When trying to upload the new version I found a bug in the meeting material manager. In trying to work around it I deleted the online version of minutes. Until a new version is available online please use the attached one. Cheers Magnus On 2012-04-23 12:57, Magnus Westerlund wrote: > WG, > > Draft minutes for Paris are now available. Please review and provide > feedback. > > http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 ---------------------------------------------------------------------- --------------090303070409090204030205 Content-Type: text/html; charset="WINDOWS-1252"; name="AVTCORE-IETF83-v3.html.htm" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="AVTCORE-IETF83-v3.html.htm"

AVTCORE IETF83 Minutes

Monday, 26th of March at 13.00-16.10 2012.

Note Takers: Brian Rosen, Charles Eckel

Chairs: Roni Even, Magnus Westerlund

Audio recordings:

·         http://www.ietf.org/audio/ietf83/ietf83-252b-20120326-1256-pm.mp3

·         http://www.ietf.org/audio/ietf83/ietf83-252b-20120326-1506-pm.mp3

1. AVTCore Status Update Chairs

The WG chairs provided a short status update after having covered the Note Well and the Agenda. The WG has had one RFC being published, three documents in IESG processing. draft-ietf-avt-srtp-ekt-03 have recently had some discussion on the list in relation to RTCWEB. draft-ietf-avt-srtp-aes-gcm-02 will progress after EKT. draft-ietf-avtcore-srtp-encrypted-header-ext-01 has finished WGLC. It will need to address comments before publication. draft-ietf-avtcore-monarch-11 is in WGLC.

The WG chairs made a milestone review. There were a number of milestone dates that was missed. Update proposed with new dates. There have also been proposals for new milestones, Overview of RTP security solutions, RTP clock source signaling, and SRTP crypto transform and key management based on ARIA algorithm.

The chairs also informed the WG about the change in Publication Request write-up (PROTO). This includes asking the authors about confirmation about IPR disclosures related to the document.

Magnus Westerlund also reminded the WG about the importance of filling in the blue sheets. One reason is so that we get the right sized room.

2. Why RTP Sessions Should Be Content Neutral

draft-alvestrand-rtp-sess-neutral-00

Harald Alvestrand presented his personal view around media flows, transport pairs and their relation to RTP session. Since RTP and SDP were published the amount of bandwidth capacity has gone up significantly and RSVP and Multicast hasn’t deployed. The network can provide prioritization. But that is only needed when you actually want prioritization. Harald claims that RFC 3550 is making a leap of faith. One being that media types align with desired prioritization. Section 5.2, bullet 4 (Slide 6) blind mixing only works for audio conferencing. If one does video one would not like to do blind mixing.

Cullen Jennings asked about the leap of logic, he can’t quite understand the argument. Harald answered that if you believe the statement, then a mixer with sufficient meta data could mix something nice out of 3 audio and 2 video streams. So if you don’t do it blindly the statement is false. Doing it blindly the statement is irrelevant. Colin Perkins followed up this questions saying that of course one can’t mix blindly. The argument in the RFC is that at the time of writing the appropriate method of providing the meta data needed was using transport streams. Harald responded that he thinks that argument is wrong.

Harald moved on to Section 5.2 bullet 5 (Slide 7). The prioritization between media streams are not function of top level media types it is of desired functionality. Dave Oran asked for a clarification about Harald’s assumption. Do you think “multiple media” in the sentence being multiple media types (audio and video) or multiple media streams? Harald couldn’t make head and tails of that and has assumed multiple media types. Dave Oran then commented that he and likely many others don’t by the crux of the argumentation because we are not agreeing with that interpretation. Harald replied that interpreting it as multiple media streams would preclude multiple SSRCs in one RTP session which no one has argued against. Roni Even commented that this list in the RFC 3550 is in the context of a discussion of multiple media types, not streams.

Harald moved on to Corrective Action (Slide 8). Thinks there is no need to change RTP and also the RTCP isn’t connected to the media type, rather media stream asymmetry. What is needed is SDP corrections. Those are underway in draft-ietf-mmusic-sdp-bundle-negotiation-00. Now time for discussion.

Tholis Eckert? did you establish and arguments why life would be better with RTP with what you want? Harald responded that the reason this was started was that in Google when they needed to establish four transport flows there was a high failure rate. This got much better by deploying RTP and RTCP multiplexing when only two flows where needed. Now we know what the cost is and therefore we want the possibility to go to one flow when it is appropriate.

Colin Perkins stated that have we had this conversation 15 years ago I might have actually agreed with everything you said. Unfortunately we have a fair amount of history with RTP and SDP. RFC 3550 is not the only thing impacted by this. This can work in some cases including the one you are interested in. There exist serious problems in other use cases. You appear to ignore these other cases. Need to document when it works and when it doesn't not only change the SHOULD in RFC 3550.  There are drafts that say where it's a problem. Harald responded that one level I do agree with what Colin said. The reason I went ahead with this is that there are cases which are argued against by this quote. This change of permission can’t render any existing application unusable. Colin asked, who is arguing against it, only seen recent arguments that it doesn’t work in all cases. Harald, then we can finish bashing in this open door and document this.

Cullen Jennings wondered what you are asking for. According to the slide we are on track to do things with all the issues that need work. Hadriel Kaplan sarcastically commented that if that one use case is sufficient for a solution, while all others need to do things generic. But stepping back, draft-ietf-mmusic-sdp-bundle-negotiation-00 is far from done. Also, this is a proposal of changing RTP which is what you want. Magnus Westerlund has another proposal of how to do multiple RTP sessions over a single transport (Solution B) which would be an alternative and we can do that. And Cullen commented that I don’t see the problem. Hadriel responded that the advantage of multiple RTP sessions over one transport  is that it support other use cases. Which also don’t want to create multiple transport flows but have multiple RTP sessions. For example, to simplify transcoding of the audio and not the video. Just add a sixth tuple so that one can separate them inside of the five tuple used today. Cullen responded that he wants to send the same RTP packets I send today on a single transport. Hadriel responded that this is actually not the same packet you sent yesterday. For example if using SRTP with a single RTP session there will be a single key for all media streams. Cullen responded that this is not in his slides. Cullen stated that Harald is arguing that all is fine, nothing needs to be done. Cullen doesn’t think that is what Harald really wants.

Roni Even (as WG chair) commented that one need to understand when it works and the limitations are. In the end what is important is that one understands when to use a single RTP session and when there is a need for multiple sessions. Hadriel asked if Roni thinks both solutions are needed. Roni responded that even if only one is needed it needs to be documented with its limitations. Colin Perkins commented that his proposal is that we do A and B and write yet another document to explain the trade-offs. Hadriel asked why would we do both if B solves all the cases and A has limitations? Colin agreed with that, but many don’t see these limitations as serious. Roni commented that B doesn’t use the same RTP as today. Colin concluded that we have been arguing about this for months and we are not agreeing. Thus let’s do both and document the trade-offs.

Hadriel asked the proponents for A if they really cared if it is A or B, doesn’t you just want the hammer? Is the two or one byte header that big a deal? Harald commented that on an architectural level we should not continue to enforce an unsound architectural choice. Desire that we do get the consensus of the AVTCORE WG so that we don’t need to have this discussion anymore. As a deployer I want to put audio and video in the same session without getting grief from AVTCORE. Hadriel asked as if you really care about one or multiple RTP sessions. Harald answered one due to lines of code. Hadriel responded that you anyway need to support multiple RTP sessions and thus already have the code. To add a session multiplexing layer would mean more lines of code. Hadriel responded that he believes that in the end it would be less lines of codes. Today you should have no code and supporting a multiplexing layer is; if supported, then read two bytes and send here. Harald responded that don’t you think we have implemented single session solution after such a long argument? Cullen Jennings commented that he doesn’t think this is a valid argument. We are arguing over 5 lines of code, when we are dumping many thousands of lines of code into the browsers.

Moving on to the next topic.

3. RTP Multiplexing Architecture - Magnus Westerlund

draft-westerlund-avtcore-multiplex-architecture-01

Was skipped, to allow for continued discussion around single transport multiplexing, i.e. next topic.

4. Multiple RTP Session on a Single Lower-Layer Transport - Magnus Westerlund

draft-westerlund-avtcore-transport-multiplexing-02

Starting time 49 minutes into first audio recording.

Magnus Westerlund (as individual) went into a presentation intended to drive discussion and achieve the goal of knowing which work should be done. Therefore there is quick check pretty soon and unless clear consensus exists we will go into the details. On slide 4 the options are presented; 1) Define a mechanism that enables multiple RTP sessions over a single lower layer transport. 2) Clarify the RTP specification and operation of a single RTP session with multiple media types in it. 3) Do both 1) and 2). 4) Do nothing.

Cullen Jennings commented that he didn't get the slide (4). Is option 1 include the option of adding a mux header, and the second using something like payload type to differentiate the media types. Magnus responded yes, the main goal he has is to have full RTP sessions with full RTP functionality. Cullen responded that he doesn’t know what an RTP session is. Magnus clarified that one really important function for option 1) is to have multiple RTP sessions, each having their full 32-bit SSRC spaces available for usage, including having the same SSRC value being used for different media streams in both session, which is not possible in option 2. Roni commented that this is part of the discussion in the multiplexing architecture document (draft-westerlund-avtcore-multiplex-architecture-01). Colin Perkins commented that the proposal in draft-westerlund-avtcore-transport-multiplexing-02 is to add a demultiplexing shim to realize option 1. The second option is basically to do what Harald proposes. Cullen asked, can you clarify what Harald is proposing? Magnus suggested that we should go through the details of the proposed work on slide 5.

Magnus presented his and Colin Perkins proposal to do option 3), i.e. doing both option 1) and 2). The details of what needs to be worked on are described on the slide. Cullen Jennings wonder what happened to the bundle proposal, i.e. take a bunch of stuff that are on different m= lines in the SDP and allow them to run on a single 5-tuple? Magnus answered that this is Harald’s, i.e. option 2. Cullen disagreed that there is a difference. Hadriel Kaplan supported Magnus view. Cullen followed up asking if there are two video cameras are they two m= lines? Magnus responded that it is possible but not necessarily and that has not been the main discussion point. The main discussion has been around having both audio and video in an RTP session. Cullen wants to get clarification on an easy thing, what about two video cameras. Magnus responded that this is not part of the discussion at all. Cullen responded that this what he got was different in the neutral discussion compared to how bundle currently stands. Magnus responded that he thinks the issue Cullen is after is how you represent in SDP when one end-point have multiple media sources. This issue hasn’t been much discussed at all. Cullen commented that he thought this is what was discussed when started down the bundle path. Magnus responded that he at least wasn’t discussing this issue. Magnus tried to conclude that the question of how you represent multiple media sources in an RTP session in SDP will still be there independent of the choices and proposals in this slide deck. Colin Perkins commented that it is important to separate the signaling issue from the RTP level issues. People have been putting multiple cameras in the same RTP session for 15 years. We might argue how you signal this but people have been doing this for a long time.

Colin Perkins reiterated the options. 1) We have the concept of RTP sessions and find them useful and like to keep them when transporting them over a single transport flow (5-tuple). There is also use cases for putting things together in the same RTP session that previously were  not, i.e. option 2), which some find useful and can make it work, like WebRTC. We also need a document that says what the issues and considerations are.

Harald stated that when he has been discussing bundle he hasn’t been discussing if an m= line should represent one, two or fifty sources of the same type. Magnus commented that it is good that at least Harald and he have been discussing the same thing. 

Richard Azack asked why can’t we have multiple unique sets of payload type and use these to determine which RTP session the packet belongs to when sending multiple RTP sessions over the same 5-tuple. Magnus answered that in most implementations you start at port level, the payload type indicates encoding, which would force one to use Port + PT as determination of RTP session. Colin Perkins commented that Richard should read draft-westerlund-avtcore-multiplex-architecture-01 for extensive discussion of why it wouldn’t work.

Magnus proposed that we do a consensus check to see if the discussion so far has accomplished anything. Roni Even is the one that judges the consensus, if any, and he shouldn’t call it unless it is very clear. Magnus iterated the choices. Cullen Jennings commented he doesn’t know what any of these questions mean. That we want to work on something around multiplexing is the only one that is clear and have been for several meetings. Roni Even clarified that all Magnus attempts to determine is how to go forward. Cullen Jennings stated a proposal for the WG. Let’s take the requirements people have expressed and analyze the drafts against these. Stop talking about sessions and transport and answer simple questions such as; can I send multiple video cameras over one UDP port? Can I offer multiple codecs for the same camera and switch between them without additional signaling? Can I run all my stuff on one port, two ports, N ports. Cullen couldn’t answer these questions for any of the proposals. Those should be clear to go forward. Colin Perkins answered that the answer to the first two questions is yes and have been for the last 15 years. The answer to the third one is what we try to decide. Roni added that both of the solution options can resolve question three, but we are trying to determine if we should do either or both.

Hadriel Kaplan commented that he hasn’t seen the advantages disadvantages between the options. From his perspective option 1 has advantages; don't know what they are for 2). Are we going have any slides on the advantages disadvantages? Are we voting without knowing the pro and cons? Magnus stated that he can present what the limitations are one the single RTP session, which is part of the slide deck. Hadriel commented that the only downside he knows of for 1) is the overhead (one or two bytes). That is what you are seeing on the wire commented Roni. From the point of the receiver it is two different streams. Which Hadriel commented is exactly what he has today. They are just demultiplexing this two bytes in, which is why it is simple, following the KISS principle. Roni responded that we today have both the single (multiplex inside) and the multi-session (multiplex on transport) cases, the only limitation that exist is the SHOULD NOT in RFC 3550 about audio and video in the same session. Hadriel responded that this is the big rub isn’t it? There are reasons, and what Harald is saying is that these may not be applicable to his use case. And this is only a should. So people for which a single RTP session with multiple media types are applicable can do it. Thus we would not need to develop what Magnus is proposing. However, there are still people thinking that it is needed… Hadriel commented that there are clear advantages to Magnus’ proposal. Hadriel is flabbergasted that people doesn’t understand how easy it is to add two bytes. The attribute issues we discussed in MMUSIC this morning. With Magnus proposal these all goes away as each m= line is still a separate RTP session. Roni responded that this is a question for MMUSIC. There is the question Cullen raised if one describe each SSRC as an individual m= line or have multiple SSRCs in a given m= line. Hadriel responded there aspects that matter in this group. For example by having separate RTP sessions there is separation of the RTCP reports also. Thus the reports are orthogonal and independent between the RTP sessions. In the single RTP session case the reports needs to be about different media types and one issue in fact the payload type relation on what one reports on. You are mixing oil and water and tries to get mayonnaise.

Jonathan Lennox commented first that a lot of the disconnect between Colin and Cullen is two models. The first one is the way RTP works in the head of the ones that designed RTP, meaning that you can have up to 2^32 SSRCs in an RTP session. Then it is the second model in which RTP works, the one being used by SIP which is one SSRC in each direction, end of the story. The one understanding the second gets confused over the first one. The ones understanding the first one gets confused over when people make statements following the second one, as the response from the first one is that of course they can do that. Jonathan prefers the first model, it has many benefits, unfortunately there is lot of SDP is designed according to the second model which is broken. This is MMUSIC’s problem. A second comment was to Hadriel, that these two bytes are only two bytes and having to rewrite anything that needs to look at the packet on the wire, like Wireshark and Deep Packet Inspection. It is mostly a question of who does the work; the people doing the media plane, or the ones doing the signaling plane. Hadriel clear do not want it to be him. Jonathan clearly don’t want it to be him either.

Paul Kyzivat commented that he doesn’t know enough to choose between the two options. But is concerned over doing both. If you do it both you will have lots more interoperability. One side do one and signal that and the other side do the other, we will have a mess. Magnus responded that a class of applications actually have to agree on which method they are going to use to avoid that issue. An application or class of applications must determine if they can accept the limitations of a single RTP session or actually need multiple RTP sessions. RTP is used in a wide variety of applications. Unfortunately a lot of them aren’t represented in this room. Paul commented that you assume that there are applications that are firewalled from each other? Magnus responded thatyes there are classes, like sensor networks or sensor data transport.

Cullen Jennings commented he would like to try to up level the discussion. Colin appear frustrated by the “this is signaling problem take it over there” and Cullen himself are frustrated that when he takes it to MMUSIC he is told to take it AVTCORE. And in AVTCORE he is told to take it to MMUSIC. And we are both the same people. RTP clearly is used in different context, and Cullen is interested in usage inside the RFC 3264 SDP Offer/Answer usage of RTP.  In this discussion we come up on cases that are non-compatible. It might be SDP O/A that is wrong, but independently that is irrelevant. We must consider what is built and deployed and what we need to interoperate with. That is the hard part of SDP and how to make this work together. Cullen wants to see clear descriptions of how we are going to interoperate with existing implementations. Magnus asked if what you are suggesting is to continue working on both tracks to get the real details of both proposals. Roni commented that the choices and what is need to be addressed in MMUSIC will be different depending on if you do only Multiple RTP sessions over a single transport or if you do multiple media types in a single RTP session or both. If we can come to a decision it would make it easier in MMUSIC. Magnus commented that if we follow the line Hadriel is arguing doing only Multiple RTP sessions over single transport then life in MMUSIC is likely easier. If we do both solutions, the choice between the solutions will be out of our hands, it will be in other places where the choice is made between the solutions. When it comes to “Multiple Media types in a single session” one way of looking at it is that it has really been SDP that enforced the SHOULD NOT, and as bundle is happening the limitation has already been released and it will happen. Personally I think it is doing both or only Multiple RTP sessions over a single transport. Doing nothing would in fact mean that we need to go kill bundle in MMUSIC so that there is no way of signaling multiple media types for a single RTP session.

Hadriel Kaplan followed up on Jonathan regarding Wireshark. Wireshark will have to be changed independent on which we do. Jonathan responded that this is not true as multiple SSRCs are already supported. Hadriel is that really true, can it really play back both audio and video in that single transport flow? [Confused partially off the mic comments]. Roni commented he thinks what we trying to accomplish is to have everything working that is currently within RFC 3550 and in addition allow multiple RTP sessions being transported on the same flow. Hadriel responded that isn’t true you are trying to have multiple media types in a single RTP session. Roni disagreed. Magnus supported Hadriels view and went on to comment. There are two different things but they are brought together by the commonality in enabling multiple media types over a single transport flow. Hadriel followed up saying that there are two choices for solving that problem. We either have a single RTP session with multiple media types and get all the issues in MMUSIC or we take what we have today and get an extra muxing a few bytes in, a 6-tuple instead of 5-tuple everything else stays the same. Of course it is going to be simpler for me, why do you think I am up at the mic. It will also be useful in other contexts, like SIP. Jonathan Lennox commented that this could be used in SIP. Hadriel responded, not realistically assuming SBCs. Hadriel went on to comments Magnus previous comments as being confusing. Of course we should always try to do only one thing? Roni commented that the previous decision in RTCWEB was to start with the single RTP session and then develop the multi session. Hadriel, responded that this is not their decision to make, they have to follow the decision made in AVTCORE and MMUSIC. If some vendors want to do it, then it is a proprietary solution. If I am held to the fire and have to come to this group and get things through then they will have to do the same. Cullen Jennings commented that it wasn’t some random group that decided what Roni said, it was this WG. Magnus stated that minutes for Quebec IETF says that we are to do both. It was Magnus that brought up the question of doing only one solution in Taipei, otherwise we would be further along the track to do both. Hadriel clarified that my statement that both will be in the marketplace anyway doesn’t matter, we IETF can decide which are standardized solutions and we can decided to do only one.   

Roni commented that in terms of RTP nothing prevents you from having multiple media types in a single RTP session. It is an SDP issue. What we can do in this WG is to capture what it means to do that. The text in RFC 3550 is that yes you can do it but be careful due to the following reasons. Roni’s interpretation of what Magnus says is that AVTCORE should document this. For the issues of doing it in SDP we need to discuss that and see if it works. There might be other signaling protocols where this works.

Harald commented with his process lawyers hat that WGs don’t get to override other WGs decisions. IESG is the ones that get to override. If RTCWEB makes a decision that is incompatible with AVTCOREs then we have some ADs with a headache. Harald’s personal architect hat comments that only doing Multiple RTP sessions over a single transport does solves Hadriel’s transport multiplexing, not Harald’s architectural issues. The decision of top level media type is still stupid and should be fixed no matter the cost. The implementor hat is that we will get something that works. Colin responded, surely you are not proposing that we fix every stupid IETF decision

Jonathan Lennox commented that we either can make RTP a bit uglier to work around SDP or we can make SDP uglier to work with RTP. Following Alice's Restaurant principal that one big pile of garbage is always better than two smaller piles of garbage, Jonathan thinks we should put the garbage on top of the existing garbage and make SDP uglier.

Jonathan’s second comment was that he don’t get the cases where multiple media types in one single RTP session doesn’t work. Either they haven’t been well explained or they don’t apply to real use cases. I am happy to do both as long as the use cases are good enough and someone else is happy to do the work. Magnus commented that he can present the two biggest limitations.

Magnus explained slide 10 pressing on that one want to establish a communication session with multiple participants or have a point to point session that goes through a media gateway. Assume that one client C and the central point are supporting and enables using multiple media types in a single RTP session. On the far side of the central point you have one or more clients not capable of using multiple media types in the same RTP session, instead they fall back to using different RTP sessions over independent transports. Thus you have SSRCs that comes from different RTP sessions that suddenly need to function in the context of a single RTP session without collisions. If they are colliding they force the need to do SSRC translation. SSRC translation is costly as it forces re-encryption of the content and forces the translator to be aware of all RTCP extensions being used in the RTP session to guarantee correct translation. Roni commented that it is an Mixer so it shouldn’t be a problem. Magnus answered that this is primarily for nodes that don’t do full processing of the media, such as transport translators, media gateways or RTP mixers that switches between sources. Jonathan commented that if these are offer/answers you can’t do that anyway (see later presentation). Roni also commented that he agrees with Jonathan if you are talking about RTP mixers they by definition present a different SSRC space to each leg. But Magnus are correct for a gateway. Magnus responded that in RTCWEB it appears that the limitation Jonathan talks about isn’t going to exist due to JSEP. Cullen Jennings asked why you can’t rely on the SSRC collision mechanism? Magnus responded that it might not work if client A uses the same SSRC on both RTP sessions, which is allowed as they are different sessions, then it will not see a collision. It is the merger of the RTP sessions that causes the collision. Colin Perkins also commented that there exists signaling that overrides the collision detection rules in RTP. Cullen responded that as Jonathan said if people are doing offer/answer this is not a problem. Colin responded that it is a problem if one does a=ssrc and the other isn’t, then you have a problem.

Richard Ejzak asked if there is negotiation between the client and the central node then it is clear if shall be used or not. Magnus responded that then it becomes a deployment problem. If one want to use a single RTP session you have to forklift upgrade your clients. The reason is that you negotiate the transport individually between the client and the central node. The goal is to agree locally if you can use it or not. Otherwise you will need to know that all clients that may join this particular session will support using a single transport.

Roni Even commented that we are running out of time and should try to give some guidance on how to proceed. Magnus brought up the Options slide and asked if anyone is a supporting the option to do nothing. No one supported that. Cullen commented that his understanding of the previous agreement is to do multiple media types in a single RTP sessions and then continue working on enabling multiple RTP sessions over a single transport. There is too little clarity to make a decision.

Justin Uberti commented that he thought that we had agreed that we have one proposal “Multiple Media Types in a single session” that works for a set of interesting use case. We can clear work on another solution that works for all use cases. But I thought we had agreed on doing “Multiple Media Types in a single session”. Magnus commented that he thinks that both Justin and Cullen in fact are arguing for the Proposal on slide 5. Justin responded that the agreement was for multiple SSRCs and a single port and potentially multiple media types. Colin Perkins commented that what he remembers we go forward with the proposal for multiple media types in a single RTP session. We also bring forward a proposal for multiple RTP sessions over a single transport. Which is what we are doing and we are saying that we should go forward with both of them.

Roni Even stated that we can’t guarantee that we will in the end be able to support all of them. After AVTcore WG makes a decision, and described the RTP aspects we will have to specify how to use them in SDP. And that will not happen here. We can only describe how to do both using RTP, not the signaling.

Jonathan Lennox commented that with the exception of Hadriel we appear to have some consensus for doing Option 3 (both) module the understanding of what three is, including continuing with individual submission for Multiple RTP sessions over a single transport.

Roni Even stated that for the single session that you will need to expand the architecture document to describe when it can be used without bias for Multiple RTP sessions. The Multiple RTP sessions needs a separate draft. Lennox commented that it clearly needs normative work. Single RTP session needs to remove the should and some descriptive work. Roni followed up that means it is an update to RFC 3550 in the end. Magnus stated that his understanding is that the people are saying doing both independently. There was proposed that the main proponents of different views would meet and figure out the document structure and who does the work? Roni asked if anyone was objecting? Documents will be not adopted at this stage, we first need to figure out the right set of documents. We are to progress with the assumption that we will update RFC 3550 in regards to the SHOULD and also continue with draft-westerlund-avtcoretransport-multiplexing-02. That is the direction we are going to take. Brian Rosen asked what about the part that describes single RTP session with multiple media types needs to discuss its limitations. Roni responded certainly. Roni concluded that we appear to have a consensus of how to progress. We also need discuss with MMUSIC how to deal with the SDP aspects.

5. RTP Congestion Control: Circuit Breakers for Unicast Sessions - Colin Perkins

draft-perkins-avtcore-rtp-circuit-breakers-00

Starts at 1:45:00 in the first audio recording

Colin Perkins presenting. The motivation is that RTCWEB is talking about congestion control, there are some proposal but it is a difficult problem. This works is about conditions where if encountered everyone in this room would agree is problematic and therefore should stop. Anyone using congestion control would always be within these limits.

Colin will also be talking about this in ICCRG’s second session on Tuesday.

The base assumption is RFC 3550 RTCP information. Future work will look into refining this using RTP extensions. Using RTT/Jitter every 5 seconds is too seldom. Packet loss statistics every 5 seconds is not good for congestion control but for overload detection is probably good enough. Two circuit breakers are proposed. The first one is timeout, no increased RTCP extended sequence number for two reporting intervals. The second breaker is if one gets 10 times the TCP throughput equation says an equivalent TCP connection would get.

There are open issues that need to be discussed. Include the assumption for the circuit breakers and if they in themselves are appropriate. The second major thing is around using any available RTP extensions.

Cullen Jennings commented that both look great. They are easy, implementable exactly what we need for circuit breakers. Think we (Cisco) tried this in our Telepresence equipment. Think that a single packet loss could result in that HD rates were not possible any more. Colin responded that it might be correct as the model is standard TCP and does not do high rates very well. But it is something we need to look into.

Flemming Andreasen asked if this assumes RTP packet losses are congestion? Colin responded yes, and clearly this is not always the case. If one can’t do the assumption how do we do a circuit breaker at all? Flemming responded that might mean that this isn’t applicable in all cases. Needs to be clear on this.

Harald Alvestrand asked if Colin have looked at some example numbers yet? Colin responded no, not yet. Harald had a second question regarding the packet size, appears odd that we would get lower throughput if we use smaller packets. Colin responded that there was the reduced size work for TFRC and we should consider taking that into account. Harald proposed that we could use the MTU for that. Colin responded that this is a slightly bigger issue and there was discussion for DCCP around this. Will look into this. Harald commented that it probably doesn’t matter much if we are aiming at hitting within a factor of 10 for this. Magnus commented that the question comes down to if one is byte or packet congested. Colin followed up that the things that use small packets are commonly audio which is lower bit-rate than video and thus less likely to cause congestion.

Tholios Eckert? asked what is the magic with 10 times the throughput? Colin responded that it is number picked out of thin air. Tholios asked if it the fairness argument, that RTP can do 10 times what TCP could over the same path. Colin responded that the proposal is not a congestion control algorithm it is a stop you are breaking things algorithm. The factor 10 is a number that makes it clear that it is significant more than what TCP gets and thus a clear sign that something is wrong. Tholios commented that 10 times is so unfair that you should give up. Colin stated that 10 is not set in stone it is a starting point for the discussion.

James Polk stated that he had sent an email to the RTCWEB Congstion list (rtp-congestion@alvestrand.no) and wonders if that was the right list to provide feedback. Colin think that list is the right one. He will reply to the question which had to do if the solution is for best effort only, and what if is not best effort, and multiple DSCP being used?

Magnus Westerlund (as chair) stated that this works appear to be very relevant for this WG. It will likely end up as part of congestion control discussions in a number of RTP extensions etc. This will be the outer limit on what can be done, and hopefully in the future we will see more fair, better etc algorithms. Colin responded that what is important is that we agree on that this type of draft is what we need to do. Then we can argue what the right content is. James Polk commented that if the transport area is spinning up a RTP congestion WG then this work will belong there. Magnus commented that until that happens AVTCORE appear a good home. The goal with this was to produce something quickly that RTCWEB could reference. We hope that the future WG will produce something that we more generally can reference in these cases. James asked Harald if he is motivated to get the WG spun up by Vancouver? Harald did acknowledge that.

6. RTP Topology Considerations for Offer/Answer-Initiated Sessions - Jonathan Lennox

draft-lennox-avtcore-rtp-topo-offer-answer-00

Presentation starts 1:59:00 into the first audio recording.

Jonathan Lennox presenting RTP Topology considerations for Offer/Answer initiated sessions. Offer/Answer (O/A) has two modes, one for multicast addresses and another for unicast (the more common). Jonathan has analyzed the topologies in RFC 5117 and all except one can be assembled from Offer/Answer unicast, the exception is Topo-Transport-Translator. The Topo-Transport-Translator is basically a relay of packets from one participant to all the others. This basically behaves like a multicast session would. For example all participants need to have a single view of the session. The rest of the topologies do some level of modification to the media, RTP packets or RTCP reporting. In essence the middlebox ensures that a given participant can understand what it sends from the other participants.

So why doesn’t Topo-Transport-Translator work with O/A? Where the topology requires a common session configuration, unicast O/A allows each end-point to establish its own view of the session. Some examples from the core of SDP O/A are 1) Bandwidth. When you send an Offer you express the bandwidth you want to receive. When the answerer sends an answer it expresses what it want to receive. These values are used to determine what the RTCP bandwidth is using the 5% rule. If the two end-points express significantly different values you end up with different RTCP reporting intervals and timeout values. In a session where a common view needs to be established, no-one can tell what the common value is to be as there exist no obvious answer. 2) Media Types. Participants remove media types (Payload Types) from an offer in the answer or updated Offer. An answer can even renumber the payload type numbers used for a given configuration. 3) There exist additional parameters such as ptime and many SDP extensions that will have issues.

The above is a good thing, as you know that you in fact are only talking to one other party. That may be forwarding or rewriting other participant’s media, but you can optimize for this case. Thus you can make optimizations which aren’t possible if you blindly are talking to a large group of participants. Colin Perkins commented that everything except transport translators and multicast. Jonathan agreed as multicast do have special rules in SDP O/A and can detect that. It doesn’t know about transport translators.

When you have asymmetric bandwidth the optimization you can do is to have the peer use 5% of my receiver bandwidth towards me, and I will use 5% of your receiver bandwidth towards you. Timeout is calculated accordingly. We also resolve the issue that if A uses one SSRC and B 5 SSRCs, then B adds another SSRC, then A’s bandwidth is reduced, despite it not being shared with any other SSRC in this direction. They are not rivals for the same bitrate capacity.

RTCP receiver reports. In a RTP session all receivers sends reports on all senders. In a many to many session this goes towards number of reception reports being quadratic to the number of session members. If you are actually talking to the same person they are basically useless. Colin Perkins asked for clarification that they will be stacked up in the same packet. Jonathan agreed, but when you are on the order of 150 participants, they can’t be stacked up into the same packet due to MTU. Colin commented that in that case you are round-robin between the SSRC on which you report. Jonathan responded that starts to slow things down. The point is that the middlebox is consuming most of the RTCP reports itself. So the current rule uses up RTCP bandwidth that could otherwise be used for more useful and timely things. If you have multiple sources coming from the same end-point, having them report on each other is completely useless.

Normative recommendations for unicast SDP offer/answer

·         RTCP bandwidth and timeouts MUST be calculated independently in each direction

·         endpoints SHOULD NOT send reports from their own sources

·         endpoints SHOULD pick single reporting source to send reception reports

Way forward:

Colin Perkins agrees that there is an issue with RTCP bandwidth and asymmetric paths. We have known about this a long time but no one has been annoyed sufficiently to do something about it. For the other two points, he believes that the end-points must send reports. The whole point of the transport translator is that it behaves as a multicast group, so don't try to change it; if you do not want this, use another topology (e.g. terminate RTP session on the mixer). Jonathan responded that the point is that I know I am using one of the other models. Explicitly then use one of the other topologies so that you don’t see all the other SSRCs and don’t have to report on them. Don’t change the definition of RTP so it breaks. Jonathan responded that even if you are terminating RTP sessions on the mixer but are sending a lot of sources in each terminated session you still have the same problem. If I have 150 SSRCs in a session and you’re the peer with 150 SSRCs we do have 150^2 reporting blocks. Colin, but then use an RTP mixer so that you don’t have as many SSRCs. Jonathan responded, we are not using an mixer, I am exaggerating a bit, but we are seeing this problem. Colin Perkins responded that having built such a system 15 years ago without any issue what is the problem? Bandwidth is cheap. Jonathan responded that he don’t like complexities that are O(N^2). But it ends up being wasted/stealing from more important things. Colin responded, then configure your bandwidth fraction sensibly. Jonathan responded that he can’t send his feedback in a timely and frequent fashion. Colin responded, you have 150 reporting intervals, send them on any of them. Use AVPF, don’t see the problem.

Joerg Ott commented that you might want to engineer this off-line. This looks interesting but don’t know if it is the right suggestions. Joerg has looked at more complex overlay structures using RTCP point to point in segments. Jonathan responded that he wants to know more about Joerg’s use case.

Magnus Westerlund (as individual) thinks the problem should be split up. We should at least clarify how entities with multiple sources should behave. The second two bullets (Slide 15) apply to all the topologies. Jonathan responded that there is a difference between transport translator and multicast and the rest. Magnus followed up that one of his main concerns is that we shouldn’t have different behaviors depending on topology. If one clarifies how any end-point with multiple SSRCs are to behave it will apply to all topologies. Magnus also supported looking into the asymmetric bandwidth, but the WG should target generic solutions that aren’t specific to offer/answer. Please remember that we have other usages of RTP that aren’t established O/A signaling. Jonathan asked if they apply asymmetric bandwidth. Magnus responded yes. Jonathan commented that he think in that case you can’t do a transport translator. Magnus thinks dividing the proposals up into independent pieces which can each be discussed on their own merits is the way forward.

Harald Alvestrand asked if the last two bullets on slide 15 are clarifications or changes. Jonathan responded that it is probably a question in debate. Jonathan has a way of constructing it so that it is within the spec if you assume a weird internal topology. Harald responded that he has worked with an engineer trying to interpret RFC 3550 rules and several times thought they can’t mean that. So please clarify. Jonathan followed up that the bullets can be interpreted so that the local SSRCs can’t see each other and therefore can’t report on each other. The issue is that if the other side looks at this, it can think the network is broken as 2/3 of the sources can’t see me. If they know you are doing this it is not a problem. Colin commented that is the issue. There are devices that will think this is broken. Jonathan asked, are they devices that can use offer/answer. Colin responded that he don’t think O/A is the right thing to think about. Joerg Ott commented that you need to clarify what you think your co-located sources are. There is work on SIP end-point decomposition ongoing, so you don’t quite know how well the thing you suppose is sitting next to you really can talk to you or not. Please keep this in mind when you go through this.

7. Multipath RTP
Varun Singh, presented by Joerg Ott

draft-singh-avtcore-mprtp-04

Starts 19 min into the second audio recording.

Joerg Ott presenting Multipath RTP proposal. The authors have received quite a lot of comments, mostly about signaling.  Recap and summary of updates since -02.

Two mechanisms to convey interface information; an RTCP based inband and a SDP based out of band. SDP takes precedence over RTP.

Implemented multipath to test a bandwidth distribution algorithm.  Results of single path vs. multiple paths, if enough capacity, both work well. Similarly; as loss increases multipath helps.

Next steps

-          Turn into WG item?

-          Add security considerations.

-          Double-check with mmusic.

Currently the draft is targeted for experimental RFC.

Roni as Chair: Is the AVTCORE WG interested in a WG item working on an experimental multipath solution? Jonathan Lennox commented this is more forward looking than most care about immediately, but will be useful in near future. Inclined to support this work. Joerg Ott one additional target deployments are multicast overlays for streaming is one place. Magnus, as Chair: not strong support, but will check on list as well. As long as someone drives it is necessary, but we also need some from the community that review and comment on the work.

8. RTP Clock Source Signaling
Aidan Williams

draft-williams-avtcore-clksrc-00

Starts 28 minutes into second audio recording.

Aidan Williams presents the new draft on RTP Clock Source signaling. The draft is a result of discussion at IETF 82. Several people had interest in this so making it a general building block is a good idea.  IDMS and AVB sync both had SDP signaling for clock source, combined into this document. Need mechanism to provide explicit SDP signaling of NTP timestamp clock source.

Motivations are that a single reference clock used to create NTP timestamps in RTP protocols in a end-point. No indication currently of which clock is being used. Use cases include social tv, video walls, networked audio, and sensor arrays.

Using SDP to let end-points describe what clock source they are using. IP addresses, EUI-64, … Definition of equivalent clocks is also given. Can describe various clock types, NTP, 1588 family, GPS, local. There is also a concept of Traceable clock. If you can track it back to a global time source.

Going through the example on Slide 7. Ted Hardie asking If you have NTP attr on one m-line, shouldn't it be on all of them, i.e. session level? NTP is after all a system level time source. Aidan responded that this is an artificial example in slide. Commonly you would have one for the whole session. Ted followed up that he wanted to be certain that a receiver of the SDP would not make a decision on the m= lines based on time source as the same time source would be available on to all m= lines. Aidan responded that for a given system yes. We want to be able to detect systems that aren’t using the same clock source or master clock. Ted commented that in this emitter case are you presuming that if I have a video source it may have a different time source that the general system time source? Aidan confirmed that could occur. Jonathan Lennox commented that in the case of disaggregated media you might not actually want different clock source and should actually raise an alarm. Ted asked if there is a method for interrogating the sources of disaggregated media for their time source. Aidan responded that he was not aware of any standard mechanisms.

Toerless asked if you expect it to become reference for any upcoming work. This works appears to allow end-points to determine if they are synchronized or not in a binary fashion, possibly even how desynchronized. Is it up to these end-points what they can do with that. Aidan responded yes, that is what it provides. IDMS is the most immediate use case. Aidan clarified that he himself is primarily in the synchronized audio playback case. Toerless asked if the end-points will have well defined behavior depending on if they are synchronized or not. Aidan responded yes, for a synchronized audio playback a device would probably mute, but this will be application dependent. Toerless asked if this actually help if one only has a local clock? Can I calculate the drift and use that somehow? Aidan responded that what really helps is the knowledge if the sender and receiver have a synchronized time base or not.

Magnus as Chair asked the WG if there is interested in working on a solution within IETF in this WG. There was some interest indicated through raised hands. The reason asking the question in very general terms was that the chairs needs to discuss with Ads and MMUSIC WG chairs if it is appropriate to take the work on.

9. RTCP for inter-destination media synchronization
Ray van Brandenburg

draft-ietf-avtcore-idms-03

Starts 43 min into second audio recording.

Ray van Brandenburg provided a short status update. Using synchronized clocks with IDMS improves performance but is not necessary. Clock source signaling has been moved out as an optional but normative reference. Risk that this delays IDMS. Other changes are clarified terminology, dealing with leap seconds, and general editorial clean up. Think it is ready for WG last call.

Colin Perkins asked if the leap second issue is IDMS specific or a general clarification to RFC 3550. Ray responded that it is applicable to any use cases requiring tight synchronization. It could be a clarification on RFC 3550. Currently there is a general remark in the clock source draft and a more specific one in IDMS. So based on your comment we might need an even more general for RFC 3550. Colin responded, that yes if this will affect others than IDMS then making it a very short draft updating RFC 3550 that IDMS can reference. Ray agreed to look into creating such a draft.

Glen Zorn was curious why reference to clock source draft needs to be normative? Ray responded that his interpretation of the normative vs. informative guidance is clear that an optimal but performance improving part should be normative reference. Glen commented, that the clock synchronization is optional. Magnus Westerlund (as chair) stated that even for optional parts, if you do need to understand the reference to implement it, it is still a normative reference. Glen was skeptical clearly normative if you need to understand it to implement it and be compliant. But in this case it is optional and thus you don’t need it to be compliant. Magnus responded that it depends on the use case and an implementer may actually have to include this optional part.

Roni Even concluding as chair; First thing is to write leap second as separate draft applicable to RFC 3550. Secondly, regarding the WG last call we can go ahead without clock source but the final publication will be held until the clock source is available.

10. Duplicating RTP Streams  
Ali Begen

draft-begen-avtcore-rtp-duplication-01

Starts 51 min into the second audio recording.

Ali Begen presented this individual proposal which last was presented in Taipei. Duplication of RTP stream and RTCP reports is not well specified, this draft addresses that need. Temporal (time shifted) redundancy use case. The SDP using SSRC grouping to indicate the duplication. When doing spatial redundancy the SDP uses media stream (m=) grouping, plus use of cname and srcname (draft-westerlund-avtext-rtcp-sdes-srcname-00) to indicate which SSRCs in the different RTP sessions that are duplication of each other. This is necessary if there is more than one SSRC from a given cname.

One remaining issue, if stream merging happens inside network element, how to deal with it. Propose treating as mixer. Roni Even commented (as individual) that it appears to be the same issue as for the AVTEXT WG item draft-ietf-avtext-splicing-for-rtp-07. Colin Perkins commented that both a mixer and translator would work, there is slightly different trade-offs. The Mixer makes it visible and lets you report and the translator makes it invisible and don’t lets you report. Jonathan Lennox commented that it appears what is happing is that one takes two streams and mixes them. Unless you deliberately try to hide this use a mixer. Roni (as individual) asked for clarification that when Ali said merge it resulting stream will include packets from both streams. A mixer will result in only one outgoing SSRC.

Ali asked for adoption of this draft in AVTCORE WG. They are already working on getting the signaling part adopted in MMUSIC. Magnus Westerlund (as chair) asked Ali if he believes that the push back raised previously has been resolved about the utility of duplication? Ali responded that the push back has been around why you wouldn’t use FEC instead and those have been well explained in the draft. Roni also commented that another issue was around congested paths. Ali commented that this is not the intended usage to address congested paths. Magnus called for a hum of who are interested in this as a WG item. A fair amount of people supporting a WG item, none against, the chairs will take to list.

End of meeting.

 

--------------090303070409090204030205-- From magnus.westerlund@ericsson.com Tue Apr 24 06:13:53 2012 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 A516921F8821 for ; Tue, 24 Apr 2012 06:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.12 X-Spam-Level: X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Mp5n42tQiJgA for ; Tue, 24 Apr 2012 06:13:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CCF1921F8808 for ; Tue, 24 Apr 2012 06:13:52 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-1e-4f96a70f88eb Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6D.A0.03534.F07A69F4; Tue, 24 Apr 2012 15:13:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 24 Apr 2012 15:13:51 +0200 Message-ID: <4F96A6FF.3000302@ericsson.com> Date: Tue, 24 Apr 2012 15:13:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org, Colin Perkins , "Charles Eckel (eckelcu)" References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> In-Reply-To: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Tue, 24 Apr 2012 13:13:53 -0000 WG, Colin and Charles This version intends to address the WG last call comments. I would recommend that people review the changes. I will give people a week to review this. Please provide any feedback on the changes no later than 1st of May. Cheers Magnus On 2012-04-18 05:58, 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 : Monitoring Architecture for RTP > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-12.txt > Pages : 29 > Date : 2012-04-17 > > This memo proposes an architecture for extending RTP Control Protocol > (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to > report new metrics regarding media transmission or reception quality, > following RTCP guideline established in RFC5968. This memo suggests > that a new block should contain a single metric or a small number of > metrics relevant to a single parameter of interest or concern, rather > than containing a number of metrics which attempt to provide full > coverage of all those parameters of concern to a specific > application. Applications may then "mix and match" to create a set > of blocks which covers their set of concerns. Where possible, a > specific block should be designed to be re-usable across more than > one application, for example, for all of voice, streaming audio and > video. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt > > _______________________________________________ > 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 magnus.westerlund@ericsson.com Tue Apr 24 06:18:18 2012 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 5CA7621F84EC for ; Tue, 24 Apr 2012 06:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.123 X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 4-x61hrt050f for ; Tue, 24 Apr 2012 06:18:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF3A21F87BD for ; Tue, 24 Apr 2012 06:18:17 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-08-4f96a817d5b1 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CA.87.26681.818A69F4; Tue, 24 Apr 2012 15:18:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 24 Apr 2012 15:18:02 +0200 Message-ID: <4F96A7FA.6030901@ericsson.com> Date: Tue, 24 Apr 2012 15:17:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> In-Reply-To: <4F96A6FF.3000302@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Tue, 24 Apr 2012 13:18:18 -0000 Authors, I have reviewed the latest changes and do wonder if the proposed formulations really are the correct one. Full diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-12 Section 5.2: Report blocks that require such correlation need to include the payload type of the reported media, and must signal details and parameters of the payload format to which that payload type is bound. I think my grief with the above sentence is the second half. I don't find it appropriate that each report block include details and parameters of the the payload format. I think the approriate level is to include the payload type and use the functions you anyway have for associating signalling with media session capture to store the actual parameter? 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 ron.even.tlv@gmail.com Tue Apr 24 13:03:21 2012 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 2C3D621E802C for ; Tue, 24 Apr 2012 13:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 Sj5OfdwxqOip for ; Tue, 24 Apr 2012 13:03:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6659B21E8011 for ; Tue, 24 Apr 2012 13:03:20 -0700 (PDT) Received: by werb10 with SMTP id b10so834101wer.31 for ; Tue, 24 Apr 2012 13:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=DUKMixJJMO1yvOkB5+TGquZFPhLmuIcW/RRXA8GSJDM=; b=lpHoMPBKzMRA6oKiZEDzLrsGPXE2HULnWVoPQPUXS7UkxBlH7kiY27Ob9k2riUJS5h Yd+GSDD1tPSCu0HyCdNW9gudUZFC5Ig8PjzTjNUutSsyb3tO4IBxhcBhWu6DcQGUl2T/ mOQ26MCq7KBwyUcH647X/GReEnNAICbE07NSJZVCZinh0TDnA8fijVsQKmGIqnlTSs6U Fa2Bq+cETxg23ujhAlcCpDw8PqEQmPerJJxrReNkpqOd0ciSQakOrcQIsG2qx8W8pooQ VHYi7/O8EeXmCPiEW+1JlrvLScfIqgbtr+ulnFu7x7o15bJ7KUEixDjE13MeJM4sdogo Redg== Received: by 10.216.134.41 with SMTP id r41mr3765292wei.13.1335297799510; Tue, 24 Apr 2012 13:03:19 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id k6sm31935024wie.9.2012.04.24.13.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 13:03:17 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> <4F96A7FA.6030901@ericsson.com> In-Reply-To: <4F96A7FA.6030901@ericsson.com> Date: Tue, 24 Apr 2012 23:01:34 +0300 Message-ID: <4f970705.2614b40a.2a54.72ef@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0iHLoV3Rv8tW/KRBq9DVBz3LYYmwAOBAwA Content-Language: en-us Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Tue, 24 Apr 2012 20:03:21 -0000 Hi Magnus, I think that one reason for having the information in the RTCP report = may be for RTCP monitors who just see the RTCP messages and not the signaling. Anyhow it is relevant to codec metrics and not to the transport metrics Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Tuesday, April 24, 2012 4:18 PM > To: avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-12.txt >=20 > Authors, >=20 > I have reviewed the latest changes and do wonder if the proposed > formulations really are the correct one. >=20 > Full diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-12 >=20 > Section 5.2: > Report blocks that require such correlation need to include the = payload > type of the reported media, and must signal details and parameters of > the payload format to which that payload type is bound. >=20 > I think my grief with the above sentence is the second half. I don't > find it appropriate that each report block include details and > parameters of the the payload format. I think the approriate level is > to include the payload type and use the functions you anyway have for > associating signalling with media session capture to store the actual > parameter? >=20 > Cheers >=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 bill.wu@huawei.com Tue Apr 24 19:34:34 2012 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 E5C6A11E8074 for ; Tue, 24 Apr 2012 19:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 Q8KZuWYjjyq4 for ; Tue, 24 Apr 2012 19:34:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8521E8012 for ; Tue, 24 Apr 2012 19:34:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE77369; Tue, 24 Apr 2012 22:34:33 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:32:47 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:32:51 -0700 Received: from w53375 (10.138.41.149) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 10:32:45 +0800 Message-ID: From: Qin Wu To: Magnus Westerlund , References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com><4F96A6FF.3000302@ericsson.com> <4F96A7FA.6030901@ericsson.com> Date: Wed, 25 Apr 2012 10:32:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 25 Apr 2012 02:34:34 -0000 SGksIE1hZ251czoNClRoYW5rIGZvciB5b3VyIGNvbW1lbnQsIHBsZWFzZSBzZWUgbXkgcmVwbGll cyBpbmxpbmUuDQoNCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPkZyb206ICJNYWdu dXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCj5UbzogPGF2 dEBpZXRmLm9yZz4NCj5TZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiA5OjE3IFBNDQo+U3Vi amVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJj aC0xMi50eHQNCg0KDQo+QXV0aG9ycywNCg0KPkkgaGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IGNo YW5nZXMgYW5kIGRvIHdvbmRlciBpZiB0aGUgcHJvcG9zZWQNCj5mb3JtdWxhdGlvbnMgcmVhbGx5 IGFyZSB0aGUgY29ycmVjdCBvbmUuDQoNCj5GdWxsIGRpZmY6DQo+aHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMg0KDQo+U2VjdGlv biA1LjI6DQo+UmVwb3J0IGJsb2NrcyB0aGF0IHJlcXVpcmUgc3VjaCBjb3JyZWxhdGlvbiBuZWVk IHRvIGluY2x1ZGUgdGhlIHBheWxvYWQNCj50eXBlIG9mIHRoZSByZXBvcnRlZCBtZWRpYSwgYW5k IG11c3Qgc2lnbmFsIGRldGFpbHMgYW5kIHBhcmFtZXRlcnMgb2YNCj50aGUgcGF5bG9hZCBmb3Jt YXQgdG8gd2hpY2ggdGhhdCBwYXlsb2FkIHR5cGUgaXMgYm91bmQuDQoNCj5JIHRoaW5rIG15IGdy aWVmIHdpdGggdGhlIGFib3ZlIHNlbnRlbmNlIGlzIHRoZSBzZWNvbmQgaGFsZi4gSSBkb24ndA0K PmZpbmQgaXQgYXBwcm9wcmlhdGUgdGhhdCBlYWNoIHJlcG9ydCBibG9jayBpbmNsdWRlIGRldGFp bHMgYW5kDQo+cGFyYW1ldGVycyBvZiB0aGUgdGhlIHBheWxvYWQgZm9ybWF0LiANCg0KW1Fpbl06 IFR3byB0aGluZ3MgSSBsaWtlIHRvIGNsYXJpZnk6DQphLiBOb3QgZWFjaCB0aGUgcmVwb3J0IGJs b2NrIG5lZWRzIHRvIGluY2x1ZGUgcGF5bG9hZCBmb3JtYXQgcmVsYXRlZCBwYXJhbWV0ZXJzLg0K T25seSBjb2RlYyBkZXBlbmRlbnQgcmVwb3J0IGJsb2NrIGRvZXMuIGUuZy4sIHJlcG9ydCBibG9j a3MgdGhhdCBzdXBwb3J0IG11bHRpLWNoYW5uZWwgDQphdWRpbyBvciBtdWx0aS1sYXllciB2aWRl byBkZWZpbmVkIGluIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZSBpbmNsdWRlcyBjb2Rl YyBkZXBlbmRlbnQgbWV0cmljcy4NCg0KYi4gU3VjaCByZXBvcnQgYmxvY2tzIG9ubHkgbmVlZCB0 byBpbmNsdWRlIHBheWxvYWQgdHlwZSBhbmQgZG9uJ3QgbmVlZCB0byBpbmNsdWRlDQpkZXRhaWxz IGFuZCBwYXJhbWV0ZXJzIG9mIHRoZSBwYXlsb2FkIGZvcm1hdC4gVGhlIHNpZ25hbGluZyBtYXkg YmUgbmVlZGVkIHRvIA0KYXNzb2NpYXRlIGRldGFpbHMgYW5kIHBhcmFtZXRlcnMgb2YgcGF5bG9h ZCBmb3JtYXQgd2l0aCBzdWNoIHJlcG9ydCBibG9jaywgZS5nLiwNCmluIHRoZSBtaWRkbGUgb2Yg c2Vzc2lvbiwgcGF5bG9hZCBmb3JtYXQgY2hhbmdlcy4NCg0KPkkgdGhpbmsgdGhlIGFwcHJvcmlh dGUgbGV2ZWwgaXMgdG8NCj5pbmNsdWRlIHRoZSBwYXlsb2FkIHR5cGUgYW5kIA0KDQpbUWluXTog VGhhdCdzIHdoYXQgY3VycmVudGx5IHNlY3Rpb24gNS4zIHNhaWQuIFRoZSByZWFzb24gdG8gYWRk IHBheWxvYWQgdHlwZSBpcyBmb2xsb3dpbmcNCnRoZSBQYXJpcyBkaXNjdXNzaW9uIGFib3V0IFFv RSBtZXRyaWNzLCB3ZSB0aGluayBRb0UgZm9yIGEgc2luZ2xlIHN0cmVhbSB3aWxsIGFsc28gZGVw ZW5kIA0Kb24gdGhlIHBheWxvYWQgZm9ybWF0IGluIHVzZSwgYW5kIHdpbGwgYmUgbWVhbmluZ2xl c3MgdW5sZXNzIHRoYXQgcGF5bG9hZCBmb3JtYXQgaXMga25vd24uIA0KDQo+dXNlIHRoZSBmdW5j dGlvbnMgeW91IGFueXdheSBoYXZlIGZvcg0KPmFzc29jaWF0aW5nIHNpZ25hbGxpbmcgd2l0aCBt ZWRpYSBzZXNzaW9uIGNhcHR1cmUgdG8gc3RvcmUgdGhlIGFjdHVhbA0KPnBhcmFtZXRlcj8NCg0K W1Fpbl06IFdoYXQncyB0aGUgZGlmZmVyZW5jZSB3aXRoIHdoYXQgc2VjdGlvbiA1LjMsIHNlY29u ZCBoYWxmIHBhcnQgc2FpZD8NClRoZSByZWFzb24gdG8gc2F5ICJtdXN0IHNpZ25hbCBkZXRhaWxz IGFuZCBwYXJhbWV0ZXJzIG9mDQp0aGUgcGF5bG9hZCBmb3JtYXQgdG8gd2hpY2ggdGhhdCBwYXls b2FkIHR5cGUgaXMgYm91bmQiIGlzIGJlY29zDQoNCkZvciBvbmUgUlRQIHNlc3Npb24sIHRoZXJl IG1heSBoYXZlIG11bHRpcGxlIHBheWxvYWQgZm9ybWF0cyBiZXR3ZWVuDQpSVFAgcGFydGljaXBh bnRzIHRoYXQgY2FuIGJlIG5lZ290aWF0ZWQsIHRoZSBwYXlsb2FkIGZvcm1hdCBtYXkgY2hhbmdl cyANCmluIHRoZSBtaWQtc2Vzc2lvbiwgaW4gc3VjaCBjYXNlcywgc29tZSBraW5kIG9mIG1lY2hh bmlzbXMgYXJlIHJlcXVpcmVkIHRvIHNpZ25hbCB3aGF0IA0KcGF5bG9hZCBmb3JtYXQgd2FzIGlu IHVzZSBmb3IgdGhlIHJlcG9ydGluZyBpbnRlcnZhbC4NCg0KSWYgSSBtaXNzIGFueXRoaW5nLCBw bGVhc2UgbGV0IG1lIGtub3cuDQoNCg0KPkNoZWVycw0KDQo+TWFnbnVzIFdlc3Rlcmx1bmQNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJj aCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+RXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQ aG9uZSAgKzQ2IDEwIDcxNDgyODcNCj5G5HL2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmls ZSArNDYgNzMgMDk0OTA3OQ0KPlNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5z cG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0 From bill.wu@huawei.com Tue Apr 24 19:35:02 2012 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 0CB3C21E802D for ; Tue, 24 Apr 2012 19:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 AZVeQlOctZNR for ; Tue, 24 Apr 2012 19:35:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 649FE21E8012 for ; Tue, 24 Apr 2012 19:35:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFM79648; Tue, 24 Apr 2012 22:35:01 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:33:23 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:33:26 -0700 Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 10:33:19 +0800 Message-ID: From: Qin Wu To: Roni Even , 'Magnus Westerlund' , References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com><4F96A7FA.6030901@ericsson.com> <4f970705.2614b40a.2a54.72ef@mx.google.com> Date: Wed, 25 Apr 2012 10:33:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 25 Apr 2012 02:35:02 -0000 WWVzLCBJIEFncmVlLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJSb25pIEV2ZW4iIDxyb24uZXZlbi50bHZAZ21haWwuY29tPg0KVG86ICIn TWFnbnVzIFdlc3Rlcmx1bmQnIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPjsgPGF2 dEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgNDowMSBBTQ0KU3Vi amVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJj aC0xMi50eHQNCg0KDQpIaSBNYWdudXMsDQpJIHRoaW5rIHRoYXQgb25lIHJlYXNvbiBmb3IgaGF2 aW5nIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgUlRDUCByZXBvcnQgbWF5IGJlDQpmb3IgUlRDUCBt b25pdG9ycyB3aG8ganVzdCBzZWUgdGhlIFJUQ1AgbWVzc2FnZXMgYW5kIG5vdCB0aGUgc2lnbmFs aW5nLg0KQW55aG93IGl0IGlzIHJlbGV2YW50IHRvIGNvZGVjIG1ldHJpY3MgYW5kIG5vdCB0byB0 aGUgdHJhbnNwb3J0IG1ldHJpY3MNClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBhdnQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gU2VudDogVHVlc2RheSwg QXByaWwgMjQsIDIwMTIgNDoxOCBQTQ0KPiBUbzogYXZ0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTIudHh0 DQo+IA0KPiBBdXRob3JzLA0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgY2hhbmdl cyBhbmQgZG8gd29uZGVyIGlmIHRoZSBwcm9wb3NlZA0KPiBmb3JtdWxhdGlvbnMgcmVhbGx5IGFy ZSB0aGUgY29ycmVjdCBvbmUuDQo+IA0KPiBGdWxsIGRpZmY6DQo+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTINCj4gDQo+IFNl Y3Rpb24gNS4yOg0KPiBSZXBvcnQgYmxvY2tzIHRoYXQgcmVxdWlyZSBzdWNoIGNvcnJlbGF0aW9u IG5lZWQgdG8gaW5jbHVkZSB0aGUgcGF5bG9hZA0KPiB0eXBlIG9mIHRoZSByZXBvcnRlZCBtZWRp YSwgYW5kIG11c3Qgc2lnbmFsIGRldGFpbHMgYW5kIHBhcmFtZXRlcnMgb2YNCj4gdGhlIHBheWxv YWQgZm9ybWF0IHRvIHdoaWNoIHRoYXQgcGF5bG9hZCB0eXBlIGlzIGJvdW5kLg0KPiANCj4gSSB0 aGluayBteSBncmllZiB3aXRoIHRoZSBhYm92ZSBzZW50ZW5jZSBpcyB0aGUgc2Vjb25kIGhhbGYu IEkgZG9uJ3QNCj4gZmluZCBpdCBhcHByb3ByaWF0ZSB0aGF0IGVhY2ggcmVwb3J0IGJsb2NrIGlu Y2x1ZGUgZGV0YWlscyBhbmQNCj4gcGFyYW1ldGVycyBvZiB0aGUgdGhlIHBheWxvYWQgZm9ybWF0 LiBJIHRoaW5rIHRoZSBhcHByb3JpYXRlIGxldmVsIGlzDQo+IHRvIGluY2x1ZGUgdGhlIHBheWxv YWQgdHlwZSBhbmQgdXNlIHRoZSBmdW5jdGlvbnMgeW91IGFueXdheSBoYXZlIGZvcg0KPiBhc3Nv Y2lhdGluZyBzaWduYWxsaW5nIHdpdGggbWVkaWEgc2Vzc2lvbiBjYXB0dXJlIHRvIHN0b3JlIHRo ZSBhY3R1YWwNCj4gcGFyYW1ldGVyPw0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVy bHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJp Y3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAg ICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbkcvZnYXRhbiA2ICAgICAg ICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0s IFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRl byBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA== From csp@csperkins.org Wed Apr 25 02:46:00 2012 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 837D121F85AF for ; Wed, 25 Apr 2012 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 j9qeZ+4p2AWC for ; Wed, 25 Apr 2012 02:45:59 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82D21F85AC for ; Wed, 25 Apr 2012 02:45:59 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SMyn9-00044l-eI; Wed, 25 Apr 2012 09:45:57 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4F96A7FA.6030901@ericsson.com> Date: Wed, 25 Apr 2012 10:45:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54EB743A-F396-4CCF-A593-67A64B06C952@csperkins.org> References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> <4F96A7FA.6030901@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 25 Apr 2012 09:46:00 -0000 Magnus, On 24 Apr 2012, at 14:17, Magnus Westerlund wrote: > I have reviewed the latest changes and do wonder if the proposed > formulations really are the correct one. >=20 > Full diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-12 >=20 > Section 5.2: > Report blocks that require such correlation need to include the = payload > type of the reported media, and must signal details and parameters of > the payload format to which that payload type is bound. >=20 > I think my grief with the above sentence is the second half. I don't > find it appropriate that each report block include details and > parameters of the the payload format. I think the approriate level is = to > include the payload type and use the functions you anyway have for > associating signalling with media session capture to store the actual > parameter? I don't interpret that text as requiring the report blocks to include = details of the parameters of the payload format. Rather, those = parameters need to be signalled. Perhaps a better phrasing would be: "Report blocks that require such correlation need to include the payload = type of the reported media. In addition, it is necessary to signal the = details and parameters of the payload format to which that payload type = is bound using some out-of-band means (e.g., as part of an SDP = offer/answer exchange)." =20 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 25 02:46:59 2012 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 4EA3A21F870F for ; Wed, 25 Apr 2012 02:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 NMNNcVnr-vRv for ; Wed, 25 Apr 2012 02:46:58 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0A021F8701 for ; Wed, 25 Apr 2012 02:46:58 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SMyoF-00044l-dA; Wed, 25 Apr 2012 09:46:57 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4F96A6FF.3000302@ericsson.com> Date: Wed, 25 Apr 2012 10:46:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 25 Apr 2012 09:46:59 -0000 Magnus, I'm happy with the changes (although you might want to include a = clarification to Section 5.2 along the lines that I just proposed). Colin On 24 Apr 2012, at 14:13, Magnus Westerlund wrote: > WG, Colin and Charles >=20 > This version intends to address the WG last call comments. I would > recommend that people review the changes. I will give people a week to > review this. Please provide any feedback on the changes no later than > 1st of May. >=20 > Cheers >=20 > Magnus >=20 > On 2012-04-18 05:58, 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 : Monitoring Architecture for RTP >> Author(s) : Qin Wu >> Geoff Hunt >> Philip Arden >> Filename : draft-ietf-avtcore-monarch-12.txt >> Pages : 29 >> Date : 2012-04-17 >>=20 >> This memo proposes an architecture for extending RTP Control = Protocol >> (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type = to >> report new metrics regarding media transmission or reception = quality, >> following RTCP guideline established in RFC5968. This memo = suggests >> that a new block should contain a single metric or a small number = of >> metrics relevant to a single parameter of interest or concern, = rather >> than containing a number of metrics which attempt to provide full >> coverage of all those parameters of concern to a specific >> application. Applications may then "mix and match" to create a set >> of blocks which covers their set of concerns. Where possible, a >> specific block should be designed to be re-usable across more than >> one application, for example, for all of voice, streaming audio and >> video. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt >>=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 --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Wed Apr 25 07:14:23 2012 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 1C3B721F8759 for ; Wed, 25 Apr 2012 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 kUXv6mzIs-cr for ; Wed, 25 Apr 2012 07:14:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70521F8715 for ; Wed, 25 Apr 2012 07:14:21 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-6f-4f9806bc519e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 58.79.26681.CB6089F4; Wed, 25 Apr 2012 16:14:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012 16:14:20 +0200 Message-ID: <4F9806A7.60507@ericsson.com> Date: Wed, 25 Apr 2012 16:13:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Colin Perkins References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> <4F96A7FA.6030901@ericsson.com> <54EB743A-F396-4CCF-A593-67A64B06C952@csperkins.org> In-Reply-To: <54EB743A-F396-4CCF-A593-67A64B06C952@csperkins.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Wed, 25 Apr 2012 14:14:23 -0000 On 2012-04-25 11:45, Colin Perkins wrote: > Magnus, > > On 24 Apr 2012, at 14:17, Magnus Westerlund wrote: >> I have reviewed the latest changes and do wonder if the proposed >> formulations really are the correct one. >> >> Full diff: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-12 >> >> Section 5.2: Report blocks that require such correlation need to >> include the payload type of the reported media, and must signal >> details and parameters of the payload format to which that payload >> type is bound. >> >> I think my grief with the above sentence is the second half. I >> don't find it appropriate that each report block include details >> and parameters of the the payload format. I think the approriate >> level is to include the payload type and use the functions you >> anyway have for associating signalling with media session capture >> to store the actual parameter? > > > I don't interpret that text as requiring the report blocks to include > details of the parameters of the payload format. Rather, those > parameters need to be signalled. Perhaps a better phrasing would be: > > "Report blocks that require such correlation need to include the > payload type of the reported media. In addition, it is necessary to > signal the details and parameters of the payload format to which that > payload type is bound using some out-of-band means (e.g., as part of > an SDP offer/answer exchange)." > The proposed text is much clearer on the signaling being out of band in relation to RTCP and that is how I personally think it should be. Authors, are you also fine with the text proposed by Colin? 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 magnus.westerlund@ericsson.com Wed Apr 25 07:46:57 2012 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 E56EA21F869F for ; Wed, 25 Apr 2012 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 m7BKcgvCxwrB for ; Wed, 25 Apr 2012 07:46:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C299C21F869C for ; Wed, 25 Apr 2012 07:46:56 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-76-4f980e5f000b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 35.C4.03534.F5E089F4; Wed, 25 Apr 2012 16:46:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 25 Apr 2012 16:46:55 +0200 Message-ID: <4F980E4D.1040205@ericsson.com> Date: Wed, 25 Apr 2012 16:46:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Adopting a WG item for RTP stream duplication? 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, 25 Apr 2012 14:46:58 -0000 WG, In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ The result in the meeting room was minuted as: A fair amount of people supporting a WG item, none against. See more about this item (Agenda Item 10) in the minutes http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm Thus I would like to ask the rest of the WG if they support or oppose the creation of a WG item for defining how to best perform RTP stream Duplication. Cheers Magnus Westerlund (WG Chair) ---------------------------------------------------------------------- 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 Wed Apr 25 17:37:42 2012 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 AAFBA11E80AE for ; Wed, 25 Apr 2012 17:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 g6Ma9v6op8AM for ; Wed, 25 Apr 2012 17:37:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB911E8076 for ; Wed, 25 Apr 2012 17:37:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN55343; Wed, 25 Apr 2012 20:37:41 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 17:34:17 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 17:34:22 -0700 Received: from w53375 (10.138.41.149) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 08:33:53 +0800 Message-ID: <6DDCD7E1F5E646118B1F2C7276890DEC@china.huawei.com> From: Qin Wu To: Magnus Westerlund , Colin Perkins References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com><4F96A6FF.3000302@ericsson.com> <4F96A7FA.6030901@ericsson.com><54EB743A-F396-4CCF-A593-67A64B06C952@csperkins.org> <4F9806A7.60507@ericsson.com> Date: Thu, 26 Apr 2012 08:33:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Thu, 26 Apr 2012 00:37:42 -0000 WWVzLCBpdCBsb29rcyBnb29kIHRvIHVzLiBUaGFua3MuDQoNClJlZ2FyZHMhDQotUWluDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0KVG86ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNz cGVya2lucy5vcmc+DQpDYzogPGF2dEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjUsIDIwMTIgMTA6MTMgUE0NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTIudHh0DQoNCg0KT24gMjAxMi0wNC0yNSAxMTo0NSwg Q29saW4gUGVya2lucyB3cm90ZToNCj4gTWFnbnVzLA0KPiANCj4gT24gMjQgQXByIDIwMTIsIGF0 IDE0OjE3LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4+IEkgaGF2ZSByZXZpZXdlZCB0aGUg bGF0ZXN0IGNoYW5nZXMgYW5kIGRvIHdvbmRlciBpZiB0aGUgcHJvcG9zZWQgDQo+PiBmb3JtdWxh dGlvbnMgcmVhbGx5IGFyZSB0aGUgY29ycmVjdCBvbmUuDQo+PiANCj4+IEZ1bGwgZGlmZjogDQo+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0Y29yZS1t b25hcmNoLTEyDQo+PiANCj4+IFNlY3Rpb24gNS4yOiBSZXBvcnQgYmxvY2tzIHRoYXQgcmVxdWly ZSBzdWNoIGNvcnJlbGF0aW9uIG5lZWQgdG8NCj4+IGluY2x1ZGUgdGhlIHBheWxvYWQgdHlwZSBv ZiB0aGUgcmVwb3J0ZWQgbWVkaWEsIGFuZCBtdXN0IHNpZ25hbA0KPj4gZGV0YWlscyBhbmQgcGFy YW1ldGVycyBvZiB0aGUgcGF5bG9hZCBmb3JtYXQgdG8gd2hpY2ggdGhhdCBwYXlsb2FkDQo+PiB0 eXBlIGlzIGJvdW5kLg0KPj4gDQo+PiBJIHRoaW5rIG15IGdyaWVmIHdpdGggdGhlIGFib3ZlIHNl bnRlbmNlIGlzIHRoZSBzZWNvbmQgaGFsZi4gSQ0KPj4gZG9uJ3QgZmluZCBpdCBhcHByb3ByaWF0 ZSB0aGF0IGVhY2ggcmVwb3J0IGJsb2NrIGluY2x1ZGUgZGV0YWlscw0KPj4gYW5kIHBhcmFtZXRl cnMgb2YgdGhlIHRoZSBwYXlsb2FkIGZvcm1hdC4gSSB0aGluayB0aGUgYXBwcm9yaWF0ZQ0KPj4g bGV2ZWwgaXMgdG8gaW5jbHVkZSB0aGUgcGF5bG9hZCB0eXBlIGFuZCB1c2UgdGhlIGZ1bmN0aW9u cyB5b3UNCj4+IGFueXdheSBoYXZlIGZvciBhc3NvY2lhdGluZyBzaWduYWxsaW5nIHdpdGggbWVk aWEgc2Vzc2lvbiBjYXB0dXJlDQo+PiB0byBzdG9yZSB0aGUgYWN0dWFsIHBhcmFtZXRlcj8NCj4g DQo+IA0KPiBJIGRvbid0IGludGVycHJldCB0aGF0IHRleHQgYXMgcmVxdWlyaW5nIHRoZSByZXBv cnQgYmxvY2tzIHRvIGluY2x1ZGUNCj4gZGV0YWlscyBvZiB0aGUgcGFyYW1ldGVycyBvZiB0aGUg cGF5bG9hZCBmb3JtYXQuIFJhdGhlciwgdGhvc2UNCj4gcGFyYW1ldGVycyBuZWVkIHRvIGJlIHNp Z25hbGxlZC4gUGVyaGFwcyBhIGJldHRlciBwaHJhc2luZyB3b3VsZCBiZToNCj4gDQo+ICJSZXBv cnQgYmxvY2tzIHRoYXQgcmVxdWlyZSBzdWNoIGNvcnJlbGF0aW9uIG5lZWQgdG8gaW5jbHVkZSB0 aGUNCj4gcGF5bG9hZCB0eXBlIG9mIHRoZSByZXBvcnRlZCBtZWRpYS4gSW4gYWRkaXRpb24sIGl0 IGlzIG5lY2Vzc2FyeSB0bw0KPiBzaWduYWwgdGhlIGRldGFpbHMgYW5kIHBhcmFtZXRlcnMgb2Yg dGhlIHBheWxvYWQgZm9ybWF0IHRvIHdoaWNoIHRoYXQNCj4gcGF5bG9hZCB0eXBlIGlzIGJvdW5k IHVzaW5nIHNvbWUgb3V0LW9mLWJhbmQgbWVhbnMgKGUuZy4sIGFzIHBhcnQgb2YNCj4gYW4gU0RQ IG9mZmVyL2Fuc3dlciBleGNoYW5nZSkuIg0KPiANCg0KVGhlIHByb3Bvc2VkIHRleHQgaXMgbXVj aCBjbGVhcmVyIG9uIHRoZSBzaWduYWxpbmcgYmVpbmcgb3V0IG9mIGJhbmQgaW4NCnJlbGF0aW9u IHRvIFJUQ1AgYW5kIHRoYXQgaXMgaG93IEkgcGVyc29uYWxseSB0aGluayBpdCBzaG91bGQgYmUu DQoNCkF1dGhvcnMsIGFyZSB5b3UgYWxzbyBmaW5lIHdpdGggdGhlIHRleHQgcHJvcG9zZWQgYnkg Q29saW4/DQoNCmNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpN dWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgy ODcNCkbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpT RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5j ZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2 dA== From magnus.westerlund@ericsson.com Thu Apr 26 01:11:14 2012 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 E7B2821F867B for ; Thu, 26 Apr 2012 01:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.138 X-Spam-Level: X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 CL5NtgMD4357 for ; Thu, 26 Apr 2012 01:11:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28721F863F for ; Thu, 26 Apr 2012 01:11:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-6e-4f99031db3df Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 10.06.25560.D13099F4; Thu, 26 Apr 2012 10:11:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012 10:11:09 +0200 Message-ID: <4F990303.6000007@ericsson.com> Date: Thu, 26 Apr 2012 10:10:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: IETF AVTCore WG References: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> In-Reply-To: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------020809080408020206020106" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-max-ssrc-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, 26 Apr 2012 08:11:14 -0000 --------------020809080408020206020106 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, (As individual) We have updated our individual draft for the maximum SSRC SDP signaling. The main change is that the fallback policy has been changed from a single SSRC to being application specific. Feedback much appreciated. Cheers Magnus Westerlund --------------020809080408020206020106 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-max-ssrc-01_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="I-D Action: draft-westerlund-avtcore-max-ssrc-01_txt.eml" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Apr 2012 10:08:10 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id 46.05.09996.962099F4; Thu, 26 Apr 2012 10:08:10 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92F21F86AD; Thu, 26 Apr 2012 01:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C03F21F86B3 for ; Thu, 26 Apr 2012 01:08:01 -0700 (PDT) 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 8+wTOsafT2ML for ; Thu, 26 Apr 2012 01:08:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7660821F86A3 for ; Thu, 26 Apr 2012 01:08:00 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Thu, 26 Apr 2012 10:08:00 +0200 Subject: I-D Action: draft-westerlund-avtcore-max-ssrc-01.txt Thread-Topic: I-D Action: draft-westerlund-avtcore-max-ssrc-01.txt Thread-Index: Ac0jg7htO74rObB8RTSBImaXVEwFGw== Message-ID: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3e-b7f636d00000270c-6d-4f99026956a3 x-brightmail-tracker: H4sIAAAAAAAAA1WSa0gUURiGPTPr7LjN6HG9fVoZjUgqpQn9mELFFKIfoRUVUYFuOe2ul9V2 1rILpGZRdtEK1wu6hXaxVBSz0kSoLewmpaZGadrF8gIVBZZmWjvOlvXv4bzv977fORyaVF+n fGghwyQYDZpkjlIpGM8VvksSieLYpU9eufPZrxqUfFbfO4LPyhb5qvfRfGdtP8F/MP+k+F5L n5IvKp1Q8oWHw/nx5mrHSNXqH2Pd1Fq0RRWWICTrdwvGkIh4le5SyxlFmtklo6uwkcxEJ5hc 5EQDXgZfbphJmT2hvb+WykUqWo0bEdwfeTYjqHEhgoq7ayRW4CkSTk96ygNBcPnRc0I+D4Rf rUcc5eEGBJduDytlUwAUXWlHuYi2sQvUWP1k9ITSr2Gywxk6hscJmfdDx/E6pRzzEkH522b7 QtcQfG+uoiQXi13hYfGgQmIK+0LVqBlJ7I69oaStbKbXDYfD6cHX9lR3+NT9xn5LgPFzlaSc EwklddMKaSEF9odbF9WyhYNfR87a1/eG3JODM4wxBsuFJkJ+Ew7M5hcztQyOgrJP/YS0J4MP IcgusThKmQxeCTmTm2RPILx4arH7I+BqYYMyH/mX/HMbiUm8GM43f6VkXgA3P5aS5xF5FXmI giimaEOXBgtG/Q5RTDUEGwRTPbL9lTsNkxGNqOdNqBV50wTnwVZOF8WqnbenJuzVaURdnDE9 WRCtaC6t4LzYkQPpsWqs1ZiEJEFIE4x/1Hk0zQF7EBXHql2NglbI2KlPNs3KBO1kRUAznDsb KHlYMU2TIuq1sv4ILfTxYtdLApYEXbrh7+yf39yJ5vu4scjBwUHN2HpT9Kb/9VHkRSPOjd0l pTB6g+lv+qitmLAVf1tvlopNmlnJJxM9WGUYi4rZED/Q39JF5R9zWPdgTXle3ZmjVPfj3vqK yYLwOCM9J3zbz9qpGuFHwKmsnvTA1CZ9a32OX0Henn0TQu3ynnus3vJxXFkZFTx1uUJXFdaW 4JxY9zmrNWkDY9hakbZx7POQtdpyJW4gJtpiClm3OXNg7XBe/qKh6b1lfb6cQtRpQoNIo6j5 DQI+gZrIAwAA dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335427683; bh=dk3BkarFVocpE1deubUp4crIC9XEIxadZ3QlgjWfDsQ=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ti6UW0Gsa2O/bLr3UhjZe75E/aM45ocSrvThagopARcKxb3WSDIoH+du1Tg5SqzjK b2MZKgbUUyZG/+j2MtPDgpjQtpg+4f66Fqgg9cvcZ9yUaHMmIuLnNIljEXkvvGlIbX tpHAKnI7xOPv2JQptLsVh1PZja8cyv+QCViKVpOM= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Internet Draft Announcements only x-beenthere: i-d-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.514 x-spam-flag: NO delivered-to: i-d-announce@ietfa.amsl.com x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiple Synchronization sources (SSRC) in RTP Session S= ignaling Author(s) : Magnus Westerlund Bo Burman Fredrik Jansson Filename : draft-westerlund-avtcore-max-ssrc-01.txt Pages : 13 Date : 2012-04-26 RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations are designed only for point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has an issue with legacy implementations. This document describes the problem and proposes a signalling solution for how to use multiple SSRCs within one RTP session and at the same time handle the legacy issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-max-ssrc-01.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-westerlund-avtcore-max-ssrc-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-max-ssrc/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------020809080408020206020106-- From eckelcu@cisco.com Fri Apr 27 11:21:51 2012 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 9A16121F866B for ; Fri, 27 Apr 2012 11:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 EbQ3OlgZg9kF for ; Fri, 27 Apr 2012 11:21:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2797521F8688 for ; Fri, 27 Apr 2012 11:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3351; q=dns/txt; s=iport; t=1335550910; x=1336760510; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=kY0deWzrZs00LVrfayDk3tPZW6OJnKQJ7X8htgB93Xc=; b=MM7vkkUdco4Bz3/AsKVThV8ew1es3H6eosMEiuBzrczlELVmUkLt6hb3 1xNaH1sNBQ00mRCjNfJMbZMN2cm489ScNwERhSP1YrkdVlZTN1v0i5Efh 5WueTudzHja2QNjdQ+D6MkQd2c/4jQcguMc2mINL+chggO9O3jBEuFu+O g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACfjmk+rRDoH/2dsb2JhbABEsgGBB4IJAQEBAwEBAQEJBgEdTgcCAgIBCBEBAwEBAQoGFwEGARoMHwMGCAEBBAESCAEZh2YEAQubY6AYBJBcYwSILzSbcYFpgwg X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="39407946" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Apr 2012 18:21:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3RILnOs025792; Fri, 27 Apr 2012 18:21:49 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 11:21:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 11:21:47 -0700 Message-ID: In-Reply-To: <4F96A6FF.3000302@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-12.txt Thread-Index: Ac0iHBl8ez8TuvJbT2qG5trpYNzOqwChjLHQ References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> From: "Charles Eckel (eckelcu)" To: "Magnus Westerlund" , , "Colin Perkins" X-OriginalArrivalTime: 27 Apr 2012 18:21:48.0936 (UTC) FILETIME=[9C4F5880:01CD24A2] Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Fri, 27 Apr 2012 18:21:51 -0000 The changes addressed all my comments, with the exception of the = following typo: > 13) Section 5.3, > r/even if though/even though Note that section 5.3 is not section 5.4, but the same typo exists. Cheers, Charles > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, April 24, 2012 6:14 AM > To: avt@ietf.org; Colin Perkins; Charles Eckel (eckelcu) > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-12.txt >=20 > WG, Colin and Charles >=20 > This version intends to address the WG last call comments. I would > recommend that people review the changes. I will give people a week to > review this. Please provide any feedback on the changes no later than > 1st of May. >=20 > Cheers >=20 > Magnus >=20 > On 2012-04-18 05:58, 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 : Monitoring Architecture for RTP > > Author(s) : Qin Wu > > Geoff Hunt > > Philip Arden > > Filename : draft-ietf-avtcore-monarch-12.txt > > Pages : 29 > > Date : 2012-04-17 > > > > This memo proposes an architecture for extending RTP Control > Protocol > > (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type > to > > report new metrics regarding media transmission or reception > quality, > > following RTCP guideline established in RFC5968. This memo > suggests > > that a new block should contain a single metric or a small number > of > > metrics relevant to a single parameter of interest or concern, > rather > > than containing a number of metrics which attempt to provide full > > coverage of all those parameters of concern to a specific > > application. Applications may then "mix and match" to create a > set > > of blocks which covers their set of concerns. Where possible, a > > specific block should be designed to be re-usable across more = than > > one application, for example, for all of voice, streaming audio > and > > video. > > > > > > A URL for this Internet-Draft is: > > = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-12.txt > > > > _______________________________________________ > > 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 > ---------------------------------------------------------------------- From bill.wu@huawei.com Fri Apr 27 18:36:49 2012 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 164EC11E808D for ; Fri, 27 Apr 2012 18:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 YT8SRJC1xQl5 for ; Fri, 27 Apr 2012 18:36:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2811E808A for ; Fri, 27 Apr 2012 18:36:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI75998; Fri, 27 Apr 2012 21:36:48 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 18:35:43 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 18:35:40 -0700 Received: from w53375 (10.138.41.149) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 28 Apr 2012 09:35:37 +0800 Message-ID: <4BE40E0F9EE94DD0B869A9C884163DFA@china.huawei.com> From: Qin Wu To: "Charles Eckel (eckelcu)" , Magnus Westerlund , , Colin Perkins References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com><4F96A6FF.3000302@ericsson.com> Date: Sat, 28 Apr 2012 09:35:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-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: Sat, 28 Apr 2012 01:36:49 -0000 SGksIENoYXJsZXM6DQpJIG1pc3NlZCB0aGlzIHR5cG8geW91IGNvbW1lbnRlZCBlYXJsaWVyLg0K SSB3aWxsIGZpeCBpdCBpbiB0aGUgdXBkYXRlLiBUaGFua3MuDQoNClJlZ2FyZHMhDQotUWluDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgRWNrZWwgKGVja2Vs Y3UpIiA8ZWNrZWxjdUBjaXNjby5jb20+DQpUbzogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPjsgPGF2dEBpZXRmLm9yZz47ICJDb2xpbiBQZXJraW5z IiA8Y3NwQGNzcGVya2lucy5vcmc+DQpTZW50OiBTYXR1cmRheSwgQXByaWwgMjgsIDIwMTIgMjoy MSBBTQ0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNv cmUtbW9uYXJjaC0xMi50eHQNCg0KDQpUaGUgY2hhbmdlcyBhZGRyZXNzZWQgYWxsIG15IGNvbW1l bnRzLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIGZvbGxvd2luZyB0eXBvOg0KDQo+IDEzKSBT ZWN0aW9uIDUuMywNCj4gci9ldmVuIGlmIHRob3VnaC9ldmVuIHRob3VnaA0KDQpOb3RlIHRoYXQg c2VjdGlvbiA1LjMgaXMgbm90IHNlY3Rpb24gNS40LCBidXQgdGhlIHNhbWUgdHlwbyBleGlzdHMu DQoNCkNoZWVycywNCkNoYXJsZXMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgNjoxNCBBTQ0KPiBUbzogYXZ0 QGlldGYub3JnOyBDb2xpbiBQZXJraW5zOyBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPiBTdWJq ZWN0OiBSZTogW0FWVENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNo LTEyLnR4dA0KPiANCj4gV0csIENvbGluIGFuZCBDaGFybGVzDQo+IA0KPiBUaGlzIHZlcnNpb24g aW50ZW5kcyB0byBhZGRyZXNzIHRoZSBXRyBsYXN0IGNhbGwgY29tbWVudHMuIEkgd291bGQNCj4g cmVjb21tZW5kIHRoYXQgcGVvcGxlIHJldmlldyB0aGUgY2hhbmdlcy4gSSB3aWxsIGdpdmUgcGVv cGxlIGEgd2VlayB0bw0KPiByZXZpZXcgdGhpcy4gUGxlYXNlIHByb3ZpZGUgYW55IGZlZWRiYWNr IG9uIHRoZSBjaGFuZ2VzIG5vIGxhdGVyIHRoYW4NCj4gMXN0IG9mIE1heS4NCj4gDQo+IENoZWVy cw0KPiANCj4gTWFnbnVzDQo+IA0KPiBPbiAyMDEyLTA0LTE4IDA1OjU4LCBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgd3JvdGU6DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydA0KPiBD b3JlIE1haW50ZW5hbmNlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4NCj4gPiBUaXRs ZSAgICAgICAgICAgOiBNb25pdG9yaW5nIEFyY2hpdGVjdHVyZSBmb3IgUlRQDQo+ID4gQXV0aG9y KHMpICAgICAgIDogUWluIFd1DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBHZW9mZiBI dW50DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsaXAgQXJkZW4NCj4gPiBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMi50eHQNCj4gPiBQYWdl cyAgICAgICAgICAgOiAyOQ0KPiA+IERhdGUgICAgICAgICAgICA6IDIwMTItMDQtMTcNCj4gPg0K PiA+ICAgIFRoaXMgbWVtbyBwcm9wb3NlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIGV4dGVuZGluZyBS VFAgQ29udHJvbA0KPiBQcm90b2NvbA0KPiA+ICAgIChSVENQKSB3aXRoIGEgbmV3IFJUQ1AgRXh0 ZW5kZWQgUmVwb3J0cyAoWFIpIChSRkMzNjExKSBibG9jayB0eXBlDQo+IHRvDQo+ID4gICAgcmVw b3J0IG5ldyBtZXRyaWNzIHJlZ2FyZGluZyBtZWRpYSB0cmFuc21pc3Npb24gb3IgcmVjZXB0aW9u DQo+IHF1YWxpdHksDQo+ID4gICAgZm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lIGVzdGFibGlzaGVk IGluIFJGQzU5NjguICBUaGlzIG1lbW8NCj4gc3VnZ2VzdHMNCj4gPiAgICB0aGF0IGEgbmV3IGJs b2NrIHNob3VsZCBjb250YWluIGEgc2luZ2xlIG1ldHJpYyBvciBhIHNtYWxsIG51bWJlcg0KPiBv Zg0KPiA+ICAgIG1ldHJpY3MgcmVsZXZhbnQgdG8gYSBzaW5nbGUgcGFyYW1ldGVyIG9mIGludGVy ZXN0IG9yIGNvbmNlcm4sDQo+IHJhdGhlcg0KPiA+ICAgIHRoYW4gY29udGFpbmluZyBhIG51bWJl ciBvZiBtZXRyaWNzIHdoaWNoIGF0dGVtcHQgdG8gcHJvdmlkZSBmdWxsDQo+ID4gICAgY292ZXJh Z2Ugb2YgYWxsIHRob3NlIHBhcmFtZXRlcnMgb2YgY29uY2VybiB0byBhIHNwZWNpZmljDQo+ID4g ICAgYXBwbGljYXRpb24uICBBcHBsaWNhdGlvbnMgbWF5IHRoZW4gIm1peCBhbmQgbWF0Y2giIHRv IGNyZWF0ZSBhDQo+IHNldA0KPiA+ICAgIG9mIGJsb2NrcyB3aGljaCBjb3ZlcnMgdGhlaXIgc2V0 IG9mIGNvbmNlcm5zLiAgV2hlcmUgcG9zc2libGUsIGENCj4gPiAgICBzcGVjaWZpYyBibG9jayBz aG91bGQgYmUgZGVzaWduZWQgdG8gYmUgcmUtdXNhYmxlIGFjcm9zcyBtb3JlIHRoYW4NCj4gPiAg ICBvbmUgYXBwbGljYXRpb24sIGZvciBleGFtcGxlLCBmb3IgYWxsIG9mIHZvaWNlLCBzdHJlYW1p bmcgYXVkaW8NCj4gYW5kDQo+ID4gICAgdmlkZW8uDQo+ID4NCj4gPg0KPiA+IEEgVVJMIGZvciB0 aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEyLnR4dA0KPiA+DQo+ID4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4NCj4gPiBUaGlzIEludGVybmV0 LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMi50eHQNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQXVkaW8v VmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gPiBhdnRAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPiA+DQo+IA0KPiANCj4g LS0NCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IE11bHRp bWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgy ODcNCj4gRuRy9mdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkN Cj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWlu dGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2F2dA==