From Even.roni@huawei.com Sun Apr 3 23:38:17 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB143A693C for ; Sun, 3 Apr 2011 23:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.618 X-Spam-Level: X-Spam-Status: No, score=-104.618 tagged_above=-999 required=5 tests=[AWL=1.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff46XRpRkckw for ; Sun, 3 Apr 2011 23:38:10 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 00E163A69DA for ; Sun, 3 Apr 2011 23:38:09 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ400J3L7TZ1Z@szxga04-in.huawei.com> for avtext@ietf.org; Mon, 04 Apr 2011 14:39:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ400LC77TZOF@szxga04-in.huawei.com> for avtext@ietf.org; Mon, 04 Apr 2011 14:39:35 +0800 (CST) Received: from windows8d787f9 ([109.65.49.204]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ400HYX7TMUB@szxml12-in.huawei.com>; Mon, 04 Apr 2011 14:39:35 +0800 (CST) Date: Mon, 04 Apr 2011 09:38:22 +0300 From: Roni Even In-reply-to: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> To: 'David R Oran' , "'DRAGE, Keith (Keith)'" Message-id: <00c401cbf292$edace870$c906b950$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvtgorGsJ3rVWTkTMO20VzsU7Y4/gFECFaA References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:38:17 -0000 Hi Dave, I think it may be good to have the two use cases. The draft will be informational so showing the flow for both cases may be good. Regards Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of David R Oran > Sent: Monday, March 28, 2011 9:58 PM > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > > Sorry I wasn't there folks (still can't travel for another month or > so). > I have one question about the discussion and conclusion. > > Was there consensus on the (I believe explicit) statement in the > requirements that the splicing action be completely undetectable by the > receiver? > > The reason I ask is that from my perspective, the entire technical > approach (including whether to model as a translator or mixer) is > driven by this one requirement. In fact, I can see a number of MUCH > simpler approaches if this requirement is dropped. > > I just want to be clear when we adopt the milestone if we are a priori > confining the solution space to solutions that satisfy this > requirement. > > I'm somewhat ambivalent about this, since the only use case I can think > of where undetectability comes into play is advertisement insertion. We > should be clear that everybody understands that this is the case. > > Cheers, DaveO. > > > On Mar 28, 2011, at 12:01 PM, DRAGE, Keith (Keith) wrote: > > > (As WG chair) > > > > There was significant interest in the face-to-face meeting to > creating a milestone in the WG. The essence of the milestone will be to > address the use case of splicing using existing tools provided in RTP. > It will therefore be an informational document. > > > > Unless the chairs hear contrary positions on the mailing list, the > chairs will discussing such a milestone with the AD and adding it to > our list of milestones in AVTEXT. > > > > Please respond by the end of this week (Friday). > > > > This does not adopt the current text as a working group item. The > author will provide another revision of this document based on comments > made, and other comments that people may wish to contribute now, and we > will make a call to adopt text at that point. Please take this as an > invitation to contribution other material either via the mailing list > or via separate internet-drafts. > > > > Regards > > > > Keith > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From magnus.westerlund@ericsson.com Mon Apr 4 02:24:44 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD3C3A6943 for ; Mon, 4 Apr 2011 02:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ITD8UBW5ln2 for ; Mon, 4 Apr 2011 02:24:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0B5CD3A6952 for ; Mon, 4 Apr 2011 02:24:36 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-a2-4d998eb97555 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.DB.09202.9BE899D4; Mon, 4 Apr 2011 11:26:18 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Apr 2011 11:26:17 +0200 Message-ID: <4D998EB8.9070007@ericsson.com> Date: Mon, 4 Apr 2011 11:26:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20110330135205.6BA313A6B57@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540EAACB8F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EAACB8F@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-ietf-avtext-multicast-acq-rtcp-xr-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 09:24:44 -0000 Ali C. Begen (abegen) skrev 2011-03-30 15:58: > https://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr > > This version addressed the comments from Magnus (chair's review). We > should be ready for pub request. Hi, I have reviewed the changes and think they are appropriate and ok. I wished the usage language was a bit more authorative. Secondly, I think the privacy angle could benefit from a bit more exploration, especially in regards to the vendor extensions. The ones present in the report block currently appear to leak only service performance related issues. The fact that one is switching channels are going to impossible to hide for anyone that can sniff the traffic arriving at a particular user. 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 Mon Apr 4 10:39:56 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3CD3A698E for ; Mon, 4 Apr 2011 10:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.562 X-Spam-Level: X-Spam-Status: No, score=-104.562 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqn6Ms2iuiWm for ; Mon, 4 Apr 2011 10:39:52 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 828BE3A6855 for ; Mon, 4 Apr 2011 10:39:52 -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 1Q6nmQ-0005iR-bn; Mon, 04 Apr 2011 17:41:34 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <00c401cbf292$edace870$c906b950$%roni@huawei.com> Date: Mon, 4 Apr 2011 18:41:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:39:56 -0000 Roni, I disagree, since the solutions for the two use cases are very = different. The draft would be better to focus on addressing a single = problem, rather than try to cover both.=20 Colin On 4 Apr 2011, at 07:38, Roni Even wrote: > Hi Dave, > I think it may be good to have the two use cases. The draft will be > informational so showing the flow for both cases may be good. > Regards > Roni >=20 >> -----Original Message----- >> From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On >> Behalf Of David R Oran >> Sent: Monday, March 28, 2011 9:58 PM >> To: DRAGE, Keith (Keith) >> Cc: avtext@ietf.org >> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >>=20 >> Sorry I wasn't there folks (still can't travel for another month or >> so). >> I have one question about the discussion and conclusion. >>=20 >> Was there consensus on the (I believe explicit) statement in the >> requirements that the splicing action be completely undetectable by = the >> receiver? >>=20 >> The reason I ask is that from my perspective, the entire technical >> approach (including whether to model as a translator or mixer) is >> driven by this one requirement. In fact, I can see a number of MUCH >> simpler approaches if this requirement is dropped. >>=20 >> I just want to be clear when we adopt the milestone if we are a = priori >> confining the solution space to solutions that satisfy this >> requirement. >>=20 >> I'm somewhat ambivalent about this, since the only use case I can = think >> of where undetectability comes into play is advertisement insertion. = We >> should be clear that everybody understands that this is the case. >>=20 >> Cheers, DaveO. >>=20 >>=20 >> On Mar 28, 2011, at 12:01 PM, DRAGE, Keith (Keith) wrote: >>=20 >>> (As WG chair) >>>=20 >>> There was significant interest in the face-to-face meeting to >> creating a milestone in the WG. The essence of the milestone will be = to >> address the use case of splicing using existing tools provided in = RTP. >> It will therefore be an informational document. >>>=20 >>> Unless the chairs hear contrary positions on the mailing list, the >> chairs will discussing such a milestone with the AD and adding it to >> our list of milestones in AVTEXT. >>>=20 >>> Please respond by the end of this week (Friday). >>>=20 >>> This does not adopt the current text as a working group item. The >> author will provide another revision of this document based on = comments >> made, and other comments that people may wish to contribute now, and = we >> will make a call to adopt text at that point. Please take this as an >> invitation to contribution other material either via the mailing list >> or via separate internet-drafts. >>>=20 >>> Regards >>>=20 >>> Keith >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins http://csperkins.org/ From Even.roni@huawei.com Mon Apr 4 12:54:55 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412BD3A67BD for ; Mon, 4 Apr 2011 12:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJA1PqMU1SbR for ; Mon, 4 Apr 2011 12:54:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 097063A67B7 for ; Mon, 4 Apr 2011 12:54:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ5003S18Q0ZS@szxga03-in.huawei.com> for avtext@ietf.org; Tue, 05 Apr 2011 03:56:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ5005648Q0SV@szxga03-in.huawei.com> for avtext@ietf.org; Tue, 05 Apr 2011 03:56:24 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-1-169.red.bezeqint.net [79.182.1.169]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ500CRJ8P710@szxml11-in.huawei.com>; Tue, 05 Apr 2011 03:56:24 +0800 (CST) Date: Mon, 04 Apr 2011 22:54:24 +0300 From: Roni Even In-reply-to: <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> To: 'Colin Perkins' Message-id: <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acvy76KkTh8c1dfTTu+ch4d/QslrpAADlXbg References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:54:55 -0000 Colin, I think that the case with the requirement to undetectability is a simple translator, is there something specific in this case. My view was that if we take undetectability away and use a translator or a mixer it becomes an RFC3550 translator/mixer and we just point to RFC 3550. I am still not sure why we made splicing using translator and not RTP mixer which seemed to me a better fit. Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Colin Perkins > Sent: Monday, April 04, 2011 8:42 PM > To: Roni Even > Cc: avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > > Roni, > > I disagree, since the solutions for the two use cases are very > different. The draft would be better to focus on addressing a single > problem, rather than try to cover both. > > Colin > > > > On 4 Apr 2011, at 07:38, Roni Even wrote: > > Hi Dave, > > I think it may be good to have the two use cases. The draft will be > > informational so showing the flow for both cases may be good. > > Regards > > Roni > > > >> -----Original Message----- > >> From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > >> Behalf Of David R Oran > >> Sent: Monday, March 28, 2011 9:58 PM > >> To: DRAGE, Keith (Keith) > >> Cc: avtext@ietf.org > >> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > >> > >> Sorry I wasn't there folks (still can't travel for another month or > >> so). > >> I have one question about the discussion and conclusion. > >> > >> Was there consensus on the (I believe explicit) statement in the > >> requirements that the splicing action be completely undetectable by > the > >> receiver? > >> > >> The reason I ask is that from my perspective, the entire technical > >> approach (including whether to model as a translator or mixer) is > >> driven by this one requirement. In fact, I can see a number of MUCH > >> simpler approaches if this requirement is dropped. > >> > >> I just want to be clear when we adopt the milestone if we are a > priori > >> confining the solution space to solutions that satisfy this > >> requirement. > >> > >> I'm somewhat ambivalent about this, since the only use case I can > think > >> of where undetectability comes into play is advertisement insertion. > We > >> should be clear that everybody understands that this is the case. > >> > >> Cheers, DaveO. > >> > >> > >> On Mar 28, 2011, at 12:01 PM, DRAGE, Keith (Keith) wrote: > >> > >>> (As WG chair) > >>> > >>> There was significant interest in the face-to-face meeting to > >> creating a milestone in the WG. The essence of the milestone will be > to > >> address the use case of splicing using existing tools provided in > RTP. > >> It will therefore be an informational document. > >>> > >>> Unless the chairs hear contrary positions on the mailing list, the > >> chairs will discussing such a milestone with the AD and adding it to > >> our list of milestones in AVTEXT. > >>> > >>> Please respond by the end of this week (Friday). > >>> > >>> This does not adopt the current text as a working group item. The > >> author will provide another revision of this document based on > comments > >> made, and other comments that people may wish to contribute now, and > we > >> will make a call to adopt text at that point. Please take this as an > >> invitation to contribution other material either via the mailing > list > >> or via separate internet-drafts. > >>> > >>> Regards > >>> > >>> Keith > >>> _______________________________________________ > >>> avtext mailing list > >>> avtext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avtext > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From efriedri@cisco.com Mon Apr 4 13:02:55 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35313A67B7 for ; Mon, 4 Apr 2011 13:02:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7NByL4zUxSR for ; Mon, 4 Apr 2011 13:02:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E1FF63A63D3 for ; Mon, 4 Apr 2011 13:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=efriedri@cisco.com; l=2280; q=dns/txt; s=iport; t=1301947477; x=1303157077; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=4txk1i2Z5uSdEybeAzBBqUyddIweTuSK1pYfX1FiKRc=; b=VS9ylV6Cp7BtoSQ/o/MnEJYlHeCd+TUHxVNPFDTx1EFWj+I3oalZbT41 IYxN3TzjzbLWCfNo2ROHWeTnyv+lNa/mHbQn3+gCcFh1OjvushB0pFrk1 Tuf31GasQOsaAVg36R551yBZKuqZJoakbMUftLjEbGNAxdTtAKft3HrFd k=; X-IronPort-AV: E=Sophos;i="4.63,299,1299456000"; d="scan'208";a="330460817" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2011 20:04:37 +0000 Received: from dhcp-161-44-173-248.cisco.com (dhcp-161-44-173-248.cisco.com [161.44.173.248]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34K4aG6004386; Mon, 4 Apr 2011 20:04:37 GMT Message-Id: From: Eric Friedrich To: Magnus Westerlund In-Reply-To: <4D998EB8.9070007@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Apr 2011 16:04:37 -0400 References: <20110330135205.6BA313A6B57@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540EAACB8F@xmb-sjc-215.amer.cisco.com> <4D998EB8.9070007@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-ietf-avtext-multicast-acq-rtcp-xr-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:02:55 -0000 Hi Magnus, Thanks for the comments. Would you be ok with the addition of the =20 following text to Section 6? "MA report integrity can be provided by SRTP and SRTCP. Malicious sniffing or otherwise obtaining MA report blocks can reveal =20= performance characteristics of the RTP service and underlying network. =20= This information is already available to an observer with the ability =20= to capture RTP + RTCP session traffic. The contents and value of any private vendor extensions should be =20 studied when considering the need to secure the MA report. Application-=20= level performance data may be present that is not otherwise available =20= to an attacker as with the required fields and vendor neutral =20 extensions." --Eric Friedrich On Apr 4, 2011, at 5:26 AM, Magnus Westerlund wrote: > Ali C. Begen (abegen) skrev 2011-03-30 15:58: >> = https://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr >> >> This version addressed the comments from Magnus (chair's review). We >> should be ready for pub request. > > Hi, > > I have reviewed the changes and think they are appropriate and ok. I > wished the usage language was a bit more authorative. Secondly, I =20 > think > the privacy angle could benefit from a bit more exploration, =20 > especially > in regards to the vendor extensions. The ones present in the report > block currently appear to leak only service performance related =20 > issues. > The fact that one is switching channels are going to impossible to =20 > hide > for anyone that can sniff the traffic arriving at a particular user. > > 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 > ---------------------------------------------------------------------- > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Tue Apr 5 09:23:30 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E4928C120 for ; Tue, 5 Apr 2011 09:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.837 X-Spam-Level: X-Spam-Status: No, score=-104.837 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0MXYnpCdtnG for ; Tue, 5 Apr 2011 09:23:28 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id D4AAD28C114 for ; Tue, 5 Apr 2011 09:23:27 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p35GOvpA011468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 18:25:06 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 5 Apr 2011 18:25:04 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org" Date: Tue, 5 Apr 2011 18:25:03 +0200 Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "avtext@ietf.org" Subject: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:23:30 -0000 I've done a detailed review of this document before sending for publication= request. I'd appreciate it if you could address the following in a new ver= sion. By all means ask questions about any of the comments. I don't believe= any of these make a technical change to the document, but they should make= it clearer. 1) General. There are a number of instances where SHALL is used in the= document. This means exactly the same as "MUST" and it would be more consi= stent to use "MUST" throughout. 2) Abstract. In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver may use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver may (or may have to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). Replace two instances of "may" by "can" and an instance of "may have to" by= "be compelled to", to avoid usage of RFC 2119 like language (even though l= ower case) In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can (or be compelled to) do = a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). 3) Section 1, 2nd paragraph In most RTP-based multicast applications such as the ones carrying video content, the RTP source sends inter-related data. Consequently, the RTP application may not be able to decode and present the data in an RTP packet before decoding one or more earlier RTP packets and/or before acquiring some Reference Information about the content itself. Thus, RTP receivers that are randomly joining a multicast session often experience a random acquisition delay. In order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] proposes an approach where an auxiliary unicast RTP session is established between a retransmission server and the joining RTP receiver. Over this unicast RTP session, the retransmission server provides the Reference Information, which is all the information the RTP receiver needs to rapidly acquire the multicast stream. This method is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). However, depending on the variability in the Source Filtering Group Management Protocol (SFGMP) processing times, availability of network resources for rapid acquisition and nature of the RTP data, not all RTP receivers can acquire the multicast stream in the same amount of time. The performance of rapid acquisition may vary not only for different RTP receivers but also over time. Replace "may not be able to" with "cannot" and instance of "may" with "can"= to avoid usage of RFC 2119 language. In most RTP-based multicast applications such as the ones carrying video content, the RTP source sends inter-related data. Consequently, the RTP application cannot decode and present the data in an RTP packet before decoding one or more earlier RTP packets and/or before acquiring some Reference Information about the content itself. Thus, RTP receivers that are randomly joining a multicast session often experience a random acquisition delay. In order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] proposes an approach where an auxiliary unicast RTP session is established between a retransmission server and the joining RTP receiver. Over this unicast RTP session, the retransmission server provides the Reference Information, which is all the information the RTP receiver needs to rapidly acquire the multicast stream. This method is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). However, depending on the variability in the Source Filtering Group Management Protocol (SFGMP) processing times, availability of network resources for rapid acquisition and nature of the RTP data, not all RTP receivers can acquire the multicast stream in the same amount of time. The performance of rapid acquisition can vary not only for different RTP receivers but also over time. 4) Section 1, 3rd paragraph To increase the visibility of the multicast service provider into its network, to diagnose slow multicast acquisition issues and to collect the acquisition experiences of the RTP receivers, this document defines a new report block type, which is called Multicast Acquisition (MA) Report Block, within the framework of RTCP XR. RTP receivers that are using the method described in [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every time they join a new multicast RTP session. RTP receivers that use a different method for rapid acquisition or those do not use any method but rather do a simple multicast join may also use this report to collect information. This way, the multicast service provider can quantitatively compare the improvements achieved by different methods. Replace two instances of "may" with "can". To increase the visibility of the multicast service provider into its network, to diagnose slow multicast acquisition issues and to collect the acquisition experiences of the RTP receivers, this document defines a new report block type, which is called Multicast Acquisition (MA) Report Block, within the framework of RTCP XR. RTP receivers that are using the method described in [I-D.ietf-avt-rapid-acquisition-for-rtp] can use this report every time they join a new multicast RTP session. RTP receivers that use a different method for rapid acquisition or those do not use any method but rather do a simple multicast join can also use this report to collect information. This way, the multicast service provider can quantitatively compare the improvements achieved by different methods. 5) Section 3. Definition of Primary Multicast Session. (Primary) Multicast Session: The multicast session to which RTP receivers can join at a random point in time. I interpret the parenthesis round "primary" to indicate that some instances= of the term appear without the word "primary" but still mean "primary". I'= m not convinced that is the case. Anyway, remove the parenthesis and check = the rest of the document for instances where "primary" should now be insert= ed. 6) Section 3. Definition of Primary Multicast (RTP) Streams Primary Multicast (RTP) Streams: The RTP stream(s) carried in the primary multicast RTP session. I cannot find this term used within the document. If it does not appear, de= lete it. If the something in the document means this, then apply the define= d term to it. 7) Section 4. 2nd paragraph. The optional extensions that are defined in this document are primarily developed for the method presented in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide rapid acquisition MAY define their own extensions to be used in the MA report block. I don't think this merits RFC 2119 language and certainly not "MAY" which d= efines an option. I think "can" is sufficient here. Other methods are outsi= de the scope of this document. 8) Section 4. 4th paragraph. The MA report block is better to be sent after all the necessary information is collected and computed. Partial reporting is generally not useful as it may not give the full picture of the multicast acquisition, and causes additional complexity in terms of report block matching and correlation. The MA report block SHOULD only be sent as a part of an RTCP compound packet, and it is sent in the primary multicast session. I had some trouble parsing the 1st sentence, and I believe it is better rew= orded as below. It is better to send the MA report block after all the necessary information is collected and computed. Partial reporting is generally not useful as it cannot give the full picture of the multicast acquisition, and causes additional complexity in terms of report block matching and correlation. The MA report block SHOULD only be sent as a part of an RTCP compound packet, and it is sent in the primary multicast session. Secondly, for the "SHOULD" usage, it is normal to provide additional text i= dentify use cases under which the "SHOULD" might or might not be deviated f= rom. Otherwise implementors will trat it as a straight option and we may as= well have written "MAY". What do we really mean here? How do we check conf= ormance? 9) Section 4. 5th paragraph The reliability of the MA report block is not any more essential than other report blocks or types. If desired, the report block could be repeated for redundancy purposes while respecting to the RTCP scheduling algorithms. Again I had some trouble parsing this. I suggest the following: The need for reliability of the MA report block is no greater than other report blocks or types. If desired, the report block could be repeated for redundancy purposes while respecting to the RTCP scheduling algorithms. 10) Section 4.1. Status This document defines several status codes and registers them with IANA in Section 7.5. If a new vendor-neutral status code will be defined, it MUST be registered with IANA through the guidelines specified in Section 7.5. If the new status code is intended to be used privately by a vendor, there is no need for IANA management. Instead, the vendor MUST use the private extension mechanism (Section 4.2.2) to convey its message and MUST indicate this by putting zero in the Status field. The above text contains two requirements on the vendor. Firstly I am not a = great fan of hiding these requirements in a coding section. Secondly the first of these is also repeated in section 4.2 so we should de= lete one of them anyway. Finally the last paragraph is a combination of a vendor requirement and an = implementation requirement. These have to be split. For the first half ("th= e vendor MUST use the private extension mechanism (Section 4.2.2) to convey= its message), I am not sure how one would demonstrate conformance so I wou= ld suggest we have a sentence more like: "Section 4.2.2 defines how a vendor defines and uses private extens= ion mechanisms to convey its message." For the second half, I would suggest a sentence of the form: "To indicate a private extension mechanism, the RTP receiver MUST s= et the Status field to zero." 11) Section 4.1. Rsvd o Rsvd. (16 bits): This field SHALL be set to 0 and ignored on reception. Two separate requirements here and write in the active. The RTP receiver MUST set this bit to "0". The recipient MUST ignor= e this bit when received. However I note that RFC 3611 uses the following text for similar bits, whic= h could be an alternative: This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. 12) Section 4.1.1. I would suggest splitting this subsection into two. The first would cover t= he paragraphs relating to someone writing a new MA method, and should be ti= tled something like "defining new MA methods". The second would be the rema= ining material and should be entitled something like "use of status codes".= The reason for this is that the conformers to the statements are completel= y different. 13) Section 4.1.1, 1st paragraph Different MA methods usually use different status codes, although some status codes (e.g., a code indicating that multicast join has failed) may apply to more than one MA method. However, the status code reported in the base report MUST always be within the scope of the particular MA method specified in the MA Method field. Change "may" to "can". Delete the "However" as superfluous. Different MA methods usually use different status codes, although some status codes (e.g., a code indicating that multicast join has failed) can apply to more than one MA method. The status code reported in the base report MUST always be within the scope of the particular MA method specified in the MA Method field. 14) Section 4.1.1, second paragraph. In certain MA methods, the RTP receiver may generate a status code for its multicast acquisition attempt, or may be told by another network element or RTP endpoint what the current status is via a response code. In such cases, the RTP receiver MAY report the value of the received response code as its status code if the response code has a higher priority. It is RECOMMENDED that each MA method outlines the rules pertaining to its response and status codes so that RTP receiver implementations can determine what to report in any given scenario. Below, we provide these rules for the RAMS method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Change "may" to "can" twice. As regards the "RECOMMENDED", this is equivalent to "SHOULD" and presumably= should be assessed by any review before making the IANA registration. Howe= ver you give no guidance as to what should be checked here. Do we make the = IANA registration anyway. If so, I would argue that the RFC 2119 language i= s superfluous, and give the language more in the form of descriptive guidan= ce. 15) Section 4.1.1, third paragraph Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines several response codes for its MA method. The 1xx and 2xx-level response codes are informational and success response codes, respectively. If the RTP receiver receives a 1xx or 2xx-level response code, it MUST use one of the 1xxx-level status codes defined in Section 7.5 of this document. The RTP receiver may also receive a 4xx or 5xx-level response code (indicating receiver-side and server- side errors, respectively). In that case, the RTP receiver MUST use the response code as its status code. In other words, the 4xx and 5xx-level response codes have a higher priority than the 1xxx-level status codes. The 5xx-level response codes have a higher priority than the 4xx-level response codes and MUST be reported in the base report in case the RTP receiver receives both 4xx and 5xx-level response codes (in different RAMS-I messages) during the same RAMS session. I would suggest some minor rewording as follows: Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines several response codes for its MA method. The 1xx and 2xx-level response codes are informational and success response codes, respectively. If the RTP receiver receives a 1xx or 2xx-level response code, then the RTP receiver MUST use one of the 1xxx-level stat= us codes defined in Section 7.5 of this document. If the RTP receiver receives a 4xx or 5xx-level response code (indicating receiver-side and server- side errors, respectively), then the RTP receiver MUST use the response code as its status code. In other words, the 4xx and 5xx-level response codes have a higher priority than the 1xxx-level status codes. The 5xx-level response codes have a higher priority than the 4xx-level response codes and MUST be reported in the base report in case the RTP receiver receives both 4xx and 5xx-level response codes (in different RAMS-I messages) during the same RAMS session. However not sure the final sentence correctly expresses what should be conf= ormed to. Presumably we have to select one and only one response code when = multiple are reported. Does this sentence clearly specify which one is sele= cted. Can there be multiple 4xx responses? 16) Section 4.2, 1st paragraph: To improve the reporting scope, it might be desirable to define new fields in the MA report block. Such fields MUST be encoded as TLV elements as described below and sketched in Figure 2: Not sure this statement merits RFC 2119 language, and indeed I'm not clear = if this is a requirement on the definer of the extension, or on the impleme= ntor of the extension. 17) Section 4.2, 1st paragraph, length o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields, and the 8-bit Reserved field between them. Note that this length does not include any padding that is required for alignment. Change "required" to "needed". 18) Section 4.2, 2nd paragraph and 3rd paragraphs: In the extensions, the Reserved field SHALL be set to zero and ignored on reception. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero. In the MA report block, any vendor-neutral or private extension MUST be placed after the base report. Again I am not clear whether this is a requirement on the definer of the ex= tension, or on the implementor of the extension. 19) Section 4.2.1, 2nd paragraph, 1st bullet: o RTP Seqnum of the First Multicast Packet (16 bits): TLV element that specifies the RTP sequence number of the first multicast packet received for the primary multicast stream. If the multicast join was successful, this element MUST exist. If no multicast packet has been received, this element SHALL NOT exist. I assume the RFC 2119 language is a requirement on the implementation of th= e RTP receiver. Please make this clear. Note this comment also applies to many of the subsequent bullets. Please re= view. 20) Section 4.2.2, 1st paragraph: It is desirable to allow vendors to use private extensions in TLV format. For interoperability, such extensions MUST NOT collide with each other. I don't believe I can assess conformance to such a statement unless I know = the scope of the uniqueness required. I suspect this is something that shou= ld not use RFC 2119 language in the first place. 21) Section 4.2.2, 3rd paragraph: The structure that MUST be used for the private extensions is depicted in Figure 3. Here, the private enterprise numbers are used from http://www.iana.org/assignments/enterprise-numbers. This will ensure the uniqueness of the private extensions and avoid any collision. Again I am not clear whether this is a requirement on the definer of the ex= tension, or on the implementor of the extension. 22) Section 5. I believe there is a construct in ABNF that allows an existing production t= o be extended using "/=3D" I'm guessing here, but I think you are extending the following production f= rom RFC 3611: xr-format =3D pkt-loss-rle / pkt-dup-rle / pkt-rcpt-times / rcvr-rtt / stat-summary / voip-metrics / format-ext In which case I would expect to see something like xr-format /=3D multicast-acq-ext multicast-acq-ext =3D "multicast-acq" along with a reference to RFC 3611 for the original production. 23) Section 6. 2nd paragraph The information contained in MA reports could be stolen as any other RTCP reports if proper protection mechanism(s) are not in place. If desired, similar to other RTCP XR reports, the MA reports MAY be protected by using Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) [RFC3711]. Used with "MAY" I believe RFC 3711 becomes a normative reference. Currently= it is only informative. 24) Section 6. 3rd paragraph Using the MA reports to provide feedback into the acquisition of the multicast streams can introduce possible additional security implications. If a forged or otherwise modified MA report is received for an earlier acquisition attempt, invalid data may be used as input in later rapid acquisition attempts. For example, incorrectly small SFGMP join times could cause the unicast burst to be too short, leading to gaps in sequence numbers in the approach discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly, when it is in fact failing, or vice versa. However, the MA reports are believed not to introduce any additional risks from a confidentiality viewpoint. Change "may" to "can". Using the MA reports to provide feedback into the acquisition of the multicast streams can introduce possible additional security implications. If a forged or otherwise modified MA report is received for an earlier acquisition attempt, invalid data can be used as input in later rapid acquisition attempts. For example, incorrectly small SFGMP join times could cause the unicast burst to be too short, leading to gaps in sequence numbers in the approach discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly, when it is in fact failing, or vice versa. However, the MA reports are believed not to introduce any additional risks from a confidentiality viewpoint. 25) Section 7. 1st paragraph The following contact information shall be used for all registrations in this document: Change to The following contact information is provided for all registrations in this document: 26) Section 7.4. Final bullet o A detailed description of what the new Status code describes and how it shall be interpreted. Reword to: o A detailed description of what the new Status code describes and how it is interpreted. Same change also to Section 7.5 final bullet. 27) Normative references. RFC 5226 is not a normative reference. Move to informative references secti= on. Regards Keith From abegen@cisco.com Tue Apr 5 10:56:48 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D6328C136 for ; Tue, 5 Apr 2011 10:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.412 X-Spam-Level: X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76KZaV9dFHsg for ; Tue, 5 Apr 2011 10:56:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 09B4028C0FA for ; Tue, 5 Apr 2011 10:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=20761; q=dns/txt; s=iport; t=1302026306; x=1303235906; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8HD8ZxPoKGIffzLuHjzMsOKCNGlFOaZJy2dQgDkKwfA=; b=m+DEhvhhCYh/PAZPTQ6RPAUGz9LO3Cvs/s4VgMtuHogaMNZttBj9WmbD dpR0YFNucBY0U7spohMQun7hFozehZ5hiX+U51OjY+tGG1l8KhOnAdl8r 3x3kCsjpmAnUnNd6kZ213TDFGbjNzmQekPv5wY1aybknLLqufSBxXQrhl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAANJWm02rRDoI/2dsb2JhbACYIY1Id4h5niKcIYJ9gm8EhUeLPw X-IronPort-AV: E=Sophos;i="4.63,305,1299456000"; d="scan'208";a="331136144" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 05 Apr 2011 17:58:26 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p35HwQgT004826; Tue, 5 Apr 2011 17:58:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 10:58:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 10:58:03 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjg References: From: "Ali C. Begen (abegen)" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 05 Apr 2011 17:58:26.0102 (UTC) FILETIME=[0FE0DD60:01CBF3BB] Cc: avtext@ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:56:48 -0000 Keith, > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Tuesday, April 05, 2011 12:25 PM > To: Ali C. Begen (abegen); = draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org > Cc: avtext@ietf.org > Subject: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in = preparation for pub request >=20 > I've done a detailed review of this document before sending for = publication request. I'd appreciate it if you could address the > following in a new version. By all means ask questions about any of = the comments. I don't believe any of these make a > technical change to the document, but they should make it clearer. > 1) General. There are a number of instances where SHALL is used = in the document. This means exactly the same as > "MUST" and it would be more consistent to use "MUST" throughout. Then, why did 2119 define "SHALL"? I prefer "SHALL" over "MUST" in = certain scenarios. This is a writing style preference. =20 > 2) Abstract. >=20 > In most RTP-based multicast applications, the RTP source sends = inter- > related data. Due to this interdependency, randomly joining RTP > receivers usually cannot start consuming the multicast data right > after they join the session. Thus, they often experience a random > acquisition delay. An RTP receiver may use one ore more different > approaches to achieve rapid acquisition. Yet, due to various > factors, performance of the rapid acquisition methods usually = varies. > Furthermore, in some cases the RTP receiver may (or may have to) do = a > simple multicast join. For quality reporting, monitoring and > diagnostics purposes, it is important to collect detailed = information > from the RTP receivers about their acquisition and presentation > experiences. This document addresses this issue by defining a new > report block type, called Multicast Acquisition (MA) Report Block, > within the framework of RTP Control Protocol (RTCP) Extended = Reports > (XR) (RFC 3611). This document also defines the necessary = signaling > of the new MA report block type in the Session Description Protocol > (SDP). >=20 > Replace two instances of "may" by "can" and an instance of "may have = to" by "be compelled to", to avoid usage of RFC 2119 > like language (even though lower case) I think you are paying unnecessary attention here and in other = paragraphs you noted. Using such keywords in abstract or intro before = 2119 usage is introduced is absolutely fine - as noted by IESG in my = earlier documents. Again, this is pure writing style issue.=20 > 5) Section 3. Definition of Primary Multicast Session. >=20 > (Primary) Multicast Session: The multicast session to which RTP > receivers can join at a random point in time. >=20 > I interpret the parenthesis round "primary" to indicate that some = instances of the term appear without the word "primary" > but still mean "primary". I'm not convinced that is the case. Anyway, = remove the parenthesis and check the rest of the > document for instances where "primary" should now be inserted. This is consistent with our definitions and terms used in the RAMS spec. = I'd rather keep the same to be consistent. =20 > 6) Section 3. Definition of Primary Multicast (RTP) Streams >=20 > Primary Multicast (RTP) Streams: The RTP stream(s) carried in the > primary multicast RTP session. >=20 > I cannot find this term used within the document. If it does not = appear, delete it. If the something in the document means > this, then apply the defined term to it. Good catch. Should remove it. =20 > 7) Section 4. 2nd paragraph. >=20 > The optional extensions that are defined in this document are > primarily developed for the method presented in > [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that = provide > rapid acquisition MAY define their own extensions to be used in the > MA report block. >=20 > I don't think this merits RFC 2119 language and certainly not "MAY" = which defines an option. I think "can" is sufficient here. > Other methods are outside the scope of this document. "can" is fine here. =20 > 8) Section 4. 4th paragraph. >=20 > The MA report block is better to be sent after all the necessary > information is collected and computed. Partial reporting is > generally not useful as it may not give the full picture of the > multicast acquisition, and causes additional complexity in terms of > report block matching and correlation. The MA report block SHOULD > only be sent as a part of an RTCP compound packet, and it is sent = in > the primary multicast session. >=20 > I had some trouble parsing the 1st sentence, and I believe it is = better reworded as below. >=20 > It is better to send the MA report block after all the necessary > information is collected and computed. Partial reporting is > generally not useful as it cannot give the full picture of the > multicast acquisition, and causes additional complexity in terms of > report block matching and correlation. The MA report block SHOULD > only be sent as a part of an RTCP compound packet, and it is sent = in > the primary multicast session. Rewording looks better. Thanks. =20 > Secondly, for the "SHOULD" usage, it is normal to provide additional = text identify use cases under which the "SHOULD" might > or might not be deviated from. Otherwise implementors will trat it as = a straight option and we may as well have written > "MAY". What do we really mean here? How do we check conformance? There is no conformance check here. As Magnus suggested, we added this = text to clarify that this report block was sent as a part of the = compound packet. I don't see any reason why anybody would do it = differently. But, even if they do, no big deal, nothing will break and = the world will not collapse. Any proper RTP implementation has to follow = certain rules anyway, which we don't need to repeat here. =20 > 9) Section 4. 5th paragraph >=20 > The reliability of the MA report block is not any more essential = than > other report blocks or types. If desired, the report block could = be > repeated for redundancy purposes while respecting to the RTCP > scheduling algorithms. >=20 > Again I had some trouble parsing this. I suggest the following: >=20 > The need for reliability of the MA report block is no greater than > other report blocks or types. If desired, the report block could = be > repeated for redundancy purposes while respecting to the RTCP > scheduling algorithms. OK. =20 > 10) Section 4.1. Status >=20 > This document defines several status codes and registers them = with > IANA in Section 7.5. If a new vendor-neutral status code will = be > defined, it MUST be registered with IANA through the guidelines > specified in Section 7.5. If the new status code is intended to > be used privately by a vendor, there is no need for IANA > management. Instead, the vendor MUST use the private extension > mechanism (Section 4.2.2) to convey its message and MUST = indicate > this by putting zero in the Status field. >=20 > The above text contains two requirements on the vendor. Firstly I am = not a great fan of hiding these requirements in a coding > section. I can't think of any other (and better) place to define them. =20 > Secondly the first of these is also repeated in section 4.2 so we = should delete one of them anyway. Will remove the one in 4.2.1. =20 > Finally the last paragraph is a combination of a vendor requirement = and an implementation requirement. These have to be > split. For the first half ("the vendor MUST use the private extension = mechanism (Section 4.2.2) to convey its message), I am > not sure how one would demonstrate conformance so I would suggest we = have a sentence more like: >=20 > "Section 4.2.2 defines how a vendor defines and uses private = extension mechanisms to convey its message." OK. =20 > For the second half, I would suggest a sentence of the form: >=20 > "To indicate a private extension mechanism, the RTP receiver = MUST set the Status field to zero." OK. =20 > 11) Section 4.1. Rsvd >=20 > o Rsvd. (16 bits): This field SHALL be set to 0 and ignored on > reception. >=20 > Two separate requirements here and write in the active. >=20 > The RTP receiver MUST set this bit to "0". The recipient MUST = ignore this bit when received. OK. =20 > However I note that RFC 3611 uses the following text for similar bits, = which could be an alternative: >=20 > This field is reserved for future definition. In the absence > of such definition, the bits in this field MUST be set to = zero > and MUST be ignored by the receiver. >=20 > 12) Section 4.1.1. >=20 > I would suggest splitting this subsection into two. The first would = cover the paragraphs relating to someone writing a new MA > method, and should be titled something like "defining new MA methods". = The second would be the remaining material and > should be entitled something like "use of status codes". The reason = for this is that the conformers to the statements are > completely different. I am not sure whether this will be clearer but I will look into it. =20 > 13) Section 4.1.1, 1st paragraph >=20 > Different MA methods usually use different status codes, although > some status codes (e.g., a code indicating that multicast join has > failed) may apply to more than one MA method. However, the status > code reported in the base report MUST always be within the scope of > the particular MA method specified in the MA Method field. >=20 > Change "may" to "can". Delete the "However" as superfluous. OK > 14) Section 4.1.1, second paragraph. >=20 > In certain MA methods, the RTP receiver may generate a status code > for its multicast acquisition attempt, or may be told by another > network element or RTP endpoint what the current status is via a > response code. In such cases, the RTP receiver MAY report the = value > of the received response code as its status code if the response = code > has a higher priority. It is RECOMMENDED that each MA method > outlines the rules pertaining to its response and status codes so > that RTP receiver implementations can determine what to report in = any > given scenario. Below, we provide these rules for the RAMS method > described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. >=20 > Change "may" to "can" twice. OK. =20 > As regards the "RECOMMENDED", this is equivalent to "SHOULD" and = presumably should be assessed by any review before > making the IANA registration. However you give no guidance as to what = should be checked here. Do we make the IANA > registration anyway. If so, I would argue that the RFC 2119 language = is superfluous, and give the language more in the form > of descriptive guidance. Ok. I will just say "each MA methods needs ..." =20 > 15) Section 4.1.1, third paragraph >=20 > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines > several response codes for its MA method. The 1xx and 2xx-level > response codes are informational and success response codes, > respectively. If the RTP receiver receives a 1xx or 2xx-level > response code, it MUST use one of the 1xxx-level status codes = defined > in Section 7.5 of this document. The RTP receiver may also receive = a > 4xx or 5xx-level response code (indicating receiver-side and = server- > side errors, respectively). In that case, the RTP receiver MUST = use > the response code as its status code. In other words, the 4xx and > 5xx-level response codes have a higher priority than the 1xxx-level > status codes. The 5xx-level response codes have a higher priority > than the 4xx-level response codes and MUST be reported in the base > report in case the RTP receiver receives both 4xx and 5xx-level > response codes (in different RAMS-I messages) during the same RAMS > session. >=20 > I would suggest some minor rewording as follows: >=20 > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines > several response codes for its MA method. The 1xx and 2xx-level > response codes are informational and success response codes, > respectively. If the RTP receiver receives a 1xx or 2xx-level > response code, then the RTP receiver MUST use one of the 1xxx-level = status codes defined > in Section 7.5 of this document. If the RTP receiver receives a > 4xx or 5xx-level response code (indicating receiver-side and = server- > side errors, respectively), then the RTP receiver MUST use > the response code as its status code. In other words, the 4xx and > 5xx-level response codes have a higher priority than the 1xxx-level > status codes. The 5xx-level response codes have a higher priority > than the 4xx-level response codes and MUST be reported in the base > report in case the RTP receiver receives both 4xx and 5xx-level > response codes (in different RAMS-I messages) during the same RAMS > session. >=20 > However not sure the final sentence correctly expresses what should be = conformed to. Presumably we have to select one and > only one response code when multiple are reported. Does this sentence = clearly specify which one is selected. Can there be > multiple 4xx responses? Yes, you select one (as the last sentence indicates). The sentence says = 5xx has higher priority over 4xx. There cannot be multiple 4xx responses = in the same RAMS session AFAICT. =20 > 16) Section 4.2, 1st paragraph: >=20 > To improve the reporting scope, it might be desirable to define new > fields in the MA report block. Such fields MUST be encoded as TLV > elements as described below and sketched in Figure 2: >=20 > Not sure this statement merits RFC 2119 language, and indeed I'm not = clear if this is a requirement on the definer of the > extension, or on the implementor of the extension. Better said "such fields are to be encoded ...". The requirement was = mentioned earlier. >=20 > 17) Section 4.2, 1st paragraph, length >=20 > o Length: A two-octet field that indicates the length (in octets) > of the TLV element excluding the Type and Length fields, and the > 8-bit Reserved field between them. Note that this length does = not > include any padding that is required for alignment. >=20 > Change "required" to "needed". Ok. =20 > 18) Section 4.2, 2nd paragraph and 3rd paragraphs: >=20 > In the extensions, the Reserved field SHALL be set to zero and > ignored on reception. If a TLV element does not fall on a 32-bit > boundary, the last word MUST be padded to the boundary using = further > bits set to zero. >=20 > In the MA report block, any vendor-neutral or private extension = MUST > be placed after the base report. >=20 > Again I am not clear whether this is a requirement on the definer of = the extension, or on the implementor of the extension. On the implementor. The place of the extension has nothing to do with = its definition. We could make it active sentence and clarify it. =20 > 19) Section 4.2.1, 2nd paragraph, 1st bullet: >=20 > o RTP Seqnum of the First Multicast Packet (16 bits): TLV element > that specifies the RTP sequence number of the first multicast > packet received for the primary multicast stream. If the > multicast join was successful, this element MUST exist. If no > multicast packet has been received, this element SHALL NOT = exist. >=20 > I assume the RFC 2119 language is a requirement on the implementation = of the RTP receiver. Please make this clear. >=20 > Note this comment also applies to many of the subsequent bullets. = Please review. OK. =20 > 20) Section 4.2.2, 1st paragraph: >=20 > It is desirable to allow vendors to use private extensions in TLV > format. For interoperability, such extensions MUST NOT collide = with > each other. >=20 > I don't believe I can assess conformance to such a statement unless I = know the scope of the uniqueness required. I suspect > this is something that should not use RFC 2119 language in the first = place. I can simply remove the second sentence since by definition extensions = will not collide between vendors. But if a vendor is na=EFve enough to = use the same type for different extensions, it is their problem. =20 > 21) Section 4.2.2, 3rd paragraph: >=20 > The structure that MUST be used for the private extensions is > depicted in Figure 3. Here, the private enterprise numbers are = used > from http://www.iana.org/assignments/enterprise-numbers. This will > ensure the uniqueness of the private extensions and avoid any > collision. >=20 > Again I am not clear whether this is a requirement on the definer of = the extension, or on the implementor of the extension. Will make this clear, too. =20 > 22) Section 5. >=20 > I believe there is a construct in ABNF that allows an existing = production to be extended using "/=3D" >=20 > I'm guessing here, but I think you are extending the following = production from RFC 3611: >=20 > xr-format =3D pkt-loss-rle > / pkt-dup-rle > / pkt-rcpt-times > / rcvr-rtt > / stat-summary > / voip-metrics > / format-ext >=20 > In which case I would expect to see something like >=20 > xr-format /=3D multicast-acq-ext >=20 > multicast-acq-ext =3D "multicast-acq" >=20 > along with a reference to RFC 3611 for the original production. I copied this part from RFC 5725 directly, I was suggested to write it = that way and it looked correct to me. Unless it is wrong, I wanna keep = it that way. =20 > 23) Section 6. 2nd paragraph >=20 > The information contained in MA reports could be stolen as any = other > RTCP reports if proper protection mechanism(s) are not in place. = If > desired, similar to other RTCP XR reports, the MA reports MAY be > protected by using Secure RTP (SRTP) and Secure RTP Control = Protocol > (SRTCP) [RFC3711]. >=20 > Used with "MAY" I believe RFC 3711 becomes a normative reference. = Currently it is only informative. Will move it to the normative part. =20 > 24) Section 6. 3rd paragraph >=20 > Using the MA reports to provide feedback into the acquisition of = the > multicast streams can introduce possible additional security > implications. If a forged or otherwise modified MA report is > received for an earlier acquisition attempt, invalid data may be = used > as input in later rapid acquisition attempts. For example, > incorrectly small SFGMP join times could cause the unicast burst to > be too short, leading to gaps in sequence numbers in the approach > discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. = Additionally, > forged reports could give the appearance that rapid acquisition is > performing correctly, when it is in fact failing, or vice versa. > However, the MA reports are believed not to introduce any = additional > risks from a confidentiality viewpoint. >=20 > Change "may" to "can". >=20 Ok. =20 > 25) Section 7. 1st paragraph >=20 > The following contact information shall be used for all = registrations > in this document: >=20 > Change to >=20 > The following contact information is provided for all registrations > in this document: Ok. =20 > 26) Section 7.4. Final bullet >=20 > o A detailed description of what the new Status code describes and > how it shall be interpreted. >=20 > Reword to: >=20 > o A detailed description of what the new Status code describes and > how it is interpreted. >=20 > Same change also to Section 7.5 final bullet. Ok. =20 > 27) Normative references. >=20 > RFC 5226 is not a normative reference. Move to informative references = section. Moved (FYI, both are acceptable to IESG AFAICT). -acbegen =20 >=20 > Regards >=20 > Keith From keith.drage@alcatel-lucent.com Wed Apr 6 07:05:15 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB343A69B5 for ; Wed, 6 Apr 2011 07:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.969 X-Spam-Level: X-Spam-Status: No, score=-106.969 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m7LDecdgEQv for ; Wed, 6 Apr 2011 07:05:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 148623A69B1 for ; Wed, 6 Apr 2011 07:05:13 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p36E6REA007642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Apr 2011 16:06:53 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Apr 2011 16:06:29 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org" Date: Wed, 6 Apr 2011 16:06:28 +0200 Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjgACh8LrA= Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:05:15 -0000 See below and deleting the ones you already plan to fix. Keith > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: 05 April 2011 18:58 > To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- > xr@tools.ietf.org > Cc: avtext@ietf.org > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in > preparation for pub request >=20 > Keith, >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Tuesday, April 05, 2011 12:25 PM > > To: Ali C. Begen (abegen); draft-ietf-avtext-multicast-acq-rtcp- > xr@tools.ietf.org > > Cc: avtext@ietf.org > > Subject: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in > preparation for pub request > > > > I've done a detailed review of this document before sending for > publication request. I'd appreciate it if you could address the > > following in a new version. By all means ask questions about any of the > comments. I don't believe any of these make a > > technical change to the document, but they should make it clearer. >=20 > > 1) General. There are a number of instances where SHALL is used in > the document. This means exactly the same as > > "MUST" and it would be more consistent to use "MUST" throughout. >=20 > Then, why did 2119 define "SHALL"? I prefer "SHALL" over "MUST" in certai= n > scenarios. This is a writing style preference. >=20 Coming from SDOs that inherently used "shall" I prefer it as well. The reas= on for using "shall" as opposed to "must" in ISO, CEN, CENELEC and ETSI is = that these standards have to be translated into other languages, and they h= ave chosen modal auxiliary verbs that are readily translatable without erro= r into other languages. The problem with "must" is the translation into the= equivalent German. I suspect the "SHALL" exists in RFC 2119 not to allow style, but to allow d= ouble publication of specifications from other SDOs as RFCs, without having= to change all the word. But my real complaint is not against the use of SHALL as opposed to MUST. I= t is the use of MUST in one sentence versus SHALL in the next sentence. Sta= ndards are not about the variability and richness of writing style. They ar= e about using things consistently so if the reader gets the correct interpr= etation from one usage to the next. So if you changed everything to "SHALL"= I would not have a problem - although other people might! > > 2) Abstract. > > > > In most RTP-based multicast applications, the RTP source sends inter= - > > related data. Due to this interdependency, randomly joining RTP > > receivers usually cannot start consuming the multicast data right > > after they join the session. Thus, they often experience a random > > acquisition delay. An RTP receiver may use one ore more different > > approaches to achieve rapid acquisition. Yet, due to various > > factors, performance of the rapid acquisition methods usually varies= . > > Furthermore, in some cases the RTP receiver may (or may have to) do = a > > simple multicast join. For quality reporting, monitoring and > > diagnostics purposes, it is important to collect detailed informatio= n > > from the RTP receivers about their acquisition and presentation > > experiences. This document addresses this issue by defining a new > > report block type, called Multicast Acquisition (MA) Report Block, > > within the framework of RTP Control Protocol (RTCP) Extended Reports > > (XR) (RFC 3611). This document also defines the necessary signaling > > of the new MA report block type in the Session Description Protocol > > (SDP). > > > > Replace two instances of "may" by "can" and an instance of "may have to= " > by "be compelled to", to avoid usage of RFC 2119 > > like language (even though lower case) >=20 > I think you are paying unnecessary attention here and in other paragraphs > you noted. Using such keywords in abstract or intro before 2119 usage is > introduced is absolutely fine - as noted by IESG in my earlier documents. > Again, this is pure writing style issue. >=20 This is not the most important comment for those sections that are recogniz= ed as purely informative. What I am trying to avoid with a lot of these cha= nges is people asking later on "This doesn't have capital letters but was a= requirement really meant". > > 8) Section 4. 4th paragraph. > > > > The MA report block is better to be sent after all the necessary > > information is collected and computed. Partial reporting is > > generally not useful as it may not give the full picture of the > > multicast acquisition, and causes additional complexity in terms of > > report block matching and correlation. The MA report block SHOULD > > only be sent as a part of an RTCP compound packet, and it is sent in > > the primary multicast session. > > > > I had some trouble parsing the 1st sentence, and I believe it is better > reworded as below. > > > > It is better to send the MA report block after all the necessary > > information is collected and computed. Partial reporting is > > generally not useful as it cannot give the full picture of the > > multicast acquisition, and causes additional complexity in terms of > > report block matching and correlation. The MA report block SHOULD > > only be sent as a part of an RTCP compound packet, and it is sent in > > the primary multicast session. >=20 > Rewording looks better. Thanks. >=20 > > Secondly, for the "SHOULD" usage, it is normal to provide additional > text identify use cases under which the "SHOULD" might > > or might not be deviated from. Otherwise implementors will trat it as a > straight option and we may as well have written > > "MAY". What do we really mean here? How do we check conformance? >=20 > There is no conformance check here. As Magnus suggested, we added this > text to clarify that this report block was sent as a part of the compound > packet. I don't see any reason why anybody would do it differently. But, > even if they do, no big deal, nothing will break and the world will not > collapse. Any proper RTP implementation has to follow certain rules > anyway, which we don't need to repeat here. >=20 So we will remove the "SHOULD from the following sentence??? > > report block matching and correlation. The MA report block SHOULD > > only be sent as a part of an RTCP compound packet, and it is sent in > > the primary multicast session. Becomes "The MA report block is only sent..." > > 12) Section 4.1.1. > > > > I would suggest splitting this subsection into two. The first would > cover the paragraphs relating to someone writing a new MA > > method, and should be titled something like "defining new MA methods". > The second would be the remaining material and > > should be entitled something like "use of status codes". The reason for > this is that the conformers to the statements are > > completely different. >=20 > I am not sure whether this will be clearer but I will look into it. >=20 The key here is that I am trying to separate the requirements into separate= sections that apply the specifier of a method from those applying to the i= mplementation (the latter which can therefore be tested on an implementatio= n). I don't really mind how such restructuring is done providing we get to = that intent. > > 15) Section 4.1.1, third paragraph > > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines > > several response codes for its MA method. The 1xx and 2xx-level > > response codes are informational and success response codes, > > respectively. If the RTP receiver receives a 1xx or 2xx-level > > response code, it MUST use one of the 1xxx-level status codes define= d > > in Section 7.5 of this document. The RTP receiver may also receive = a > > 4xx or 5xx-level response code (indicating receiver-side and server- > > side errors, respectively). In that case, the RTP receiver MUST use > > the response code as its status code. In other words, the 4xx and > > 5xx-level response codes have a higher priority than the 1xxx-level > > status codes. The 5xx-level response codes have a higher priority > > than the 4xx-level response codes and MUST be reported in the base > > report in case the RTP receiver receives both 4xx and 5xx-level > > response codes (in different RAMS-I messages) during the same RAMS > > session. > > > > I would suggest some minor rewording as follows: > > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines > > several response codes for its MA method. The 1xx and 2xx-level > > response codes are informational and success response codes, > > respectively. If the RTP receiver receives a 1xx or 2xx-level > > response code, then the RTP receiver MUST use one of the 1xxx-level > status codes defined > > in Section 7.5 of this document. If the RTP receiver receives a > > 4xx or 5xx-level response code (indicating receiver-side and server- > > side errors, respectively), then the RTP receiver MUST use > > the response code as its status code. In other words, the 4xx and > > 5xx-level response codes have a higher priority than the 1xxx-level > > status codes. The 5xx-level response codes have a higher priority > > than the 4xx-level response codes and MUST be reported in the base > > report in case the RTP receiver receives both 4xx and 5xx-level > > response codes (in different RAMS-I messages) during the same RAMS > > session. > > > > However not sure the final sentence correctly expresses what should be > conformed to. Presumably we have to select one and > > only one response code when multiple are reported. Does this sentence > clearly specify which one is selected. Can there be > > multiple 4xx responses? >=20 > Yes, you select one (as the last sentence indicates). The sentence says > 5xx has higher priority over 4xx. There cannot be multiple 4xx responses > in the same RAMS session AFAICT. >=20 OK, I think I understand. I think the text is still somewhat complex. How a= bout if we define a priority list as follows: "If multiple response codes are received for the RAMS MA method, the RTP re= ceiver MUST use only one response code, applying the following priority tab= le, where the code with the highest entry in the table represents the respo= nse code that is used. 5xx-level response codes 4xx-level response codes 1xx-level response codes 2xx-level response codes" > > > > 18) Section 4.2, 2nd paragraph and 3rd paragraphs: > > > > In the extensions, the Reserved field SHALL be set to zero and > > ignored on reception. If a TLV element does not fall on a 32-bit > > boundary, the last word MUST be padded to the boundary using further > > bits set to zero. > > > > In the MA report block, any vendor-neutral or private extension MUST > > be placed after the base report. > > > > Again I am not clear whether this is a requirement on the definer of th= e > extension, or on the implementor of the extension. >=20 > On the implementor. The place of the extension has nothing to do with its > definition. We could make it active sentence and clarify it. >=20 Please do. I like requirements in the active! > > 20) Section 4.2.2, 1st paragraph: > > > > It is desirable to allow vendors to use private extensions in TLV > > format. For interoperability, such extensions MUST NOT collide with > > each other. > > > > I don't believe I can assess conformance to such a statement unless I > know the scope of the uniqueness required. I suspect > > this is something that should not use RFC 2119 language in the first > place. >=20 > I can simply remove the second sentence since by definition extensions > will not collide between vendors. But if a vendor is na=EFve enough to us= e > the same type for different extensions, it is their problem. >=20 OK. > > 22) Section 5. > > > > I believe there is a construct in ABNF that allows an existing > production to be extended using "/=3D" > > > > I'm guessing here, but I think you are extending the following > production from RFC 3611: > > > > xr-format =3D pkt-loss-rle > > / pkt-dup-rle > > / pkt-rcpt-times > > / rcvr-rtt > > / stat-summary > > / voip-metrics > > / format-ext > > > > In which case I would expect to see something like > > > > xr-format /=3D multicast-acq-ext > > > > multicast-acq-ext =3D "multicast-acq" > > > > along with a reference to RFC 3611 for the original production. >=20 > I copied this part from RFC 5725 directly, I was suggested to write it > that way and it looked correct to me. Unless it is wrong, I wanna keep it > that way. >=20 I've seen comments on internet-drafts elsewhere making the same comment. I = don't know how recent this construct is. The publication request process do= es ask the shepherd to verify the ABNF, and the only means of doing that is= providing the construct I have identified, rather than the one in the curr= ent i-d. I'll ask Gonzalo for his expections, as I'm not really an ABNF expert. >=20 > -acbegen >=20 > > > > Regards > > > > Keith From abegen@cisco.com Wed Apr 6 07:18:45 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE7D28C0E4 for ; Wed, 6 Apr 2011 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLyQdVuEECoD for ; Wed, 6 Apr 2011 07:18:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0C08E28C0DB for ; Wed, 6 Apr 2011 07:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3873; q=dns/txt; s=iport; t=1302099628; x=1303309228; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=D8SJuLHzBfEBW4HVVehsAtmbu3jWjNvq1O1qwQ6fYjI=; b=OJnKA0J99WOuYUHwCjm1zH4M6WVHPHog/qg+pP7ZsxrlMxCfMLtoJwWi GjPEhyD8wOijkc8UpatZYPgWlpeUS/eO2vRw3GcYG+pFDCpaoYwOvdlW6 PJJjdpGW1c0v8xI7Z6ghQ1VzVapunFBH61hOGPEvkavyu5cAjKk6eqck6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADJ2nE2rRDoI/2dsb2JhbACleHeIeZw+nDOCfYJvBIVOi1c X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="331754641" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 14:20:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36EKS61013928; Wed, 6 Apr 2011 14:20:28 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 07:20:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 07:20:26 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjgACh8LrAAA+o08A== References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 06 Apr 2011 14:20:27.0957 (UTC) FILETIME=[C71C0E50:01CBF465] Cc: avtext@ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:18:45 -0000 Two minor comments below. > > > I had some trouble parsing the 1st sentence, and I believe it is = better > > reworded as below. > > > > > > It is better to send the MA report block after all the = necessary > > > information is collected and computed. Partial reporting is > > > generally not useful as it cannot give the full picture of the > > > multicast acquisition, and causes additional complexity in = terms of > > > report block matching and correlation. The MA report block = SHOULD > > > only be sent as a part of an RTCP compound packet, and it is = sent in > > > the primary multicast session. > > > > Rewording looks better. Thanks. > > > > > Secondly, for the "SHOULD" usage, it is normal to provide = additional > > text identify use cases under which the "SHOULD" might > > > or might not be deviated from. Otherwise implementors will trat it = as a > > straight option and we may as well have written > > > "MAY". What do we really mean here? How do we check conformance? > > > > There is no conformance check here. As Magnus suggested, we added = this > > text to clarify that this report block was sent as a part of the = compound > > packet. I don't see any reason why anybody would do it differently. = But, > > even if they do, no big deal, nothing will break and the world will = not > > collapse. Any proper RTP implementation has to follow certain rules > > anyway, which we don't need to repeat here. > > >=20 > So we will remove the "SHOULD from the following sentence??? >=20 > > > report block matching and correlation. The MA report block = SHOULD > > > only be sent as a part of an RTCP compound packet, and it is = sent in > > > the primary multicast session. >=20 > Becomes "The MA report block is only sent..." Sure. =20 > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] = defines > > > several response codes for its MA method. The 1xx and = 2xx-level > > > response codes are informational and success response codes, > > > respectively. If the RTP receiver receives a 1xx or 2xx-level > > > response code, then the RTP receiver MUST use one of the = 1xxx-level > > status codes defined > > > in Section 7.5 of this document. If the RTP receiver receives = a > > > 4xx or 5xx-level response code (indicating receiver-side and = server- > > > side errors, respectively), then the RTP receiver MUST use > > > the response code as its status code. In other words, the 4xx = and > > > 5xx-level response codes have a higher priority than the = 1xxx-level > > > status codes. The 5xx-level response codes have a higher = priority > > > than the 4xx-level response codes and MUST be reported in the = base > > > report in case the RTP receiver receives both 4xx and 5xx-level > > > response codes (in different RAMS-I messages) during the same = RAMS > > > session. > > > > > > However not sure the final sentence correctly expresses what = should be > > conformed to. Presumably we have to select one and > > > only one response code when multiple are reported. Does this = sentence > > clearly specify which one is selected. Can there be > > > multiple 4xx responses? > > > > Yes, you select one (as the last sentence indicates). The sentence = says > > 5xx has higher priority over 4xx. There cannot be multiple 4xx = responses > > in the same RAMS session AFAICT. > > > OK, I think I understand. I think the text is still somewhat complex. = How about if we define a priority list as follows: Actually, we realized that there won't be any case where the receiver = gets both 4xx and 5xx responses. So, the sentence is removed. =20 I will replace all the SHALLs with a MUST just for you, Keith. Expect the revision shortly. -acbegen From Internet-Drafts@ietf.org Wed Apr 6 07:45:03 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0823928C112; Wed, 6 Apr 2011 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JLBVOgYLQ2F; Wed, 6 Apr 2011 07:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F29B28C10E; Wed, 6 Apr 2011 07:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110406144502.15640.9106.idtracker@localhost> Date: Wed, 06 Apr 2011 07:45:02 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action:draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Author(s) : A. Begen, E. Friedrich Filename : draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt Pages : 21 Date : 2011-04-06 In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can (or be compelled to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-06074235.I-D@ietf.org> --NextPart-- From keith.drage@alcatel-lucent.com Wed Apr 6 09:30:25 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0C33A69DD for ; Wed, 6 Apr 2011 09:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvtTjLzDu-Zm for ; Wed, 6 Apr 2011 09:30:23 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E5FEB3A69DB for ; Wed, 6 Apr 2011 09:30:21 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p36GVv1S000613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Apr 2011 18:32:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 6 Apr 2011 18:31:59 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org" Date: Wed, 6 Apr 2011 18:31:58 +0200 Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjgACh8LrAAA+o08AAEhVhQ Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:30:25 -0000 Thanks. Just reviewing (again) the IANA section, and noticed the following. Section 7.1. 7.1. RTCP XR Block Type Type value 11 has been pre-registered with IANA for the "Multicast Acquisition Report Block" in the RTCP XR Block Type Registry. This IANA action was already performed by the RAMS draft, and therefore the= re is no IANA action associated with this parameter. As such it is sensible= not to include this section, unless you feel it is appropriate to add this= draft as a reference in the existing IANA registry entry (in which case th= e section needs to be redrafted to say this). Regards Keith > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: 06 April 2011 15:20 > To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- > xr@tools.ietf.org > Cc: avtext@ietf.org > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in > preparation for pub request >=20 > Two minor comments below. >=20 > > > > I had some trouble parsing the 1st sentence, and I believe it is > better > > > reworded as below. > > > > > > > > It is better to send the MA report block after all the necessary > > > > information is collected and computed. Partial reporting is > > > > generally not useful as it cannot give the full picture of the > > > > multicast acquisition, and causes additional complexity in terms > of > > > > report block matching and correlation. The MA report block > SHOULD > > > > only be sent as a part of an RTCP compound packet, and it is sen= t > in > > > > the primary multicast session. > > > > > > Rewording looks better. Thanks. > > > > > > > Secondly, for the "SHOULD" usage, it is normal to provide additiona= l > > > text identify use cases under which the "SHOULD" might > > > > or might not be deviated from. Otherwise implementors will trat it > as a > > > straight option and we may as well have written > > > > "MAY". What do we really mean here? How do we check conformance? > > > > > > There is no conformance check here. As Magnus suggested, we added thi= s > > > text to clarify that this report block was sent as a part of the > compound > > > packet. I don't see any reason why anybody would do it differently. > But, > > > even if they do, no big deal, nothing will break and the world will > not > > > collapse. Any proper RTP implementation has to follow certain rules > > > anyway, which we don't need to repeat here. > > > > > > > So we will remove the "SHOULD from the following sentence??? > > > > > > report block matching and correlation. The MA report block > SHOULD > > > > only be sent as a part of an RTCP compound packet, and it is sen= t > in > > > > the primary multicast session. > > > > Becomes "The MA report block is only sent..." >=20 > Sure. >=20 > > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines > > > > several response codes for its MA method. The 1xx and 2xx-level > > > > response codes are informational and success response codes, > > > > respectively. If the RTP receiver receives a 1xx or 2xx-level > > > > response code, then the RTP receiver MUST use one of the 1xxx- > level > > > status codes defined > > > > in Section 7.5 of this document. If the RTP receiver receives a > > > > 4xx or 5xx-level response code (indicating receiver-side and > server- > > > > side errors, respectively), then the RTP receiver MUST use > > > > the response code as its status code. In other words, the 4xx > and > > > > 5xx-level response codes have a higher priority than the 1xxx- > level > > > > status codes. The 5xx-level response codes have a higher > priority > > > > than the 4xx-level response codes and MUST be reported in the > base > > > > report in case the RTP receiver receives both 4xx and 5xx-level > > > > response codes (in different RAMS-I messages) during the same > RAMS > > > > session. > > > > > > > > However not sure the final sentence correctly expresses what should > be > > > conformed to. Presumably we have to select one and > > > > only one response code when multiple are reported. Does this > sentence > > > clearly specify which one is selected. Can there be > > > > multiple 4xx responses? > > > > > > Yes, you select one (as the last sentence indicates). The sentence > says > > > 5xx has higher priority over 4xx. There cannot be multiple 4xx > responses > > > in the same RAMS session AFAICT. > > > > > OK, I think I understand. I think the text is still somewhat complex. > How about if we define a priority list as follows: >=20 > Actually, we realized that there won't be any case where the receiver get= s > both 4xx and 5xx responses. So, the sentence is removed. >=20 > I will replace all the SHALLs with a MUST just for you, Keith. >=20 > Expect the revision shortly. >=20 > -acbegen From abegen@cisco.com Wed Apr 6 09:36:23 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D683A69CC for ; Wed, 6 Apr 2011 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTlCD22I9qVA for ; Wed, 6 Apr 2011 09:36:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E2773A67CF for ; Wed, 6 Apr 2011 09:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=5994; q=dns/txt; s=iport; t=1302107885; x=1303317485; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=L0PhRpC6QaQkt2tjgs0wgqdEqJ0zb/ordbdIL1DBQY0=; b=AV+IiY43N86KCavv2AX2icc7x2On+V1gb7MBH5qLlxCD+p8gJFK9oBcz gQsOA9JxTE8FAdp5RWxwXyVoxRGUZEncshKLB/XscPKDVsWW/PXSUjPJK wzDA2UcvzKDpsr0nSLE63uuoIHqVcniQd7OnpJLxo01PCEa3NExgJHXIA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAOSVnE2tJXG8/2dsb2JhbACYLY1Ld4h5nGucR4J9gm8EhU6LVw X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="676746368" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2011 16:38:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p36Gc48l006645; Wed, 6 Apr 2011 16:38:05 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 09:38:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 09:37:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EB56A45@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjgACh8LrAAA+o08AAEhVhQAABZeIA= References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 06 Apr 2011 16:38:04.0510 (UTC) FILETIME=[00660FE0:01CBF479] Cc: avtext@ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:36:23 -0000 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Wednesday, April 06, 2011 12:32 PM > To: Ali C. Begen (abegen); = draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org > Cc: avtext@ietf.org > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in = preparation for pub request >=20 > Thanks. >=20 > Just reviewing (again) the IANA section, and noticed the following. >=20 > Section 7.1. >=20 > 7.1. RTCP XR Block Type >=20 > Type value 11 has been pre-registered with IANA for the "Multicast > Acquisition Report Block" in the RTCP XR Block Type Registry. >=20 > This IANA action was already performed by the RAMS draft, and = therefore there is no IANA action associated with this No, it was not performed by the RAMS draft. It was registered = externally. > parameter. As such it is sensible not to include this section, unless = you feel it is appropriate to add this draft as a reference in > the existing IANA registry entry (in which case the section needs to = be redrafted to say this). Until this becomes an RFC, we need to keep this text around to let = people know what will be used for this XR block. If the RFC editor feels = appropriate, she can remove the sentence at that time. -acbegen =20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: 06 April 2011 15:20 > > To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- > > xr@tools.ietf.org > > Cc: avtext@ietf.org > > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 = in > > preparation for pub request > > > > Two minor comments below. > > > > > > > I had some trouble parsing the 1st sentence, and I believe it = is > > better > > > > reworded as below. > > > > > > > > > > It is better to send the MA report block after all the = necessary > > > > > information is collected and computed. Partial reporting = is > > > > > generally not useful as it cannot give the full picture of = the > > > > > multicast acquisition, and causes additional complexity in = terms > > of > > > > > report block matching and correlation. The MA report block > > SHOULD > > > > > only be sent as a part of an RTCP compound packet, and it = is sent > > in > > > > > the primary multicast session. > > > > > > > > Rewording looks better. Thanks. > > > > > > > > > Secondly, for the "SHOULD" usage, it is normal to provide = additional > > > > text identify use cases under which the "SHOULD" might > > > > > or might not be deviated from. Otherwise implementors will = trat it > > as a > > > > straight option and we may as well have written > > > > > "MAY". What do we really mean here? How do we check = conformance? > > > > > > > > There is no conformance check here. As Magnus suggested, we = added this > > > > text to clarify that this report block was sent as a part of the > > compound > > > > packet. I don't see any reason why anybody would do it = differently. > > But, > > > > even if they do, no big deal, nothing will break and the world = will > > not > > > > collapse. Any proper RTP implementation has to follow certain = rules > > > > anyway, which we don't need to repeat here. > > > > > > > > > > So we will remove the "SHOULD from the following sentence??? > > > > > > > > report block matching and correlation. The MA report block > > SHOULD > > > > > only be sent as a part of an RTCP compound packet, and it = is sent > > in > > > > > the primary multicast session. > > > > > > Becomes "The MA report block is only sent..." > > > > Sure. > > > > > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] = defines > > > > > several response codes for its MA method. The 1xx and = 2xx-level > > > > > response codes are informational and success response = codes, > > > > > respectively. If the RTP receiver receives a 1xx or = 2xx-level > > > > > response code, then the RTP receiver MUST use one of the = 1xxx- > > level > > > > status codes defined > > > > > in Section 7.5 of this document. If the RTP receiver = receives a > > > > > 4xx or 5xx-level response code (indicating receiver-side = and > > server- > > > > > side errors, respectively), then the RTP receiver MUST use > > > > > the response code as its status code. In other words, the = 4xx > > and > > > > > 5xx-level response codes have a higher priority than the = 1xxx- > > level > > > > > status codes. The 5xx-level response codes have a higher > > priority > > > > > than the 4xx-level response codes and MUST be reported in = the > > base > > > > > report in case the RTP receiver receives both 4xx and = 5xx-level > > > > > response codes (in different RAMS-I messages) during the = same > > RAMS > > > > > session. > > > > > > > > > > However not sure the final sentence correctly expresses what = should > > be > > > > conformed to. Presumably we have to select one and > > > > > only one response code when multiple are reported. Does this > > sentence > > > > clearly specify which one is selected. Can there be > > > > > multiple 4xx responses? > > > > > > > > Yes, you select one (as the last sentence indicates). The = sentence > > says > > > > 5xx has higher priority over 4xx. There cannot be multiple 4xx > > responses > > > > in the same RAMS session AFAICT. > > > > > > > OK, I think I understand. I think the text is still somewhat = complex. > > How about if we define a priority list as follows: > > > > Actually, we realized that there won't be any case where the = receiver gets > > both 4xx and 5xx responses. So, the sentence is removed. > > > > I will replace all the SHALLs with a MUST just for you, Keith. > > > > Expect the revision shortly. > > > > -acbegen From keith.drage@alcatel-lucent.com Thu Apr 7 02:17:34 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69ABE3A68D6 for ; Thu, 7 Apr 2011 02:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gCuGejbpd6o for ; Thu, 7 Apr 2011 02:17:33 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3DC9B3A68DF for ; Thu, 7 Apr 2011 02:17:33 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p379JBRE015395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Apr 2011 11:19:14 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Apr 2011 11:19:13 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org" Date: Thu, 7 Apr 2011 11:19:12 +0200 Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: AcvzrgRAtVEO0O1FT3CaCh6LwBkTfAABZBjgACh8LrAAA+o08AAEhVhQAABZeIAABEWeIA== Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB56A45@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EB56A45@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 09:17:34 -0000 Right OK, I get it now. So the question I need to ask is whether section 7.1 instructs IANA clearly= in how they need to change their registration tables from how they are now= to what they should be once this internet draft is published as an RFC. So essentially they need an instruction to replace the current reference as= sociated with this registered value (which is a previous version of this dr= aft under a different name) to the number of this RFC. Regards Keith > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: 06 April 2011 17:37 > To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- > xr@tools.ietf.org > Cc: avtext@ietf.org > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in > preparation for pub request >=20 >=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Wednesday, April 06, 2011 12:32 PM > > To: Ali C. Begen (abegen); draft-ietf-avtext-multicast-acq-rtcp- > xr@tools.ietf.org > > Cc: avtext@ietf.org > > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in > preparation for pub request > > > > Thanks. > > > > Just reviewing (again) the IANA section, and noticed the following. > > > > Section 7.1. > > > > 7.1. RTCP XR Block Type > > > > Type value 11 has been pre-registered with IANA for the "Multicast > > Acquisition Report Block" in the RTCP XR Block Type Registry. > > > > This IANA action was already performed by the RAMS draft, and therefore > there is no IANA action associated with this >=20 > No, it was not performed by the RAMS draft. It was registered externally= . >=20 > > parameter. As such it is sensible not to include this section, unless > you feel it is appropriate to add this draft as a reference in > > the existing IANA registry entry (in which case the section needs to be > redrafted to say this). >=20 > Until this becomes an RFC, we need to keep this text around to let people > know what will be used for this XR block. If the RFC editor feels > appropriate, she can remove the sentence at that time. >=20 > -acbegen >=20 > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: 06 April 2011 15:20 > > > To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- > > > xr@tools.ietf.org > > > Cc: avtext@ietf.org > > > Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 i= n > > > preparation for pub request > > > > > > Two minor comments below. > > > > > > > > > I had some trouble parsing the 1st sentence, and I believe it i= s > > > better > > > > > reworded as below. > > > > > > > > > > > > It is better to send the MA report block after all the > necessary > > > > > > information is collected and computed. Partial reporting is > > > > > > generally not useful as it cannot give the full picture of > the > > > > > > multicast acquisition, and causes additional complexity in > terms > > > of > > > > > > report block matching and correlation. The MA report block > > > SHOULD > > > > > > only be sent as a part of an RTCP compound packet, and it is > sent > > > in > > > > > > the primary multicast session. > > > > > > > > > > Rewording looks better. Thanks. > > > > > > > > > > > Secondly, for the "SHOULD" usage, it is normal to provide > additional > > > > > text identify use cases under which the "SHOULD" might > > > > > > or might not be deviated from. Otherwise implementors will trat > it > > > as a > > > > > straight option and we may as well have written > > > > > > "MAY". What do we really mean here? How do we check conformance= ? > > > > > > > > > > There is no conformance check here. As Magnus suggested, we added > this > > > > > text to clarify that this report block was sent as a part of the > > > compound > > > > > packet. I don't see any reason why anybody would do it > differently. > > > But, > > > > > even if they do, no big deal, nothing will break and the world > will > > > not > > > > > collapse. Any proper RTP implementation has to follow certain > rules > > > > > anyway, which we don't need to repeat here. > > > > > > > > > > > > > So we will remove the "SHOULD from the following sentence??? > > > > > > > > > > report block matching and correlation. The MA report block > > > SHOULD > > > > > > only be sent as a part of an RTCP compound packet, and it is > sent > > > in > > > > > > the primary multicast session. > > > > > > > > Becomes "The MA report block is only sent..." > > > > > > Sure. > > > > > > > > > Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] > defines > > > > > > several response codes for its MA method. The 1xx and 2xx- > level > > > > > > response codes are informational and success response codes, > > > > > > respectively. If the RTP receiver receives a 1xx or 2xx- > level > > > > > > response code, then the RTP receiver MUST use one of the > 1xxx- > > > level > > > > > status codes defined > > > > > > in Section 7.5 of this document. If the RTP receiver > receives a > > > > > > 4xx or 5xx-level response code (indicating receiver-side and > > > server- > > > > > > side errors, respectively), then the RTP receiver MUST use > > > > > > the response code as its status code. In other words, the > 4xx > > > and > > > > > > 5xx-level response codes have a higher priority than the > 1xxx- > > > level > > > > > > status codes. The 5xx-level response codes have a higher > > > priority > > > > > > than the 4xx-level response codes and MUST be reported in th= e > > > base > > > > > > report in case the RTP receiver receives both 4xx and 5xx- > level > > > > > > response codes (in different RAMS-I messages) during the sam= e > > > RAMS > > > > > > session. > > > > > > > > > > > > However not sure the final sentence correctly expresses what > should > > > be > > > > > conformed to. Presumably we have to select one and > > > > > > only one response code when multiple are reported. Does this > > > sentence > > > > > clearly specify which one is selected. Can there be > > > > > > multiple 4xx responses? > > > > > > > > > > Yes, you select one (as the last sentence indicates). The sentenc= e > > > says > > > > > 5xx has higher priority over 4xx. There cannot be multiple 4xx > > > responses > > > > > in the same RAMS session AFAICT. > > > > > > > > > OK, I think I understand. I think the text is still somewhat > complex. > > > How about if we define a priority list as follows: > > > > > > Actually, we realized that there won't be any case where the receiver > gets > > > both 4xx and 5xx responses. So, the sentence is removed. > > > > > > I will replace all the SHALLs with a MUST just for you, Keith. > > > > > > Expect the revision shortly. > > > > > > -acbegen From abegen@cisco.com Thu Apr 7 03:55:53 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EDF28C0DF for ; Thu, 7 Apr 2011 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.534 X-Spam-Level: X-Spam-Status: No, score=-7.534 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbpexjWM1Kyx for ; Thu, 7 Apr 2011 03:55:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 478593A68FC for ; Thu, 7 Apr 2011 03:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=7232; q=dns/txt; s=iport; t=1302173857; x=1303383457; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=HgtpZ9Ug/+X/Ce4jn0Lfi/xBUsgrfo4MEM96/XVxBeo=; b=cSKJP88ZBapTkzfnfKTa/ocdoJi/SGK5tdUTJ2GgSNy0JmZ4WRzBVtcc QYNKkVQomF6GuyjqcsG13MvMEy53cgB9Vh+6S6JPdo6eb9wAzxovzKhXU OV487pUc55N3r+XAX4ojN4WMw0jqFzo4D5QM6o6agZlrQgusXGVaHAUCH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAGiYnU2rRDoI/2dsb2JhbACYNIxoZgJ3iHmcM5xlgn6CbwSNRYNv X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="291177201" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 10:57:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37AvaYZ022951; Thu, 7 Apr 2011 10:57:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 03:57:36 -0700 Received: from 72.163.63.12 ([72.163.63.12]) by xmb-sjc-215.amer.cisco.com ([171.70.151.169]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Apr 2011 10:57:33 +0000 References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB56A45@xmb-sjc-215.amer.cisco.com> Content-Transfer-Encoding: quoted-printable From: "Ali C. Begen (abegen)" Thread-Topic: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request Thread-Index: Acv1Epj1X6Vw7fi9T4Ky3WYZJrghkg== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: <31512160-BC84-4406-8D1A-21A8B547DC4E@cisco.com> Date: Thu, 7 Apr 2011 06:57:28 -0400 To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 (iPhone Mail 8G4) X-OriginalArrivalTime: 07 Apr 2011 10:57:36.0614 (UTC) FILETIME=[9AD64060:01CBF512] Cc: avtext@ietf.org, draft-ietf-avtext-multicast-acq-rtcp-xr@tools.ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:55:53 -0000 It turns out that iana is enough smart to make that change automatically. Th= ey did it before in rfc 5725.=20 I think the text right now is quite adequate for it.=20 -acbegen On Apr 7, 2011, at 5:19 AM, "DRAGE, Keith (Keith)" wrote: > Right OK, I get it now. >=20 > So the question I need to ask is whether section 7.1 instructs IANA clearl= y in how they need to change their registration tables from how they are now= to what they should be once this internet draft is published as an RFC. >=20 > So essentially they need an instruction to replace the current reference a= ssociated with this registered value (which is a previous version of this dr= aft under a different name) to the number of this RFC. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: 06 April 2011 17:37 >> To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- >> xr@tools.ietf.org >> Cc: avtext@ietf.org >> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in >> preparation for pub request >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] >>> Sent: Wednesday, April 06, 2011 12:32 PM >>> To: Ali C. Begen (abegen); draft-ietf-avtext-multicast-acq-rtcp- >> xr@tools.ietf.org >>> Cc: avtext@ietf.org >>> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in >> preparation for pub request >>>=20 >>> Thanks. >>>=20 >>> Just reviewing (again) the IANA section, and noticed the following. >>>=20 >>> Section 7.1. >>>=20 >>> 7.1. RTCP XR Block Type >>>=20 >>> Type value 11 has been pre-registered with IANA for the "Multicast >>> Acquisition Report Block" in the RTCP XR Block Type Registry. >>>=20 >>> This IANA action was already performed by the RAMS draft, and therefore >> there is no IANA action associated with this >>=20 >> No, it was not performed by the RAMS draft. It was registered externally= . >>=20 >>> parameter. As such it is sensible not to include this section, unless >> you feel it is appropriate to add this draft as a reference in >>> the existing IANA registry entry (in which case the section needs to be >> redrafted to say this). >>=20 >> Until this becomes an RFC, we need to keep this text around to let people= >> know what will be used for this XR block. If the RFC editor feels >> appropriate, she can remove the sentence at that time. >>=20 >> -acbegen >>=20 >>> Regards >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: 06 April 2011 15:20 >>>> To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp- >>>> xr@tools.ietf.org >>>> Cc: avtext@ietf.org >>>> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in >>>> preparation for pub request >>>>=20 >>>> Two minor comments below. >>>>=20 >>>>>>> I had some trouble parsing the 1st sentence, and I believe it is >>>> better >>>>>> reworded as below. >>>>>>>=20 >>>>>>> It is better to send the MA report block after all the >> necessary >>>>>>> information is collected and computed. Partial reporting is >>>>>>> generally not useful as it cannot give the full picture of >> the >>>>>>> multicast acquisition, and causes additional complexity in >> terms >>>> of >>>>>>> report block matching and correlation. The MA report block >>>> SHOULD >>>>>>> only be sent as a part of an RTCP compound packet, and it is >> sent >>>> in >>>>>>> the primary multicast session. >>>>>>=20 >>>>>> Rewording looks better. Thanks. >>>>>>=20 >>>>>>> Secondly, for the "SHOULD" usage, it is normal to provide >> additional >>>>>> text identify use cases under which the "SHOULD" might >>>>>>> or might not be deviated from. Otherwise implementors will trat >> it >>>> as a >>>>>> straight option and we may as well have written >>>>>>> "MAY". What do we really mean here? How do we check conformance? >>>>>>=20 >>>>>> There is no conformance check here. As Magnus suggested, we added >> this >>>>>> text to clarify that this report block was sent as a part of the >>>> compound >>>>>> packet. I don't see any reason why anybody would do it >> differently. >>>> But, >>>>>> even if they do, no big deal, nothing will break and the world >> will >>>> not >>>>>> collapse. Any proper RTP implementation has to follow certain >> rules >>>>>> anyway, which we don't need to repeat here. >>>>>>=20 >>>>>=20 >>>>> So we will remove the "SHOULD from the following sentence??? >>>>>=20 >>>>>>> report block matching and correlation. The MA report block >>>> SHOULD >>>>>>> only be sent as a part of an RTCP compound packet, and it is >> sent >>>> in >>>>>>> the primary multicast session. >>>>>=20 >>>>> Becomes "The MA report block is only sent..." >>>>=20 >>>> Sure. >>>>=20 >>>>>>> Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] >> defines >>>>>>> several response codes for its MA method. The 1xx and 2xx- >> level >>>>>>> response codes are informational and success response codes, >>>>>>> respectively. If the RTP receiver receives a 1xx or 2xx- >> level >>>>>>> response code, then the RTP receiver MUST use one of the >> 1xxx- >>>> level >>>>>> status codes defined >>>>>>> in Section 7.5 of this document. If the RTP receiver >> receives a >>>>>>> 4xx or 5xx-level response code (indicating receiver-side and >>>> server- >>>>>>> side errors, respectively), then the RTP receiver MUST use >>>>>>> the response code as its status code. In other words, the >> 4xx >>>> and >>>>>>> 5xx-level response codes have a higher priority than the >> 1xxx- >>>> level >>>>>>> status codes. The 5xx-level response codes have a higher >>>> priority >>>>>>> than the 4xx-level response codes and MUST be reported in the >>>> base >>>>>>> report in case the RTP receiver receives both 4xx and 5xx- >> level >>>>>>> response codes (in different RAMS-I messages) during the same >>>> RAMS >>>>>>> session. >>>>>>>=20 >>>>>>> However not sure the final sentence correctly expresses what >> should >>>> be >>>>>> conformed to. Presumably we have to select one and >>>>>>> only one response code when multiple are reported. Does this >>>> sentence >>>>>> clearly specify which one is selected. Can there be >>>>>>> multiple 4xx responses? >>>>>>=20 >>>>>> Yes, you select one (as the last sentence indicates). The sentence >>>> says >>>>>> 5xx has higher priority over 4xx. There cannot be multiple 4xx >>>> responses >>>>>> in the same RAMS session AFAICT. >>>>>>=20 >>>>> OK, I think I understand. I think the text is still somewhat >> complex. >>>> How about if we define a priority list as follows: >>>>=20 >>>> Actually, we realized that there won't be any case where the receiver >> gets >>>> both 4xx and 5xx responses. So, the sentence is removed. >>>>=20 >>>> I will replace all the SHALLs with a MUST just for you, Keith. >>>>=20 >>>> Expect the revision shortly. >>>>=20 >>>> -acbegen From magnus.westerlund@ericsson.com Fri Apr 8 08:16:16 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FDB3A693B for ; Fri, 8 Apr 2011 08:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQnq76pJKYXt for ; Fri, 8 Apr 2011 08:16:15 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1BAFB3A6819 for ; Fri, 8 Apr 2011 08:16:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-03-4d9f27264512 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 01.7C.11171.6272F9D4; Fri, 8 Apr 2011 17:17:59 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Apr 2011 17:17:58 +0200 Message-ID: <4D9F2726.9090701@ericsson.com> Date: Fri, 8 Apr 2011 17:17:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eric Friedrich References: <20110330135205.6BA313A6B57@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540EAACB8F@xmb-sjc-215.amer.cisco.com> <4D998EB8.9070007@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-ietf-avtext-multicast-acq-rtcp-xr-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:16:16 -0000 Eric Friedrich skrev 2011-04-04 22:04: > Hi Magnus, > Thanks for the comments. Would you be ok with the addition of the > following text to Section 6? > > "MA report integrity can be provided by SRTP and SRTCP. > > Malicious sniffing or otherwise obtaining MA report blocks can reveal > performance characteristics of the RTP service and underlying network. > This information is already available to an observer with the ability > to capture RTP + RTCP session traffic. > > The contents and value of any private vendor extensions should be > studied when considering the need to secure the MA report. Application- > level performance data may be present that is not otherwise available > to an attacker as with the required fields and vendor neutral > extensions." Yes, it at least points towards the information leakage that do occur. 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 8 08:26:10 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0853A6943 for ; Fri, 8 Apr 2011 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAEyPsFsy4Qd for ; Fri, 8 Apr 2011 08:26:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DEADE3A693B for ; Fri, 8 Apr 2011 08:26:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-7c-4d9f297ab526 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 89.4D.11171.A792F9D4; Fri, 8 Apr 2011 17:27:54 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Apr 2011 17:27:54 +0200 Message-ID: <4D9F297A.7020309@ericsson.com> Date: Fri, 8 Apr 2011 17:27:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: avtext@ietf.org References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> In-Reply-To: <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:26:10 -0000 Roni Even skrev 2011-04-04 21:54: > Colin, > I think that the case with the requirement to undetectability is a simple > translator, is there something specific in this case. > > My view was that if we take undetectability away and use a translator or a > mixer it becomes an RFC3550 translator/mixer and we just point to RFC 3550. > > I am still not sure why we made splicing using translator and not RTP mixer > which seemed to me a better fit. > Roni, There is nothing simple about this splicing operation. Especially if you attempt to do it undetectable. Even a regular translator that can be detected with the purpose of splicing in content do needs some significant consideration. I think the simplest is the mixer. But also there the RFC 3550 isn't not a source of clarity on what you need to do to maintain RTP correctness on the different sides. When it comes to the mixer vs translator case, I think one reason was this non-detectable requirement. Another aspect of it is has to do with bit-rate adaptation to handle varying network conditions. A Mixer does kind of cut off the feedback loop between the receiver and the sender. To bridge that one needs additional RTCP messages. In the context of a translator one can make this operate at least in the following way. From primary perspective it can see the full path to the receiver when the splicer is passing its content. And when the splicer insert the alternative content it could get a report on the path up to the splicer itself. I think we need to discuss what our goals really are here. Are they only to provide the receiver with a consistent media stream despite the splicing? Or does one try to take additional steps to hide the existence of the splicer from the receivers perspective? 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 daveoran@orandom.net Fri Apr 8 08:42:04 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B0B3A681F for ; Fri, 8 Apr 2011 08:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wlf+OpJJXZ0 for ; Fri, 8 Apr 2011 08:42:03 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by core3.amsl.com (Postfix) with ESMTP id 1449C3A6819 for ; Fri, 8 Apr 2011 08:42:02 -0700 (PDT) Received: from [10.32.245.157] (c-24-62-229-193.hsd1.ma.comcast.net [24.62.229.193]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p38FiI0R003280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 08:44:18 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: David R Oran In-Reply-To: <4D9F297A.7020309@ericsson.com> Date: Fri, 8 Apr 2011 11:43:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:42:04 -0000 I tend to agree with Magnus' assessment. There seems also to be an additional (only implicitly stated) = requirement that people need to internalize (at least I think there is = after a number of discussions with the proponents). That is the ability of the translator to have minimal (or zero) overhead = when content is not being actively spliced. I believe the system model = the proponents have in their heads is one in which a system sitting in = the middle of the network somewhere can have many RTP sessions flowing = "through" , or "around" it, and only incur translator overhead during an = actual splice operation, and possibly for a short period surrounding the = splice. In other words, I'm presuming there's a scalability requirement = of the form: "the overhead must scale with the number of active splices, = not with the number of RTP sessions flowing through the intermediary". I suspect this has substantial impact, perhaps not as great as the = non-detectability requirement, but worth pondering for sure. DaveO. On Apr 8, 2011, at 11:27 AM, Magnus Westerlund wrote: > Roni Even skrev 2011-04-04 21:54: >> Colin, >> I think that the case with the requirement to undetectability is a = simple >> translator, is there something specific in this case.=20 >>=20 >> My view was that if we take undetectability away and use a translator = or a >> mixer it becomes an RFC3550 translator/mixer and we just point to RFC = 3550. >>=20 >> I am still not sure why we made splicing using translator and not RTP = mixer >> which seemed to me a better fit. >>=20 >=20 > Roni, >=20 > There is nothing simple about this splicing operation. Especially if = you > attempt to do it undetectable. Even a regular translator that can be > detected with the purpose of splicing in content do needs some > significant consideration. I think the simplest is the mixer. But also > there the RFC 3550 isn't not a source of clarity on what you need to = do > to maintain RTP correctness on the different sides. >=20 > When it comes to the mixer vs translator case, I think one reason was > this non-detectable requirement. Another aspect of it is has to do = with > bit-rate adaptation to handle varying network conditions. A Mixer does > kind of cut off the feedback loop between the receiver and the sender. > To bridge that one needs additional RTCP messages. >=20 > In the context of a translator one can make this operate at least in = the > following way. =46rom primary perspective it can see the full path to = the > receiver when the splicer is passing its content. And when the splicer > insert the alternative content it could get a report on the path up to > the splicer itself. >=20 > I think we need to discuss what our goals really are here. >=20 > Are they only to provide the receiver with a consistent media stream > despite the splicing? Or does one try to take additional steps to hide > the existence of the splicer from the receivers perspective? >=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 > ---------------------------------------------------------------------- > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From xiajinwei@huawei.com Sun Apr 10 03:13:48 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7140F3A68E1 for ; Sun, 10 Apr 2011 03:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVX79+u18y77 for ; Sun, 10 Apr 2011 03:13:47 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E77EA3A693A for ; Sun, 10 Apr 2011 03:13:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJF006U5LTES3@szxga03-in.huawei.com> for avtext@ietf.org; Sun, 10 Apr 2011 18:15:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJF005CPLTE4J@szxga03-in.huawei.com> for avtext@ietf.org; Sun, 10 Apr 2011 18:15:14 +0800 (CST) Received: from jinwei ([112.3.245.36]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJF00K33LTC9V@szxml12-in.huawei.com>; Sun, 10 Apr 2011 18:15:14 +0800 (CST) Date: Sun, 10 Apr 2011 18:15:02 +0800 From: Jinwei Xia To: Magnus Westerlund , avtext@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 10:13:48 -0000 DQpNYWdudXMsDQogDQpPbiBBcHIgOCwgMjAxMSwgYXQgMTE6MjcgQU0sIE1hZ251cyBXZXN0ZXJs dW5kIHdyb3RlOg0KDQo+IFJvbmkgRXZlbiBza3JldiAyMDExLTA0LTA0IDIxOjU0Og0KPj4gQ29s aW4sDQo+PiBJIHRoaW5rIHRoYXQgdGhlIGNhc2Ugd2l0aCB0aGUgcmVxdWlyZW1lbnQgdG8gdW5k ZXRlY3RhYmlsaXR5IGlzIGEgc2ltcGxlDQo+PiB0cmFuc2xhdG9yLCBpcyB0aGVyZSBzb21ldGhp bmcgc3BlY2lmaWMgaW4gdGhpcyBjYXNlLiANCj4+IA0KPj4gTXkgdmlldyB3YXMgdGhhdCBpZiB3 ZSB0YWtlIHVuZGV0ZWN0YWJpbGl0eSBhd2F5IGFuZCB1c2UgYSB0cmFuc2xhdG9yIG9yIGENCj4+ IG1peGVyIGl0IGJlY29tZXMgYW4gUkZDMzU1MCB0cmFuc2xhdG9yL21peGVyIGFuZCB3ZSBqdXN0 IHBvaW50IHRvIFJGQyAzNTUwLg0KPj4gDQo+PiBJIGFtIHN0aWxsIG5vdCBzdXJlIHdoeSB3ZSBt YWRlIHNwbGljaW5nIHVzaW5nIHRyYW5zbGF0b3IgYW5kIG5vdCBSVFAgbWl4ZXINCj4+IHdoaWNo IHNlZW1lZCB0byBtZSBhIGJldHRlciBmaXQuDQo+PiANCj4gDQo+IFJvbmksDQo+IA0KPiBUaGVy ZSBpcyBub3RoaW5nIHNpbXBsZSBhYm91dCB0aGlzIHNwbGljaW5nIG9wZXJhdGlvbi4gRXNwZWNp YWxseSBpZiB5b3UNCj4gYXR0ZW1wdCB0byBkbyBpdCB1bmRldGVjdGFibGUuIEV2ZW4gYSByZWd1 bGFyIHRyYW5zbGF0b3IgdGhhdCBjYW4gYmUNCj4gZGV0ZWN0ZWQgd2l0aCB0aGUgcHVycG9zZSBv ZiBzcGxpY2luZyBpbiBjb250ZW50IGRvIG5lZWRzIHNvbWUNCj4gc2lnbmlmaWNhbnQgY29uc2lk ZXJhdGlvbi4gSSB0aGluayB0aGUgc2ltcGxlc3QgaXMgdGhlIG1peGVyLiBCdXQgYWxzbw0KPiB0 aGVyZSB0aGUgUkZDIDM1NTAgaXNuJ3Qgbm90IGEgc291cmNlIG9mIGNsYXJpdHkgb24gd2hhdCB5 b3UgbmVlZCB0byBkbw0KPiB0byBtYWludGFpbiBSVFAgY29ycmVjdG5lc3Mgb24gdGhlIGRpZmZl cmVudCBzaWRlcy4NCg0KVW5kZXRlY3RhYmlsaXR5IHJlcXVpcmVtZW50IGlzIHNwZWNpZmljIGZv ciBzb21lIGFkIGluc2VydGlvbiB1c2UgY2FzZXMgKHBvc3NpYmx5IG5vdCBmb3IgYWxsKSwgYnV0 IHNvbWUgb3RoZXIgdXNlIGNhc2VzIHVzaW5nIHNwbGljaW5nIG9wZXJhdGlvbiBkbyBub3QgY292 ZXIgdGhlIHJlcXVpcmVtZW50IHN1Y2ggYXMgdGhvc2UgY2l0ZWQgYnkgRGF2ZS4gVGh1cyBJIHdp bGwgY2hhbmdlIHRoaXMgdW5kZXRlY3RhYmlsaXR5IHJlcXVpcmVtZW50IHRvIGJlIG9wdGlvbmFs LiBJZiB1bmRldGVjdGFiaWxpdHkgaXMgY29uc2lkZXJlZCwgSU1PIGl0IGlzIG5vdCBlYXN5IGVp dGhlciBmb3IgIHRyYW5zbGF0b3Igb3IgbWl4ZXIgdG8gY29uc2lkZXIgdXBwZXIgbGF5ZXIgb3Bl cmF0aW9uLg0KDQpJZiB3ZSB1c2UgbWl4ZXIsIHdoYXQncyB0aGUgdmFsdWUgaW4gQ1NSQyBmaWVs ZCB3aGVuIHRoZSBzdWJzdGl0dXRpdmUgY29udGVudCBjb21lcyBmcm9tIGxvY2FsIG1lZGlhIGZp bGU/DQoNCj4gDQo+IFdoZW4gaXQgY29tZXMgdG8gdGhlIG1peGVyIHZzIHRyYW5zbGF0b3IgY2Fz ZSwgSSB0aGluayBvbmUgcmVhc29uIHdhcw0KPiB0aGlzIG5vbi1kZXRlY3RhYmxlIHJlcXVpcmVt ZW50LiBBbm90aGVyIGFzcGVjdCBvZiBpdCBpcyBoYXMgdG8gZG8gd2l0aA0KPiBiaXQtcmF0ZSBh ZGFwdGF0aW9uIHRvIGhhbmRsZSB2YXJ5aW5nIG5ldHdvcmsgY29uZGl0aW9ucy4gQSBNaXhlciBk b2VzDQo+IGtpbmQgb2YgY3V0IG9mZiB0aGUgZmVlZGJhY2sgbG9vcCBiZXR3ZWVuIHRoZSByZWNl aXZlciBhbmQgdGhlIHNlbmRlci4NCj4gVG8gYnJpZGdlIHRoYXQgb25lIG5lZWRzIGFkZGl0aW9u YWwgUlRDUCBtZXNzYWdlcy4NCg0KTWl4ZXIgaXMgc2ltcGxlciBvbmUgZm9yIG1lZGlhIGFkYXB0 YXRpb24sIHdoaWxlIHRyYW5zbGF0b3IgaXMgYWxzbyBzbWFydCBlbm91Z2ggdG8gY2Fycnkgb3V0 IGFkYXB0YXRpb24gc2luY2UgdHJhbnNsYXRvciBjYW4gaW50ZXJjZXB0IEVDTiBmZWVkYmFja3Mg YW5kIG1vZGlmeSB0aGVtIHdoZW4gY29uZ2VzdGlvbiBvY2N1cnMgZHVyaW5nIHNwbGljZSBwZXJp b2QuIEJ1dCBJIGRvIG5vdCBvcHBvc2UgdGhhdCB1c2luZyBtaXhlciBpcyBhIG9mZi10aGUtc2hl bGYgYXBwcm9hY2guDQoNCj4gDQo+IEluIHRoZSBjb250ZXh0IG9mIGEgdHJhbnNsYXRvciBvbmUg Y2FuIG1ha2UgdGhpcyBvcGVyYXRlIGF0IGxlYXN0IGluIHRoZQ0KPiBmb2xsb3dpbmcgd2F5LiBG cm9tIHByaW1hcnkgcGVyc3BlY3RpdmUgaXQgY2FuIHNlZSB0aGUgZnVsbCBwYXRoIHRvIHRoZQ0K PiByZWNlaXZlciB3aGVuIHRoZSBzcGxpY2VyIGlzIHBhc3NpbmcgaXRzIGNvbnRlbnQuIEFuZCB3 aGVuIHRoZSBzcGxpY2VyDQo+IGluc2VydCB0aGUgYWx0ZXJuYXRpdmUgY29udGVudCBpdCBjb3Vs ZCBnZXQgYSByZXBvcnQgb24gdGhlIHBhdGggdXAgdG8NCj4gdGhlIHNwbGljZXIgaXRzZWxmLg0K DQpSaWdodC4gSXQgaXMgdGhlIGJlbmVmaXQgYnkgdXNpbmcgdHJhbnNsYXRvci4NCg0KPiANCj4g SSB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3Mgd2hhdCBvdXIgZ29hbHMgcmVhbGx5IGFyZSBoZXJl Lg0KPiANCj4gQXJlIHRoZXkgb25seSB0byBwcm92aWRlIHRoZSByZWNlaXZlciB3aXRoIGEgY29u c2lzdGVudCBtZWRpYSBzdHJlYW0NCj4gZGVzcGl0ZSB0aGUgc3BsaWNpbmc/IA0KDQpJdCBpcyBu b3QgbWFuZGF0b3J5IGZvciBhbGwgc3BsaWNpbmcgdXNlIGNhc2VzLCBidXQgYWQgaW5zZXJ0aW9u IG1heSBiZSBhIGltcG9ydGFudCBzcGxpY2luZyBjYXNlIGluIElQVFYgY29tbWVyY2lhbCBkZXBs b3ltZW50Lg0KDQo+T3IgZG9lcyBvbmUgdHJ5IHRvIHRha2UgYWRkaXRpb25hbCBzdGVwcyB0byBo aWRlDQo+IHRoZSBleGlzdGVuY2Ugb2YgdGhlIHNwbGljZXIgZnJvbSB0aGUgcmVjZWl2ZXJzIHBl cnNwZWN0aXZlPw0KDQpJTUhPIGl0IGlzIHVubmVjZXNzYXJ5IHRvIGhpZGUgaW50ZXJtZWRpYXRl IG5vZGVzIGZyb20gcmVjZWl2ZXIuDQoNCkkgcmVzcGVjdCB0aGUgcHJlZmVyZW5jZSBvZiBtYWpv cml0eSBhbmQgbW9yZSBvcGluaW9ucyBhcmUgdmVyeSBhcHByZWNpYXRlZCENCg0KDQpUaGFuayB5 b3UuDQoNCg0KSmlud2VpDQoNCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29u IFJlc2VhcmNoIEVBQi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBG5HL2Z2F0YW4gNiAgICAgICAgICAg ICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2Vk ZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g YXZ0ZXh0IG1haWxpbmcgbGlzdA0KPiBhdnRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg0K From keith.drage@alcatel-lucent.com Mon Apr 11 04:22:27 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C6C3A6B0A for ; Mon, 11 Apr 2011 04:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.976 X-Spam-Level: X-Spam-Status: No, score=-106.976 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU+FdUtXQQcw for ; Mon, 11 Apr 2011 04:22:26 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 529E33A6B05 for ; Mon, 11 Apr 2011 04:22:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3BBKZX5014087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 Apr 2011 13:22:18 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 11 Apr 2011 13:22:07 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Mon, 11 Apr 2011 13:22:05 +0200 Thread-Topic: Splicing: Confirmation of decisions at IETF#80 Thread-Index: AcvtYWJNNJPDTxTUQZyk6+srEdsGcAK2ODnA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:22:27 -0000 (As WG chair) I sent out this request a couple of weeks ago. I have seen no objections al= though the deadline is well past. There has been some significant comment on what the contents might reflect = and I assume the author will take this discussion into account in providing= a revision of his author draft. I do not see this discussion as changing t= he possible milestone text. The next step is that Magnus and I will agree the milestone text and get th= at added, and then we will make a call to adopt text. With that in mind, if you have alternative proposals for text, please submi= t them now, either as as i-d or direct to the list. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 28 March 2011 17:01 > To: 'avtext@ietf.org' > Subject: Splicing: Confirmation of decisions at IETF#80 >=20 > (As WG chair) >=20 > There was significant interest in the face-to-face meeting to creating a > milestone in the WG. The essence of the milestone will be to address the > use case of splicing using existing tools provided in RTP. It will > therefore be an informational document. >=20 > Unless the chairs hear contrary positions on the mailing list, the chairs > will discussing such a milestone with the AD and adding it to our list of > milestones in AVTEXT. >=20 > Please respond by the end of this week (Friday). >=20 > This does not adopt the current text as a working group item. The author > will provide another revision of this document based on comments made, an= d > other comments that people may wish to contribute now, and we will make a > call to adopt text at that point. Please take this as an invitation to > contribution other material either via the mailing list or via separate > internet-drafts. >=20 > Regards >=20 > Keith From magnus.westerlund@ericsson.com Mon Apr 11 04:44:18 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F07F3A6B08 for ; Mon, 11 Apr 2011 04:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZBu4O+BglHX for ; Mon, 11 Apr 2011 04:44:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2C10D3A6B07 for ; Mon, 11 Apr 2011 04:44:16 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-62-4da2e9909f48 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.15.09202.099E2AD4; Mon, 11 Apr 2011 13:44:16 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Apr 2011 13:44:16 +0200 Message-ID: <4DA2E990.60109@ericsson.com> Date: Mon, 11 Apr 2011 13:44:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jinwei Xia References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:44:18 -0000 Hi, Jinwei Xia skrev 2011-04-10 12:15: > > Magnus, > > On Apr 8, 2011, at 11:27 AM, Magnus Westerlund wrote: > >> Roni Even skrev 2011-04-04 21:54: >>> Colin, I think that the case with the requirement to >>> undetectability is a simple translator, is there something >>> specific in this case. >>> >>> My view was that if we take undetectability away and use a >>> translator or a mixer it becomes an RFC3550 translator/mixer and >>> we just point to RFC 3550. >>> >>> I am still not sure why we made splicing using translator and not >>> RTP mixer which seemed to me a better fit. >>> >> >> Roni, >> >> There is nothing simple about this splicing operation. Especially >> if you attempt to do it undetectable. Even a regular translator >> that can be detected with the purpose of splicing in content do >> needs some significant consideration. I think the simplest is the >> mixer. But also there the RFC 3550 isn't not a source of clarity on >> what you need to do to maintain RTP correctness on the different >> sides. > > Undetectability requirement is specific for some ad insertion use > cases (possibly not for all), but some other use cases using splicing > operation do not cover the requirement such as those cited by Dave. > Thus I will change this undetectability requirement to be optional. > If undetectability is considered, IMO it is not easy either for > translator or mixer to consider upper layer operation. Well, it will be detectable, unless one does transcoding in the splicer, or force the two stream to be encoded by the same encoder. If any time of media parameter are different between the two stream a downstream client will be able to detect the switch. > > If we use mixer, what's the value in CSRC field when the substitutive > content comes from local media file? Well, that could be assigned. I think we should get back the translator vs mixer when we have arrived what the reasonable requirements really are. It might in fact be that translator is the correct model and that the other aspects overweights some other. > >> >> When it comes to the mixer vs translator case, I think one reason >> was this non-detectable requirement. Another aspect of it is has to >> do with bit-rate adaptation to handle varying network conditions. A >> Mixer does kind of cut off the feedback loop between the receiver >> and the sender. To bridge that one needs additional RTCP messages. > > Mixer is simpler one for media adaptation, while translator is also > smart enough to carry out adaptation since translator can intercept > ECN feedbacks and modify them when congestion occurs during splice > period. But I do not oppose that using mixer is a off-the-shelf > approach. I wouldn't say off the shelf approach. Certain aspects are clearly more straight forward. Other still needs considerations. > >> >> In the context of a translator one can make this operate at least >> in the following way. From primary perspective it can see the full >> path to the receiver when the splicer is passing its content. And >> when the splicer insert the alternative content it could get a >> report on the path up to the splicer itself. > > Right. It is the benefit by using translator. > >> >> I think we need to discuss what our goals really are here. >> >> Are they only to provide the receiver with a consistent media >> stream despite the splicing? > > It is not mandatory for all splicing use cases, but ad insertion may > be a important splicing case in IPTV commercial deployment. > >> Or does one try to take additional steps to hide the existence of >> the splicer from the receivers perspective? > > IMHO it is unnecessary to hide intermediate nodes from receiver. Good, that makes things simpler. > > I respect the preference of majority and more opinions are very > appreciated! Well, I want the opinion of a informed majority. Which do requires that we work through the motivations. 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 Mon Apr 11 04:57:08 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FB13A69FF for ; Mon, 11 Apr 2011 04:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqPsgxMKhuK6 for ; Mon, 11 Apr 2011 04:57:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 39D873A6A09 for ; Mon, 11 Apr 2011 04:57:07 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-cb-4da2ec92ccf4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.47.09202.29CE2AD4; Mon, 11 Apr 2011 13:57:07 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Apr 2011 13:57:06 +0200 Message-ID: <4DA2EC92.5050501@ericsson.com> Date: Mon, 11 Apr 2011 13:57:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jinwei Xia References: <4D904E7E.6090504@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] comments on draft-xia-avtext-splicing-for-rtp-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:57:08 -0000 Hi, Sorry for the delay in answering. Please see discussion where there still open issues/discussion. Jinwei Xia skrev 2011-03-28 18:32: > ----- Original Message ----- From: "Magnus Westerlund" > To: ; "Jinwei Xia" > Sent: Monday, March 28, 2011 5:01 PM Subject: > comments on draft-xia-avtext-splicing-for-rtp-00 > >> >> 2. I am also missing a discussion on the RTP timestamp handling >> issues. That clearly also needs to be covered to ensure that the >> receiver gets a consistent stream. >> > > Very good question, the timestamp of main stream RTP packet is keep > intact, the timestamp of substitutive RTP packet is calculated by > Translator based on how many substitutive packets are outputted to > user during specific time. I will add related description in next > version. Well, number of packets doesn't matter. It is the relative timestamp difference that needs to be handled. Plus that correct steps between last video frame and the first spliced needs to have a reasonable and consistent step. This is easier for more continuous media like audio where the next timestamp value can be used. > >> 3. I also see a clear issue for a translator to deal with the RTCP >> translations towards the main source. My understanding is that the >> splicer will need to translate any RTCP Report blocks coming from >> down stream to the splicer, even when the substitute content is >> being forwarded by the splicer. I can see how this can be made to >> work if there are no media adaptation happening. But if the media >> streams are being adapted then this becomes problematic. This as >> any feedback relates to the stream actually being sent. So the >> translated RTCP needs to report to the main stream how the main >> stream would fair down stream of the splicer, without actually >> having sent it. I don't see how this can be done in a reasonable >> and robust way. >> >> For example if the substitute stream is higher bandwidth than the >> main stream and that stream is being reported as causing >> congestion. Then what does one report to the main stream sender? >> Because one can't know if that stream would cause congestion. Can >> someone please explain how to support this case. > > When detecting the ECN notification message during splicing period, > translator intercepts them, discards the feedback messages or remove > XR parts in RR because it knows the congestion is caused by > substitutive content rather than main content. how does the > translator execute media adaptation is inner implementation. > > Discarding ECN feedback message indeed is a additional requirement > for translator. Can translator execute above approach? Is the > approach reasonable and robust? Per discussion in the other thread I think forwarding feedback to the one that sourced the data is the right decision here. And the other source if over RTP gets the feedback for the path to the splicer. > >> REQ-2: The RTP packets whose payloads are replaced by substitutive >> content are required to keep their RTP header information to be >> consistent with those of main RTP packets whose payloads are >> unaltered. >> >> I think "Keep" is the wrong word here. I think resulting in a >> consistent stream. > > how about: " The current RTP stream received by user may contain > main content or substitutive content, but user can not find which > kind of content the RTP stream convey from current RTP header > information." I don't think that is a working requirement either. Because if you are forced to switch payload type you break the above requirement. And that has less to do with the solution, and more to do with what additional requirements you can put on the encoding of the content. > >> >> REQ-2: "The value of SSRC field in RTP header MUST be same as the >> value of corresponding field in main content RTP header, while the >> value of payload type field SHOULD be same as the value of >> corresponding field in main content RTP header. Note that in some >> cases, it may be necessary to transcode the substitutive content to >> ensure the payload type is the same, and that this may be >> prohibitively expensive, so it might be acceptable to leave the >> payload untranscoded." >> >> First, I think this isn't requirements, they are how one should >> implement it. I also think, one could clarify that if one has >> signalled the different RTP payload types then one can actually >> switch between them. IF that is supported by client depends on the >> usage. >> > > OK, so how about to delete the content "Note that~~~~"? the deleted > content will be remove to section 5 with the description about > reaction of user on different codec. Can we perhaps change the requirement from the RTP details to what the real intention is here? Is the intention that the switch over should be undetectable on the encoding, or that things are consistent. > >> >> REQ-4: Splicer MUST be backward compatible with basic >> characteristics of [RFC3550], e.g., SSRC identifier collision >> resolution and loop detection. >> >> Shouldn't this also include certain RTP extensions also? >> > > how about: "Splicer MUST be backward compatible with RTP/RTCP > protocols with its associated profiles, and extensions to those > protocols" Yes, and I in addition I think there is a point of trying to create a list of what extensions that we see being used together with a splicer so that we needs to discuss them? > >> Section 6. "Even if no new substitutive content will be inserted, >> the Translator still needs to modify the main RTP packets, and to >> recalculate the UDP/IP checksum until the main RTP session ends. >> If Translator serves multiple main RTP streams simultaneously, this >> may lead to large overhead on the Translator." >> >> I don't think this translation is any form of extreme case of >> burden. Yes, you will need to update both some RTP header fields. >> Well, you anyway would need to update the address fields and that >> is part of the pseudo header anyway. So you can't do relaying >> without paying this cost. And there are hardware off-loading for >> UDP checksums. > > OK, we just need to mention implentation consideration that > translator needs to process the lower layers. > > how about: "When Translator is used to handle RTP splicing, RTP > receiver does not need any RTP/RTCP extension for splicing. As a > trade-off, Translator must process RTP and lower layers compared to > just forwarding the main RTP stream, since Translator must coordinate > the switch between main content and substitutive content, and > generate its own RTCP reports. Even if no new substitutive content > will be inserted, the Translator still needs to modify the main RTP > packets, and to recalculate the UDP/IP checksum until the main RTP > session ends." Yes, but I think this will become obvious as you expand into more detail on the handling of each field in RTP and RTCP. 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 Mon Apr 11 04:59:04 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2413A6A0C for ; Mon, 11 Apr 2011 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZW3yqB2TikP for ; Mon, 11 Apr 2011 04:59:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8CD1F3A6A09 for ; Mon, 11 Apr 2011 04:59:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-5c-4da2ed063ba2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E3.F7.11171.60DE2AD4; Mon, 11 Apr 2011 13:59:03 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Apr 2011 13:59:03 +0200 Message-ID: <4DA2ED06.8040009@ericsson.com> Date: Mon, 11 Apr 2011 13:59:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: avtext@ietf.org References: <04CAD96D4C5A3D48B1919248A8FE0D540EB56668@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB569A1@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EB56A45@xmb-sjc-215.amer.cisco.com> <31512160-BC84-4406-8D1A-21A8B547DC4E@cisco.com> In-Reply-To: <31512160-BC84-4406-8D1A-21A8B547DC4E@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:59:04 -0000 Ali C. Begen (abegen) skrev 2011-04-07 12:57: > It turns out that iana is enough smart to make that change > automatically. They did it before in rfc 5725. > > I think the text right now is quite adequate for it. One can formulate this so that it is clear that IANA is to update the registration to now point to this document and transfer the change control to IETF. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Mon Apr 11 08:15:02 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30F43A69AD; Mon, 11 Apr 2011 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc7CSYbJ1P8f; Mon, 11 Apr 2011 08:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFA83A6889; Mon, 11 Apr 2011 08:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411151502.18471.63915.idtracker@localhost> Date: Mon, 11 Apr 2011 08:15:02 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action:draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Author(s) : A. Begen, E. Friedrich Filename : draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt Pages : 21 Date : 2011-04-11 In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can (or be compelled to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-11081352.I-D@ietf.org> --NextPart-- From keith.drage@alcatel-lucent.com Mon Apr 11 10:57:53 2011 Return-Path: X-Original-To: avtext@core3.amsl.com Delivered-To: avtext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440483A69AC for ; Mon, 11 Apr 2011 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.973 X-Spam-Level: X-Spam-Status: No, score=-105.973 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02EEjR+9Qp1a for ; Mon, 11 Apr 2011 10:57:51 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 85E8F3A69A0 for ; Mon, 11 Apr 2011 10:57:51 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3BHvopS012401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 Apr 2011 19:57:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 11 Apr 2011 19:57:50 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Mon, 11 Apr 2011 19:57:49 +0200 Thread-Topic: publication request of draft-ietf-avtext-multicast-acq-rtcp-xr Thread-Index: Acv4cfhPPHDtcYfdSCyxJUig2pY6hQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [avtext] publication request of draft-ietf-avtext-multicast-acq-rtcp-xr X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:57:53 -0000 (As WG cochair) I have just requested publication of draft-ietf-avtext-multicast-acq-rtcp-x= r. The process now is that the AD looks at it and when he is happy, he puts it= through IETF last call. Note that in the changes from -01 to -02 there hav= e been some minor technical changes. People may want to look at those chang= es in preparing comments for IETF last call. The shepherd writeup follows the end of this message. Regards Keith ----------------------------------------------------------------- Shepherd writeup for draft-ietf-avtext-multicast-acq-rtcp-xr-03=20 "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP)=20 Extended Reports (XRs)" as proposed standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 The document shepherd for this document is Keith Drage. The document shepherd has reviewed the document and believes it is ready fo= r=20 forwarding to the IESG for publication. Document history: - draft-begen-avt-rapid-sync-rtcp-xr-00 was submitted 3rd March=20 2009 and expired 4th September 2009; - draft-begen-avt-rapid-sync-rtcp-xr-01 was submitted 13th May 2009=20 and expired 14th November 2009; - draft-begen-avt-rapid-sync-rtcp-xr-02 was submitted 10th August=20 2009 and expired 11th February 2010; - draft-begen-avt-rapid-sync-rtcp-xr-03 was submitted 22nd October=20 2009 and expired 25th April 2010; - draft-ietf-avt-multicast-acq-rtcp-xr-00 was submitted 16th=20 February 2010 and expired 20th August 2010; - draft-ietf-avt-multicast-acq-rtcp-xr-01 was submitted 20th May=20 2010 and expired 21st November 2010; - with the creation of the AVTEXT working group from the ashes of AVT,=20 the document moved to AVTEXT, and draft-ietf-avtext-multicast-acq-rtcp-xr- 00 was submitted 5th March 2011 and expires 6th September 2011; - draft-ietf-avtext-multicast-acq-rtcp-xr-01 was submitted 30th=20 April 2011 and expires 1st October 2011; - draft-ietf-avtext-multicast-acq-rtcp-xr-02 was submitted 6th=20 April 2011 and expires 8th October 2011; - draft-ietf-avtext-multicast-acq-rtcp-xr-03 was submitted 11th=20 April 2011 and expires 13th October 2011; Call for adoption of baseline as WG item was made September 8th 2009 and=20 acceptance declared 15th February 2010. Working group last call was initiated on -01 version on 15th June 2010=20 for completion 29th June 2010 as proposed standard. No reviews were=20 received. The document was reviewed without comment by Roni Even. Colin Perkins reviewed, and stated "don't like the encoding, or the=20 ability to use private extensions, but the metrics look okay". Prior to working group last call, comments had been received from=20 Cullen Jennings, Tom van Caenegem. The document has since been reviewed=20 by Magnus Westerlund, in addition to the document shepherd. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has been adequately reviewed (see 1a above).=20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 There are no such concerns from the document shepherd. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 There are no concerns from the document shepherd from this perspective with= the=20 document. No IPR disclosures have been made against this document. (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 >From a reviewing perspective, the interest in this specific document has be= en=20 relatively small, but it forms an essential part of draft-ietf-avt-rapid- acquisition-for-rtp which has been well and substantially reviewed. It=20 is assumed that the interested parties in that document have also reviewed = this=20 document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No appeals or areas of conflict or discontent have been identified. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist= =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 Version 2.12.09 of ID nits identifies no issues. No other formal reviews outside of the AVT working group are perceived as=20 necessary for this document. (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The document does split normative and informative references. All the norma= tive=20 references have been reviewed and are correctly allocated as normative=20 references. None of these normative references constitute a down reference. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations have been reviewed, the registries are correctly=20 identified. The document creates two new registries for which the policy ha= s=20 been appropriately defined. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 One change to an SDP attribute has been defined in ABNF. This is an extensi= on=20 to the ABNF in RFC 3611. The ABNF has been validated by visual inspection. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction.=20 Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough?=20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP=20 receivers usually cannot start consuming the multicast data right after=20 they join the session. Thus, they often experience a random=20 acquisition delay. An RTP receiver can use one ore more different=20 approaches to achieve rapid acquisition. Yet, due to various factors,=20 performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can (or be compelled to) do=20 a simple multicast join. For quality reporting, monitoring and=20 diagnostics purposes, it is important to collect detailed information=20 from the RTP receivers about their acquisition and presentation=20 experiences. This document addresses this issue by defining a new=20 report block type, called Multicast Acquisition (MA) Report Block,=20 within the framework of RTP Control Protocol (RTCP) Extended Reports=20 (XR) (RFC 3611). This document also defines the necessary signalling=20 of the new MA report block type in the Session Description Protocol=20 (SDP). The document achieved consensus in the AVT working group. From gonzalo.camarillo@ericsson.com Tue Apr 12 05:25:03 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DDF6CE07BB for ; Tue, 12 Apr 2011 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk-GMcdNqOJK for ; Tue, 12 Apr 2011 05:25:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 46B0FE0737 for ; Tue, 12 Apr 2011 05:25:00 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-2c-4da4449bcdb8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2E.40.09202.B9444AD4; Tue, 12 Apr 2011 14:24:59 +0200 (CEST) Received: from [131.160.126.135] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 12 Apr 2011 14:24:59 +0200 Message-ID: <4DA4449A.8040100@ericsson.com> Date: Tue, 12 Apr 2011 15:24:58 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] publication request of draft-ietf-avtext-multicast-acq-rtcp-xr X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:25:04 -0000 Hi, > The process now is that the AD looks at it and when he is happy, he puts it through IETF last call. I have requested the authors to add a recommendation for an integrity protection mechanism in the Security Considerations Section. As soon as they do that, I will request its IETF LC. Cheers, Gonzalo From Internet-Drafts@ietf.org Tue Apr 12 06:30:03 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC886E0697; Tue, 12 Apr 2011 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmceuUWsGqf6; Tue, 12 Apr 2011 06:30:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43A7EE078C; Tue, 12 Apr 2011 06:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110412133003.11639.96045.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 06:30:03 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action:draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Author(s) : A. Begen, E. Friedrich Filename : draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt Pages : 21 Date : 2011-04-12 In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-12061610.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Tue Apr 12 08:00:34 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 58B67E07FC; Tue, 12 Apr 2011 08:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j43pSdTR8JVc; Tue, 12 Apr 2011 08:00:33 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1AADE079E; Tue, 12 Apr 2011 08:00:33 -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: 3.16 Message-ID: <20110412150033.4130.97121.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 08:00:33 -0700 Cc: avtext@ietf.org Subject: [avtext] Last Call: (Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)) to Proposed Standard X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:00:34 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ No IPR declarations have been submitted directly on this I-D. From csp@csperkins.org Tue Apr 12 22:00:19 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82722E0675 for ; Tue, 12 Apr 2011 22:00:19 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1++9dotVNHOs for ; Tue, 12 Apr 2011 22:00:18 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfc.amsl.com (Postfix) with ESMTP id 5F590E067B for ; Tue, 12 Apr 2011 22:00:18 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Q9NTE-00008R-jq; Mon, 11 Apr 2011 20:12:24 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> Date: Mon, 11 Apr 2011 21:12:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51BAA831-B4C1-4D60-A4FB-B8A8C85CDCEE@csperkins.org> References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> To: David R Oran X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 05:00:19 -0000 On 8 Apr 2011, at 16:43, David R Oran wrote: > I tend to agree with Magnus' assessment. >=20 > There seems also to be an additional (only implicitly stated) = requirement that people need to internalize (at least I think there is = after a number of discussions with the proponents). >=20 > That is the ability of the translator to have minimal (or zero) = overhead when content is not being actively spliced. I believe the = system model the proponents have in their heads is one in which a system = sitting in the middle of the network somewhere can have many RTP = sessions flowing "through" , or "around" it, and only incur translator = overhead during an actual splice operation, and possibly for a short = period surrounding the splice. In other words, I'm presuming there's a = scalability requirement of the form: "the overhead must scale with the = number of active splices, not with the number of RTP sessions flowing = through the intermediary". I'm not sure there's any solution for the combination of non-detectable = splicing and zero overhead when not actively splicing (at least, not = without revising RTP). All the solutions I envisage have a per-stream = overhead when not splicing in order to achieve non-detectable behaviour: = they either need to continually rewrite RTP sequence numbers and RTCP, = or act as a mixer and add a CSRC to the stream, and process RTCP = packets. As such, they all scale with the number of RTP streams flowing = through the intermediary.=20 > I suspect this has substantial impact, perhaps not as great as the = non-detectability requirement, but worth pondering for sure. Agreed. It seems to me that the draft authors need to decide whether = non-detectable behaviour or zero overhead when not splicing is their = goal, as it doesn't look like both are possible. --=20 Colin Perkins http://csperkins.org/ From Even.roni@huawei.com Tue Apr 12 22:35:51 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 743A6E065A for ; Tue, 12 Apr 2011 22:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wioM6fcWisB for ; Tue, 12 Apr 2011 22:35:50 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 7CE49E06C5 for ; Tue, 12 Apr 2011 22:35:50 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK00ARMSV5C4@szxga05-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 13:35:29 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK009I1SV48S@szxga05-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 13:35:29 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-0-251.red.bezeqint.net [79.178.0.251]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJK0010VSUWZ8@szxml11-in.huawei.com>; Wed, 13 Apr 2011 13:35:28 +0800 (CST) Date: Wed, 13 Apr 2011 08:34:42 +0300 From: Roni Even In-reply-to: <51BAA831-B4C1-4D60-A4FB-B8A8C85CDCEE@csperkins.org> To: 'Colin Perkins' , 'David R Oran' Message-id: <01bf01cbf99c$82f9bb50$88ed31f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acv5l/GpC3/lVoWnQFytpFNz0QnjgAAA2Dmg References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> <51BAA831-B4C1-4D60-A4FB-B8A8C85CDCEE@csperkins.org> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 05:35:51 -0000 Colin, I thought about the mixer based solution without listing the CSRCs. According to RFC3550 "For some applications, it MAY be acceptable for a mixer not to identify sources in the CSRC list. However, this introduces the danger that loops involving those sources could not be detected." RTCP packets with RR from the receivers will need to be processed by the mixers if the receivers cannot detect the inserted stream. Will probably require the splicer to know which sequence numbers were the inserted stream Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Colin Perkins > Sent: Monday, April 11, 2011 11:12 PM > To: David R Oran > Cc: avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > > On 8 Apr 2011, at 16:43, David R Oran wrote: > > I tend to agree with Magnus' assessment. > > > > There seems also to be an additional (only implicitly stated) > requirement that people need to internalize (at least I think there is > after a number of discussions with the proponents). > > > > That is the ability of the translator to have minimal (or zero) > overhead when content is not being actively spliced. I believe the > system model the proponents have in their heads is one in which a > system sitting in the middle of the network somewhere can have many RTP > sessions flowing "through" , or "around" it, and only incur translator > overhead during an actual splice operation, and possibly for a short > period surrounding the splice. In other words, I'm presuming there's a > scalability requirement of the form: "the overhead must scale with the > number of active splices, not with the number of RTP sessions flowing > through the intermediary". > > I'm not sure there's any solution for the combination of non-detectable > splicing and zero overhead when not actively splicing (at least, not > without revising RTP). All the solutions I envisage have a per-stream > overhead when not splicing in order to achieve non-detectable > behaviour: they either need to continually rewrite RTP sequence numbers > and RTCP, or act as a mixer and add a CSRC to the stream, and process > RTCP packets. As such, they all scale with the number of RTP streams > flowing through the intermediary. > > > I suspect this has substantial impact, perhaps not as great as the > non-detectability requirement, but worth pondering for sure. > > > Agreed. It seems to me that the draft authors need to decide whether > non-detectable behaviour or zero overhead when not splicing is their > goal, as it doesn't look like both are possible. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From xiajinwei@huawei.com Wed Apr 13 01:13:38 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 699D9E06F7 for ; Wed, 13 Apr 2011 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9iPj6mxib-q for ; Wed, 13 Apr 2011 01:13:37 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 0651FE06A5 for ; Wed, 13 Apr 2011 01:13:37 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL0095S063ET@szxga05-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 16:13:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL0075C062YE@szxga05-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 16:13:15 +0800 (CST) Received: from jinwei ([183.208.25.0]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJL00C9I062RH@szxml12-in.huawei.com>; Wed, 13 Apr 2011 16:13:14 +0800 (CST) Date: Wed, 13 Apr 2011 16:12:57 +0800 From: Jinwei Xia To: Magnus Westerlund Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:13:38 -0000 TWFnbnVzLA0KDQo8c25hcD4NCg0KPj4gDQo+PiBVbmRldGVjdGFiaWxpdHkgcmVxdWlyZW1lbnQg aXMgc3BlY2lmaWMgZm9yIHNvbWUgYWQgaW5zZXJ0aW9uIHVzZQ0KPj4gY2FzZXMgKHBvc3NpYmx5 IG5vdCBmb3IgYWxsKSwgYnV0IHNvbWUgb3RoZXIgdXNlIGNhc2VzIHVzaW5nIHNwbGljaW5nDQo+ PiBvcGVyYXRpb24gZG8gbm90IGNvdmVyIHRoZSByZXF1aXJlbWVudCBzdWNoIGFzIHRob3NlIGNp dGVkIGJ5IERhdmUuDQo+PiBUaHVzIEkgd2lsbCBjaGFuZ2UgdGhpcyB1bmRldGVjdGFiaWxpdHkg cmVxdWlyZW1lbnQgdG8gYmUgb3B0aW9uYWwuDQo+PiBJZiB1bmRldGVjdGFiaWxpdHkgaXMgY29u c2lkZXJlZCwgSU1PIGl0IGlzIG5vdCBlYXN5IGVpdGhlciBmb3INCj4+IHRyYW5zbGF0b3Igb3Ig bWl4ZXIgdG8gY29uc2lkZXIgdXBwZXIgbGF5ZXIgb3BlcmF0aW9uLg0KPiANCj4gV2VsbCwgaXQg d2lsbCBiZSBkZXRlY3RhYmxlLCB1bmxlc3Mgb25lIGRvZXMgdHJhbnNjb2RpbmcgaW4gdGhlIHNw bGljZXIsDQo+IG9yIGZvcmNlIHRoZSB0d28gc3RyZWFtIHRvIGJlIGVuY29kZWQgYnkgdGhlIHNh bWUgZW5jb2Rlci4gSWYgYW55IHRpbWUNCj4gb2YgbWVkaWEgcGFyYW1ldGVyIGFyZSBkaWZmZXJl bnQgYmV0d2VlbiB0aGUgdHdvIHN0cmVhbSBhIGRvd25zdHJlYW0NCj4gY2xpZW50IHdpbGwgYmUg YWJsZSB0byBkZXRlY3QgdGhlIHN3aXRjaC4NCg0KUmlnaHQsIGluIGFib3ZlIGFuYWx5c2lzLCB0 cmFuc2xhdG9yIGFuZCBtaXhlciBib3RoIGNhbiByZWFsaXplIHNwbGljaW5nIGJ5IGNoYW5naW5n IGRpZmZlcmVudCBSVFAgcGFyYW1ldGVycy4NCg0KPiANCj4+IA0KPj4gSWYgd2UgdXNlIG1peGVy LCB3aGF0J3MgdGhlIHZhbHVlIGluIENTUkMgZmllbGQgd2hlbiB0aGUgc3Vic3RpdHV0aXZlDQo+ PiBjb250ZW50IGNvbWVzIGZyb20gbG9jYWwgbWVkaWEgZmlsZT8NCj4gDQo+IFdlbGwsIHRoYXQg Y291bGQgYmUgYXNzaWduZWQuIEkgdGhpbmsgd2Ugc2hvdWxkIGdldCBiYWNrIHRoZSB0cmFuc2xh dG9yDQo+IHZzIG1peGVyIHdoZW4gd2UgaGF2ZSBhcnJpdmVkIHdoYXQgdGhlIHJlYXNvbmFibGUg cmVxdWlyZW1lbnRzIHJlYWxseQ0KPiBhcmUuIEl0IG1pZ2h0IGluIGZhY3QgYmUgdGhhdCB0cmFu c2xhdG9yIGlzIHRoZSBjb3JyZWN0IG1vZGVsIGFuZCB0aGF0DQo+IHRoZSBvdGhlciBhc3BlY3Rz IG92ZXJ3ZWlnaHRzIHNvbWUgb3RoZXIuDQo+IA0KPj4gDQo+Pj4gDQo+Pj4gV2hlbiBpdCBjb21l cyB0byB0aGUgbWl4ZXIgdnMgdHJhbnNsYXRvciBjYXNlLCBJIHRoaW5rIG9uZSByZWFzb24NCj4+ PiB3YXMgdGhpcyBub24tZGV0ZWN0YWJsZSByZXF1aXJlbWVudC4gQW5vdGhlciBhc3BlY3Qgb2Yg aXQgaXMgaGFzIHRvDQo+Pj4gZG8gd2l0aCBiaXQtcmF0ZSBhZGFwdGF0aW9uIHRvIGhhbmRsZSB2 YXJ5aW5nIG5ldHdvcmsgY29uZGl0aW9ucy4gQQ0KPj4+IE1peGVyIGRvZXMga2luZCBvZiBjdXQg b2ZmIHRoZSBmZWVkYmFjayBsb29wIGJldHdlZW4gdGhlIHJlY2VpdmVyDQo+Pj4gYW5kIHRoZSBz ZW5kZXIuIFRvIGJyaWRnZSB0aGF0IG9uZSBuZWVkcyBhZGRpdGlvbmFsIFJUQ1AgbWVzc2FnZXMu DQo+PiANCj4+IE1peGVyIGlzIHNpbXBsZXIgb25lIGZvciBtZWRpYSBhZGFwdGF0aW9uLCB3aGls ZSB0cmFuc2xhdG9yIGlzIGFsc28NCj4+IHNtYXJ0IGVub3VnaCB0byBjYXJyeSBvdXQgYWRhcHRh dGlvbiBzaW5jZSB0cmFuc2xhdG9yIGNhbiBpbnRlcmNlcHQNCj4+IEVDTiBmZWVkYmFja3MgYW5k IG1vZGlmeSB0aGVtIHdoZW4gY29uZ2VzdGlvbiBvY2N1cnMgZHVyaW5nIHNwbGljZQ0KPj4gcGVy aW9kLiBCdXQgSSBkbyBub3Qgb3Bwb3NlIHRoYXQgdXNpbmcgbWl4ZXIgaXMgYSBvZmYtdGhlLXNo ZWxmDQo+PiBhcHByb2FjaC4NCj4gDQo+IEkgd291bGRuJ3Qgc2F5IG9mZiB0aGUgc2hlbGYgYXBw cm9hY2guIENlcnRhaW4gYXNwZWN0cyBhcmUgY2xlYXJseSBtb3JlDQo+IHN0cmFpZ2h0IGZvcndh cmQuIE90aGVyIHN0aWxsIG5lZWRzIGNvbnNpZGVyYXRpb25zLg0KPiANCj4+IA0KPj4+IA0KPj4+ IEluIHRoZSBjb250ZXh0IG9mIGEgdHJhbnNsYXRvciBvbmUgY2FuIG1ha2UgdGhpcyBvcGVyYXRl IGF0IGxlYXN0DQo+Pj4gaW4gdGhlIGZvbGxvd2luZyB3YXkuIEZyb20gcHJpbWFyeSBwZXJzcGVj dGl2ZSBpdCBjYW4gc2VlIHRoZSBmdWxsDQo+Pj4gcGF0aCB0byB0aGUgcmVjZWl2ZXIgd2hlbiB0 aGUgc3BsaWNlciBpcyBwYXNzaW5nIGl0cyBjb250ZW50LiBBbmQNCj4+PiB3aGVuIHRoZSBzcGxp Y2VyIGluc2VydCB0aGUgYWx0ZXJuYXRpdmUgY29udGVudCBpdCBjb3VsZCBnZXQgYQ0KPj4+IHJl cG9ydCBvbiB0aGUgcGF0aCB1cCB0byB0aGUgc3BsaWNlciBpdHNlbGYuDQo+PiANCj4+IFJpZ2h0 LiBJdCBpcyB0aGUgYmVuZWZpdCBieSB1c2luZyB0cmFuc2xhdG9yLg0KPj4gDQo+Pj4gDQo+Pj4g SSB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3Mgd2hhdCBvdXIgZ29hbHMgcmVhbGx5IGFyZSBoZXJl Lg0KPj4+IA0KPj4+IEFyZSB0aGV5IG9ubHkgdG8gcHJvdmlkZSB0aGUgcmVjZWl2ZXIgd2l0aCBh IGNvbnNpc3RlbnQgbWVkaWENCj4+PiBzdHJlYW0gZGVzcGl0ZSB0aGUgc3BsaWNpbmc/DQo+PiAN Cj4+IEl0IGlzIG5vdCBtYW5kYXRvcnkgZm9yIGFsbCBzcGxpY2luZyB1c2UgY2FzZXMsIGJ1dCBh ZCBpbnNlcnRpb24gbWF5DQo+PiBiZSBhIGltcG9ydGFudCBzcGxpY2luZyBjYXNlIGluIElQVFYg Y29tbWVyY2lhbCBkZXBsb3ltZW50Lg0KPj4gDQo+Pj4gT3IgZG9lcyBvbmUgdHJ5IHRvIHRha2Ug YWRkaXRpb25hbCBzdGVwcyB0byBoaWRlIHRoZSBleGlzdGVuY2Ugb2YNCj4+PiB0aGUgc3BsaWNl ciBmcm9tIHRoZSByZWNlaXZlcnMgcGVyc3BlY3RpdmU/DQo+PiANCj4+IElNSE8gaXQgaXMgdW5u ZWNlc3NhcnkgdG8gaGlkZSBpbnRlcm1lZGlhdGUgbm9kZXMgZnJvbSByZWNlaXZlci4NCj4gDQo+ IEdvb2QsIHRoYXQgbWFrZXMgdGhpbmdzIHNpbXBsZXIuDQoNCkNhbiB3ZSBjb25jbHVkZSB0aGF0 OiAgICAgDQoNClRyYW5zbGF0b3I6IA0KICAgIHByb3M6ICBhbGxvdyBwcmltYXJ5IHNvdXJjZSBr bm93IHRoZSBzaXR1YXRpb24gb2YgZnVsbCBwYXRoLg0KICAgIGNvbnM6IG1vcmUgY29uc2lkZXJ0 YWlvbiBmb3IgbWVkaWEgYWRhcHRhdGlvbjsgY2hhbmdpbmcgUlRQIFNOIGFuZC9vciBUUywgYW5k IHRoYXQgUlRDUC4NCg0KTWl4ZXI6DQogICAgcHJvczogc3RyYWlnaHQgZm9yd2FyZCBhcHByb2Fj aCBmb3IgbWVkaWEgYWRhcHRhdGlvbi4NCiAgICBjb25zOiBwcmltYXJ5IHNvdXJjZSBvbmx5IGtu b3cgdGhlIHNpdHVhdGlvbiBiZXR3ZWVuIGl0c2VsZiBhbmQgbWl4ZXI7IGNoYW5naW5nIFJUUCBT TiwgVFMsIFNTUkMgYW5kIENTUkMsIGFuZCB0aGF0IFJUQ1AuDQoNCklzIHRoZXJlIGFueSBtaXNz aW5nIHByb3MgJiBjb25zIG9mIHRyYW5zbGF0b3IgYW5kIG1peGVyIG9uIHNwbGljaW5nPyANCg0K DQpUaGFuayB5b3UuDQoNCkppbndlaQ0KDQo+IA0KPj4gDQo+PiBJIHJlc3BlY3QgdGhlIHByZWZl cmVuY2Ugb2YgbWFqb3JpdHkgYW5kIG1vcmUgb3BpbmlvbnMgYXJlIHZlcnkNCj4+IGFwcHJlY2lh dGVkIQ0KPiANCj4gV2VsbCwgSSB3YW50IHRoZSBvcGluaW9uIG9mIGEgaW5mb3JtZWQgbWFqb3Jp dHkuIFdoaWNoIGRvIHJlcXVpcmVzIHRoYXQNCj4gd2Ugd29yayB0aHJvdWdoIHRoZSBtb3RpdmF0 aW9ucy4NCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVB Qi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPiBG5HL2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmls ZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzog bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0= From xiajinwei@huawei.com Wed Apr 13 06:09:52 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5B8BE076B for ; Wed, 13 Apr 2011 06:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=2.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwpXNkG1ZdzZ for ; Wed, 13 Apr 2011 06:09:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 877CEE0758 for ; Wed, 13 Apr 2011 06:09:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL00KYZDVP6P@szxga03-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 21:09:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL006ELDVPFA@szxga03-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 21:09:25 +0800 (CST) Received: from jinwei ([183.208.25.0]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJL00B8FDVNEX@szxml12-in.huawei.com>; Wed, 13 Apr 2011 21:09:25 +0800 (CST) Date: Wed, 13 Apr 2011 21:09:03 +0800 From: Jinwei Xia To: Colin Perkins , David R Oran Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> <51BAA831-B4C1-4D60-A4FB-B8A8C85CDCEE@csperkins.org> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:09:53 -0000 ----- Original Message ----- From: "Colin Perkins" To: "David R Oran" Cc: Sent: Tuesday, April 12, 2011 4:12 AM Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > On 8 Apr 2011, at 16:43, David R Oran wrote: >> I tend to agree with Magnus' assessment. >> >> There seems also to be an additional (only implicitly stated) requirement that people need to internalize (at least I think there is after a number of discussions with the proponents). >> >> That is the ability of the translator to have minimal (or zero) overhead when content is not being actively spliced. I believe the system model the proponents have in their heads is one in which a system sitting in the middle of the network somewhere can have many RTP sessions flowing "through" , or "around" it, and only incur translator overhead during an actual splice operation, and possibly for a short period surrounding the splice. In other words, I'm presuming there's a scalability requirement of the form: "the overhead must scale with the number of active splices, not with the number of RTP sessions flowing through the intermediary". > > I'm not sure there's any solution for the combination of non-detectable splicing and zero overhead when not actively splicing (at least, not without revising RTP). All the solutions I envisage have a per-stream overhead when not splicing in order to achieve non-detectable behaviour: they either need to continually rewrite RTP sequence numbers and RTCP, or act as a mixer and add a CSRC to the stream, and process RTCP packets. As such, they all scale with the number of RTP streams flowing through the intermediary. Agree, even if we do not support non-detectability, translator or mixer still needs to rewrite related RTP parameters for main stream while not actively splicing. More RTP session, more overhead on translator or mixer. > >> I suspect this has substantial impact, perhaps not as great as the non-detectability requirement, but worth pondering for sure. > > > Agreed. It seems to me that the draft authors need to decide whether non-detectable behaviour or zero overhead when not splicing is their goal, as it doesn't look like both are possible. Detectable seems to incur less impact and overhead compared to non-detectable. From such point of view, I prefer less overhead. Jinwei > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Apr 13 06:18:11 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 727D8E0756 for ; Wed, 13 Apr 2011 06:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.852 X-Spam-Level: X-Spam-Status: No, score=-103.852 tagged_above=-999 required=5 tests=[AWL=-1.603, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdSDyBuiwLfK for ; Wed, 13 Apr 2011 06:18:10 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfc.amsl.com (Postfix) with ESMTP id 40779E066B for ; Wed, 13 Apr 2011 06:18:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3DDHu98001457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 15:18:02 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 13 Apr 2011 15:18:01 +0200 From: "DRAGE, Keith (Keith)" To: Jinwei Xia , Magnus Westerlund Date: Wed, 13 Apr 2011 15:17:59 +0200 Thread-Topic: [avtext] Splicing: Confirmation of decisions at IETF#80 Thread-Index: Acv5srt3MqyiinUqRbebXttkYWz3DgAKThbw Message-ID: References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:18:11 -0000 [As WG cochair] In terms of the current direction forward, I'm not convinced any one partic= ular solution has to be selected by the working group. My understanding was that we wanted a document that described: "How do I us= e the existing RTP to perform splicing?" Such a document could have several= solutions, followed by text that stated: "If you do it this way, then thes= e are the implications."=20 Naturally, when the solution document becomes a working group draft, the wo= rking group will have the say whether any particular solution, along with i= ts corresponding implications, form an acceptable solution. That process co= uld nail down the field to one, but I'm not currently convinced we have to = start with one. I'd welcome some views on this. Essentially this would be saying about the current draft - this is one solu= tion. The use of this mechanism has these implications. If you use it take = into account these implications. And the way is free for the proposal of so= mething else that does it differently, with different implications. By the way the milestone has been created on the charter page - we elected = to try and complete this work in December. Please focus the discussion on w= hat we as a working group should be producing. Regards Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Jinwei Xia > Sent: 13 April 2011 09:13 > To: Magnus Westerlund > Cc: avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >=20 > Magnus, >=20 > >=20 > >> > >> Undetectability requirement is specific for some ad insertion use > >> cases (possibly not for all), but some other use cases using splicing > >> operation do not cover the requirement such as those cited by Dave. > >> Thus I will change this undetectability requirement to be optional. > >> If undetectability is considered, IMO it is not easy either for > >> translator or mixer to consider upper layer operation. > > > > Well, it will be detectable, unless one does transcoding in the splicer= , > > or force the two stream to be encoded by the same encoder. If any time > > of media parameter are different between the two stream a downstream > > client will be able to detect the switch. >=20 > Right, in above analysis, translator and mixer both can realize splicing > by changing different RTP parameters. >=20 > > > >> > >> If we use mixer, what's the value in CSRC field when the substitutive > >> content comes from local media file? > > > > Well, that could be assigned. I think we should get back the translator > > vs mixer when we have arrived what the reasonable requirements really > > are. It might in fact be that translator is the correct model and that > > the other aspects overweights some other. > > > >> > >>> > >>> When it comes to the mixer vs translator case, I think one reason > >>> was this non-detectable requirement. Another aspect of it is has to > >>> do with bit-rate adaptation to handle varying network conditions. A > >>> Mixer does kind of cut off the feedback loop between the receiver > >>> and the sender. To bridge that one needs additional RTCP messages. > >> > >> Mixer is simpler one for media adaptation, while translator is also > >> smart enough to carry out adaptation since translator can intercept > >> ECN feedbacks and modify them when congestion occurs during splice > >> period. But I do not oppose that using mixer is a off-the-shelf > >> approach. > > > > I wouldn't say off the shelf approach. Certain aspects are clearly more > > straight forward. Other still needs considerations. > > > >> > >>> > >>> In the context of a translator one can make this operate at least > >>> in the following way. From primary perspective it can see the full > >>> path to the receiver when the splicer is passing its content. And > >>> when the splicer insert the alternative content it could get a > >>> report on the path up to the splicer itself. > >> > >> Right. It is the benefit by using translator. > >> > >>> > >>> I think we need to discuss what our goals really are here. > >>> > >>> Are they only to provide the receiver with a consistent media > >>> stream despite the splicing? > >> > >> It is not mandatory for all splicing use cases, but ad insertion may > >> be a important splicing case in IPTV commercial deployment. > >> > >>> Or does one try to take additional steps to hide the existence of > >>> the splicer from the receivers perspective? > >> > >> IMHO it is unnecessary to hide intermediate nodes from receiver. > > > > Good, that makes things simpler. >=20 > Can we conclude that: >=20 > Translator: > pros: allow primary source know the situation of full path. > cons: more considertaion for media adaptation; changing RTP SN and/or > TS, and that RTCP. >=20 > Mixer: > pros: straight forward approach for media adaptation. > cons: primary source only know the situation between itself and mixer= ; > changing RTP SN, TS, SSRC and CSRC, and that RTCP. >=20 > Is there any missing pros & cons of translator and mixer on splicing? >=20 >=20 > Thank you. >=20 > Jinwei >=20 > > > >> > >> I respect the preference of majority and more opinions are very > >> appreciated! > > > > Well, I want the opinion of a informed majority. Which do requires that > > we work through the motivations. > > > > 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 > > ---------------------------------------------------------------------- > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From daveoran@orandom.net Wed Apr 13 07:01:48 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1188AE0782 for ; Wed, 13 Apr 2011 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSg0dXxiLU90 for ; Wed, 13 Apr 2011 07:01:47 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfc.amsl.com (Postfix) with ESMTP id C65E0E077C for ; Wed, 13 Apr 2011 07:01:46 -0700 (PDT) Received: from sjc-vpnasa-740.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3DDuW0i023473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2011 06:56:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: David R Oran In-Reply-To: Date: Wed, 13 Apr 2011 09:55:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7ED2691D-6625-4B4A-BE4B-7435F7E8EC11@orandom.net> References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:01:48 -0000 On Apr 13, 2011, at 9:17 AM, DRAGE, Keith (Keith) wrote: > [As WG cochair] >=20 > In terms of the current direction forward, I'm not convinced any one = particular solution has to be selected by the working group. >=20 > My understanding was that we wanted a document that described: "How do = I use the existing RTP to perform splicing?" Such a document could have = several solutions, followed by text that stated: "If you do it this way, = then these are the implications."=20 >=20 Yes, this makes sense to me, unless the work goes in the direction of = adding protocol elements (e.g. header extensions), or modifying RTP = algorithms/rules in ways that extend the protocol. > Naturally, when the solution document becomes a working group draft, = the working group will have the say whether any particular solution, = along with its corresponding implications, form an acceptable solution. = That process could nail down the field to one, but I'm not currently = convinced we have to start with one. >=20 > I'd welcome some views on this. >=20 > Essentially this would be saying about the current draft - this is one = solution. The use of this mechanism has these implications. If you use = it take into account these implications. And the way is free for the = proposal of something else that does it differently, with different = implications. >=20 I'm not entirely comfortable with this, as part of our job is to pick = one, or at least a small number of good designs in order to have maximum = interoperability and generality. It is not to explore all parts of the = design space and document them all. Cheers, Dave. > By the way the milestone has been created on the charter page - we = elected to try and complete this work in December. Please focus the = discussion on what we as a working group should be producing. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On = Behalf >> Of Jinwei Xia >> Sent: 13 April 2011 09:13 >> To: Magnus Westerlund >> Cc: avtext@ietf.org >> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >>=20 >> Magnus, >>=20 >> >>=20 >>>>=20 >>>> Undetectability requirement is specific for some ad insertion use >>>> cases (possibly not for all), but some other use cases using = splicing >>>> operation do not cover the requirement such as those cited by Dave. >>>> Thus I will change this undetectability requirement to be optional. >>>> If undetectability is considered, IMO it is not easy either for >>>> translator or mixer to consider upper layer operation. >>>=20 >>> Well, it will be detectable, unless one does transcoding in the = splicer, >>> or force the two stream to be encoded by the same encoder. If any = time >>> of media parameter are different between the two stream a downstream >>> client will be able to detect the switch. >>=20 >> Right, in above analysis, translator and mixer both can realize = splicing >> by changing different RTP parameters. >>=20 >>>=20 >>>>=20 >>>> If we use mixer, what's the value in CSRC field when the = substitutive >>>> content comes from local media file? >>>=20 >>> Well, that could be assigned. I think we should get back the = translator >>> vs mixer when we have arrived what the reasonable requirements = really >>> are. It might in fact be that translator is the correct model and = that >>> the other aspects overweights some other. >>>=20 >>>>=20 >>>>>=20 >>>>> When it comes to the mixer vs translator case, I think one reason >>>>> was this non-detectable requirement. Another aspect of it is has = to >>>>> do with bit-rate adaptation to handle varying network conditions. = A >>>>> Mixer does kind of cut off the feedback loop between the receiver >>>>> and the sender. To bridge that one needs additional RTCP messages. >>>>=20 >>>> Mixer is simpler one for media adaptation, while translator is also >>>> smart enough to carry out adaptation since translator can intercept >>>> ECN feedbacks and modify them when congestion occurs during splice >>>> period. But I do not oppose that using mixer is a off-the-shelf >>>> approach. >>>=20 >>> I wouldn't say off the shelf approach. Certain aspects are clearly = more >>> straight forward. Other still needs considerations. >>>=20 >>>>=20 >>>>>=20 >>>>> In the context of a translator one can make this operate at least >>>>> in the following way. =46rom primary perspective it can see the = full >>>>> path to the receiver when the splicer is passing its content. And >>>>> when the splicer insert the alternative content it could get a >>>>> report on the path up to the splicer itself. >>>>=20 >>>> Right. It is the benefit by using translator. >>>>=20 >>>>>=20 >>>>> I think we need to discuss what our goals really are here. >>>>>=20 >>>>> Are they only to provide the receiver with a consistent media >>>>> stream despite the splicing? >>>>=20 >>>> It is not mandatory for all splicing use cases, but ad insertion = may >>>> be a important splicing case in IPTV commercial deployment. >>>>=20 >>>>> Or does one try to take additional steps to hide the existence of >>>>> the splicer from the receivers perspective? >>>>=20 >>>> IMHO it is unnecessary to hide intermediate nodes from receiver. >>>=20 >>> Good, that makes things simpler. >>=20 >> Can we conclude that: >>=20 >> Translator: >> pros: allow primary source know the situation of full path. >> cons: more considertaion for media adaptation; changing RTP SN = and/or >> TS, and that RTCP. >>=20 >> Mixer: >> pros: straight forward approach for media adaptation. >> cons: primary source only know the situation between itself and = mixer; >> changing RTP SN, TS, SSRC and CSRC, and that RTCP. >>=20 >> Is there any missing pros & cons of translator and mixer on splicing? >>=20 >>=20 >> Thank you. >>=20 >> Jinwei >>=20 >>>=20 >>>>=20 >>>> I respect the preference of majority and more opinions are very >>>> appreciated! >>>=20 >>> Well, I want the opinion of a informed majority. Which do requires = that >>> we work through the motivations. >>>=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 >>> = ---------------------------------------------------------------------- >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Apr 13 07:49:39 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB28DE079C for ; Wed, 13 Apr 2011 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZWBjoOp3XEv for ; Wed, 13 Apr 2011 07:49:39 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfc.amsl.com (Postfix) with ESMTP id E12D0E0793 for ; Wed, 13 Apr 2011 07:49:38 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3DEnEB2030798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Apr 2011 16:49:36 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 13 Apr 2011 16:49:33 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 13 Apr 2011 16:49:31 +0200 Thread-Topic: SRTP store and forward: Confirmation of IETF#80 decisions Thread-Index: AcvtZK9g2Iwqs2ztTHu3z3PMOgE5KwMhSMsA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [avtext] SRTP store and forward: Confirmation of IETF#80 decisions X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:49:39 -0000 (As AVT cochair) There has been no objection received to the deletion of these milestones. I will therefore request the AD to delete them from our charter page. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 28 March 2011 17:25 > To: 'avtext@ietf.org' > Subject: SRTP store and forward: Confirmation of IETF#80 decisions >=20 > (As WG chair) >=20 > During the split of the WGs from the old AVT working group a number of ne= w > milestones were created. For AVTEXT these included: >=20 > Dec 2011 Submit SRTP Store-and-Forward Use Cases and Requirements for > Informational > Dec 2011 Submit Use of the Secure Real-time Transport Protocol (SRTP) in > Store-and-Forward Applications for Proposed Standard >=20 > These were adopted more because drafts existed, rather that because there > had been any real polling in the (AVT) working group for interest. >=20 > Discussion at IETF#80 identified that the original drafts do not really > have a level of support in the way they are currently drafted. There need= s > to be more work on identifying use cases, and ensuring that the solutions > address those use cases in a valid manner. >=20 > As such there is no support for the current milestones. >=20 > The chairs therefore propose to delete the current milestones. If you hav= e > objections to this, then please respond by the end of this week (Friday). >=20 > This does not prevent the authors working on the current drafts to > identify something round which we can build working group consensus. We > can easily create new milestones round this when that occurs. >=20 > Regards >=20 > Keith From xiajinwei@huawei.com Wed Apr 13 07:50:12 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 51EC9E079C for ; Wed, 13 Apr 2011 07:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRK9hbacXBXc for ; Wed, 13 Apr 2011 07:50:11 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id EF00EE0796 for ; Wed, 13 Apr 2011 07:50:10 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL0044MIIWGF@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 22:49:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL009LLIIW96@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 22:49:44 +0800 (CST) Received: from jinwei ([183.208.25.0]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJL00BJUIIVEX@szxml12-in.huawei.com>; Wed, 13 Apr 2011 22:49:44 +0800 (CST) Date: Wed, 13 Apr 2011 22:49:23 +0800 From: Jinwei Xia To: "DRAGE, Keith (Keith)" , Magnus Westerlund Message-id: <464A7AD502134A5697C7D18ADF337E0F@jinwei> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:50:12 -0000 Q2hhaXIsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRFJBR0UsIEtl aXRoIChLZWl0aCkiIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+DQpUbzogIkppbndl aSBYaWEiIDx4aWFqaW53ZWlAaHVhd2VpLmNvbT47ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCkNjOiA8YXZ0ZXh0QGlldGYub3JnPg0KU2VudDog V2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxMSA5OjE3IFBNDQpTdWJqZWN0OiBSRTogW2F2dGV4dF0g U3BsaWNpbmc6IENvbmZpcm1hdGlvbiBvZiBkZWNpc2lvbnMgYXQgSUVURiM4MA0KDQoNCj4gW0Fz IFdHIGNvY2hhaXJdDQo+IA0KPiBJbiB0ZXJtcyBvZiB0aGUgY3VycmVudCBkaXJlY3Rpb24gZm9y d2FyZCwgSSdtIG5vdCBjb252aW5jZWQgYW55IG9uZSBwYXJ0aWN1bGFyIHNvbHV0aW9uIGhhcyB0 byBiZSBzZWxlY3RlZCBieSB0aGUgd29ya2luZyBncm91cC4NCj4gDQo+IE15IHVuZGVyc3RhbmRp bmcgd2FzIHRoYXQgd2Ugd2FudGVkIGEgZG9jdW1lbnQgdGhhdCBkZXNjcmliZWQ6ICJIb3cgZG8g SSB1c2UgdGhlIGV4aXN0aW5nIFJUUCB0byBwZXJmb3JtIHNwbGljaW5nPyIgU3VjaCBhIGRvY3Vt ZW50IGNvdWxkIGhhdmUgc2V2ZXJhbCBzb2x1dGlvbnMsIGZvbGxvd2VkIGJ5IHRleHQgdGhhdCBz dGF0ZWQ6ICJJZiB5b3UgPiBkbyBpdCB0aGlzIHdheSwgdGhlbiB0aGVzZSBhcmUgdGhlIGltcGxp Y2F0aW9ucy4iIA0KPiANCj4gTmF0dXJhbGx5LCB3aGVuIHRoZSBzb2x1dGlvbiBkb2N1bWVudCBi ZWNvbWVzIGEgd29ya2luZyBncm91cCBkcmFmdCwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBoYXZl IHRoZSBzYXkgd2hldGhlciBhbnkgcGFydGljdWxhciBzb2x1dGlvbiwgYWxvbmcgd2l0aCBpdHMg Y29ycmVzcG9uZGluZyBpbXBsaWNhdGlvbnMsIGZvcm0gYW4gYWNjZXB0YWJsZSANCj4gc29sdXRp b24uIFRoYXQgcHJvY2VzcyBjb3VsZCBuYWlsIGRvd24gdGhlIGZpZWxkIHRvIG9uZSwgYnV0IEkn bSBub3QgY3VycmVudGx5IGNvbnZpbmNlZCB3ZSBoYXZlIHRvIHN0YXJ0IHdpdGggb25lLg0KPiAN Cj4gSSdkIHdlbGNvbWUgc29tZSB2aWV3cyBvbiB0aGlzLg0KPiANCj4gRXNzZW50aWFsbHkgdGhp cyB3b3VsZCBiZSBzYXlpbmcgYWJvdXQgdGhlIGN1cnJlbnQgZHJhZnQgLSB0aGlzIGlzIG9uZSBz b2x1dGlvbi4gVGhlIHVzZSBvZiB0aGlzIG1lY2hhbmlzbSBoYXMgdGhlc2UgaW1wbGljYXRpb25z LiBJZiB5b3UgdXNlIGl0IHRha2UgaW50byBhY2NvdW50IHRoZXNlIGltcGxpY2F0aW9ucy4gQW5k IHRoZSB3YXkgaXMgZnJlZSBmb3IgdGhlICA+IHByb3Bvc2FsIG9mIHNvbWV0aGluZyBlbHNlIHRo YXQgZG9lcyBpdCBkaWZmZXJlbnRseSwgd2l0aCBkaWZmZXJlbnQgaW1wbGljYXRpb25zLg0KPiAN Cg0KDQpUaGFuayB5b3UsIHlvdXIgc3VnZ2VzdGlvbiBnaXZlcyBhIHJlYXNvbmFibGUgZGlyZWN0 aW9uLiBJZiB3ZSBhZ3JlZSBvbiB0aGlzLCBJIHdpbGwgYWRkIGRpZmZlcmVudCBzb2x1dGlvbnMg d2l0aCB0aGVpciBjb3JyZXNwb25kaW5nIGltcGxpY2F0aW9ucyBpbiBmdXJ0aGVyIHdvcmsuIA0K DQoNCkJSDQpKaW53ZWkNCg0KPiBCeSB0aGUgd2F5IHRoZSBtaWxlc3RvbmUgaGFzIGJlZW4gY3Jl YXRlZCBvbiB0aGUgY2hhcnRlciBwYWdlIC0gd2UgZWxlY3RlZCB0byB0cnkgYW5kIGNvbXBsZXRl IHRoaXMgd29yayBpbiBEZWNlbWJlci4gUGxlYXNlIGZvY3VzIHRoZSBkaXNjdXNzaW9uIG9uIHdo YXQgd2UgYXMgYSB3b3JraW5nIGdyb3VwIHNob3VsZCBiZSBwcm9kdWNpbmcuDQo+IA0KPiBSZWdh cmRzDQo+IA0KPiBLZWl0aA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGF2dGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0ZXh0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiBKaW53ZWkgWGlhDQo+IFNlbnQ6IDEzIEFwcmlsIDIwMTEgMDk6MTMN Cj4gVG86IE1hZ251cyBXZXN0ZXJsdW5kDQo+IENjOiBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFthdnRleHRdIFNwbGljaW5nOiBDb25maXJtYXRpb24gb2YgZGVjaXNpb25zIGF0IElF VEYjODANCj4gDQo+IE1hZ251cywNCj4gDQo+IDxzbmFwPg0KPiANCj4gPj4NCj4gPj4gVW5kZXRl Y3RhYmlsaXR5IHJlcXVpcmVtZW50IGlzIHNwZWNpZmljIGZvciBzb21lIGFkIGluc2VydGlvbiB1 c2UNCj4gPj4gY2FzZXMgKHBvc3NpYmx5IG5vdCBmb3IgYWxsKSwgYnV0IHNvbWUgb3RoZXIgdXNl IGNhc2VzIHVzaW5nIHNwbGljaW5nDQo+ID4+IG9wZXJhdGlvbiBkbyBub3QgY292ZXIgdGhlIHJl cXVpcmVtZW50IHN1Y2ggYXMgdGhvc2UgY2l0ZWQgYnkgRGF2ZS4NCj4gPj4gVGh1cyBJIHdpbGwg Y2hhbmdlIHRoaXMgdW5kZXRlY3RhYmlsaXR5IHJlcXVpcmVtZW50IHRvIGJlIG9wdGlvbmFsLg0K PiA+PiBJZiB1bmRldGVjdGFiaWxpdHkgaXMgY29uc2lkZXJlZCwgSU1PIGl0IGlzIG5vdCBlYXN5 IGVpdGhlciBmb3INCj4gPj4gdHJhbnNsYXRvciBvciBtaXhlciB0byBjb25zaWRlciB1cHBlciBs YXllciBvcGVyYXRpb24uDQo+ID4NCj4gPiBXZWxsLCBpdCB3aWxsIGJlIGRldGVjdGFibGUsIHVu bGVzcyBvbmUgZG9lcyB0cmFuc2NvZGluZyBpbiB0aGUgc3BsaWNlciwNCj4gPiBvciBmb3JjZSB0 aGUgdHdvIHN0cmVhbSB0byBiZSBlbmNvZGVkIGJ5IHRoZSBzYW1lIGVuY29kZXIuIElmIGFueSB0 aW1lDQo+ID4gb2YgbWVkaWEgcGFyYW1ldGVyIGFyZSBkaWZmZXJlbnQgYmV0d2VlbiB0aGUgdHdv IHN0cmVhbSBhIGRvd25zdHJlYW0NCj4gPiBjbGllbnQgd2lsbCBiZSBhYmxlIHRvIGRldGVjdCB0 aGUgc3dpdGNoLg0KPiANCj4gUmlnaHQsIGluIGFib3ZlIGFuYWx5c2lzLCB0cmFuc2xhdG9yIGFu ZCBtaXhlciBib3RoIGNhbiByZWFsaXplIHNwbGljaW5nDQo+IGJ5IGNoYW5naW5nIGRpZmZlcmVu dCBSVFAgcGFyYW1ldGVycy4NCj4gDQo+ID4NCj4gPj4NCj4gPj4gSWYgd2UgdXNlIG1peGVyLCB3 aGF0J3MgdGhlIHZhbHVlIGluIENTUkMgZmllbGQgd2hlbiB0aGUgc3Vic3RpdHV0aXZlDQo+ID4+ IGNvbnRlbnQgY29tZXMgZnJvbSBsb2NhbCBtZWRpYSBmaWxlPw0KPiA+DQo+ID4gV2VsbCwgdGhh dCBjb3VsZCBiZSBhc3NpZ25lZC4gSSB0aGluayB3ZSBzaG91bGQgZ2V0IGJhY2sgdGhlIHRyYW5z bGF0b3INCj4gPiB2cyBtaXhlciB3aGVuIHdlIGhhdmUgYXJyaXZlZCB3aGF0IHRoZSByZWFzb25h YmxlIHJlcXVpcmVtZW50cyByZWFsbHkNCj4gPiBhcmUuIEl0IG1pZ2h0IGluIGZhY3QgYmUgdGhh dCB0cmFuc2xhdG9yIGlzIHRoZSBjb3JyZWN0IG1vZGVsIGFuZCB0aGF0DQo+ID4gdGhlIG90aGVy IGFzcGVjdHMgb3ZlcndlaWdodHMgc29tZSBvdGhlci4NCj4gPg0KPiA+Pg0KPiA+Pj4NCj4gPj4+ IFdoZW4gaXQgY29tZXMgdG8gdGhlIG1peGVyIHZzIHRyYW5zbGF0b3IgY2FzZSwgSSB0aGluayBv bmUgcmVhc29uDQo+ID4+PiB3YXMgdGhpcyBub24tZGV0ZWN0YWJsZSByZXF1aXJlbWVudC4gQW5v dGhlciBhc3BlY3Qgb2YgaXQgaXMgaGFzIHRvDQo+ID4+PiBkbyB3aXRoIGJpdC1yYXRlIGFkYXB0 YXRpb24gdG8gaGFuZGxlIHZhcnlpbmcgbmV0d29yayBjb25kaXRpb25zLiBBDQo+ID4+PiBNaXhl ciBkb2VzIGtpbmQgb2YgY3V0IG9mZiB0aGUgZmVlZGJhY2sgbG9vcCBiZXR3ZWVuIHRoZSByZWNl aXZlcg0KPiA+Pj4gYW5kIHRoZSBzZW5kZXIuIFRvIGJyaWRnZSB0aGF0IG9uZSBuZWVkcyBhZGRp dGlvbmFsIFJUQ1AgbWVzc2FnZXMuDQo+ID4+DQo+ID4+IE1peGVyIGlzIHNpbXBsZXIgb25lIGZv ciBtZWRpYSBhZGFwdGF0aW9uLCB3aGlsZSB0cmFuc2xhdG9yIGlzIGFsc28NCj4gPj4gc21hcnQg ZW5vdWdoIHRvIGNhcnJ5IG91dCBhZGFwdGF0aW9uIHNpbmNlIHRyYW5zbGF0b3IgY2FuIGludGVy Y2VwdA0KPiA+PiBFQ04gZmVlZGJhY2tzIGFuZCBtb2RpZnkgdGhlbSB3aGVuIGNvbmdlc3Rpb24g b2NjdXJzIGR1cmluZyBzcGxpY2UNCj4gPj4gcGVyaW9kLiBCdXQgSSBkbyBub3Qgb3Bwb3NlIHRo YXQgdXNpbmcgbWl4ZXIgaXMgYSBvZmYtdGhlLXNoZWxmDQo+ID4+IGFwcHJvYWNoLg0KPiA+DQo+ ID4gSSB3b3VsZG4ndCBzYXkgb2ZmIHRoZSBzaGVsZiBhcHByb2FjaC4gQ2VydGFpbiBhc3BlY3Rz IGFyZSBjbGVhcmx5IG1vcmUNCj4gPiBzdHJhaWdodCBmb3J3YXJkLiBPdGhlciBzdGlsbCBuZWVk cyBjb25zaWRlcmF0aW9ucy4NCj4gPg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEluIHRoZSBjb250ZXh0 IG9mIGEgdHJhbnNsYXRvciBvbmUgY2FuIG1ha2UgdGhpcyBvcGVyYXRlIGF0IGxlYXN0DQo+ID4+ PiBpbiB0aGUgZm9sbG93aW5nIHdheS4gRnJvbSBwcmltYXJ5IHBlcnNwZWN0aXZlIGl0IGNhbiBz ZWUgdGhlIGZ1bGwNCj4gPj4+IHBhdGggdG8gdGhlIHJlY2VpdmVyIHdoZW4gdGhlIHNwbGljZXIg aXMgcGFzc2luZyBpdHMgY29udGVudC4gQW5kDQo+ID4+PiB3aGVuIHRoZSBzcGxpY2VyIGluc2Vy dCB0aGUgYWx0ZXJuYXRpdmUgY29udGVudCBpdCBjb3VsZCBnZXQgYQ0KPiA+Pj4gcmVwb3J0IG9u IHRoZSBwYXRoIHVwIHRvIHRoZSBzcGxpY2VyIGl0c2VsZi4NCj4gPj4NCj4gPj4gUmlnaHQuIEl0 IGlzIHRoZSBiZW5lZml0IGJ5IHVzaW5nIHRyYW5zbGF0b3IuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4g SSB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3Mgd2hhdCBvdXIgZ29hbHMgcmVhbGx5IGFyZSBoZXJl Lg0KPiA+Pj4NCj4gPj4+IEFyZSB0aGV5IG9ubHkgdG8gcHJvdmlkZSB0aGUgcmVjZWl2ZXIgd2l0 aCBhIGNvbnNpc3RlbnQgbWVkaWENCj4gPj4+IHN0cmVhbSBkZXNwaXRlIHRoZSBzcGxpY2luZz8N Cj4gPj4NCj4gPj4gSXQgaXMgbm90IG1hbmRhdG9yeSBmb3IgYWxsIHNwbGljaW5nIHVzZSBjYXNl cywgYnV0IGFkIGluc2VydGlvbiBtYXkNCj4gPj4gYmUgYSBpbXBvcnRhbnQgc3BsaWNpbmcgY2Fz ZSBpbiBJUFRWIGNvbW1lcmNpYWwgZGVwbG95bWVudC4NCj4gPj4NCj4gPj4+IE9yIGRvZXMgb25l IHRyeSB0byB0YWtlIGFkZGl0aW9uYWwgc3RlcHMgdG8gaGlkZSB0aGUgZXhpc3RlbmNlIG9mDQo+ ID4+PiB0aGUgc3BsaWNlciBmcm9tIHRoZSByZWNlaXZlcnMgcGVyc3BlY3RpdmU/DQo+ID4+DQo+ ID4+IElNSE8gaXQgaXMgdW5uZWNlc3NhcnkgdG8gaGlkZSBpbnRlcm1lZGlhdGUgbm9kZXMgZnJv bSByZWNlaXZlci4NCj4gPg0KPiA+IEdvb2QsIHRoYXQgbWFrZXMgdGhpbmdzIHNpbXBsZXIuDQo+ IA0KPiBDYW4gd2UgY29uY2x1ZGUgdGhhdDoNCj4gDQo+IFRyYW5zbGF0b3I6DQo+ICAgICBwcm9z OiAgYWxsb3cgcHJpbWFyeSBzb3VyY2Uga25vdyB0aGUgc2l0dWF0aW9uIG9mIGZ1bGwgcGF0aC4N Cj4gICAgIGNvbnM6IG1vcmUgY29uc2lkZXJ0YWlvbiBmb3IgbWVkaWEgYWRhcHRhdGlvbjsgY2hh bmdpbmcgUlRQIFNOIGFuZC9vcg0KPiBUUywgYW5kIHRoYXQgUlRDUC4NCj4gDQo+IE1peGVyOg0K PiAgICAgcHJvczogc3RyYWlnaHQgZm9yd2FyZCBhcHByb2FjaCBmb3IgbWVkaWEgYWRhcHRhdGlv bi4NCj4gICAgIGNvbnM6IHByaW1hcnkgc291cmNlIG9ubHkga25vdyB0aGUgc2l0dWF0aW9uIGJl dHdlZW4gaXRzZWxmIGFuZCBtaXhlcjsNCj4gY2hhbmdpbmcgUlRQIFNOLCBUUywgU1NSQyBhbmQg Q1NSQywgYW5kIHRoYXQgUlRDUC4NCj4gDQo+IElzIHRoZXJlIGFueSBtaXNzaW5nIHByb3MgJiBj b25zIG9mIHRyYW5zbGF0b3IgYW5kIG1peGVyIG9uIHNwbGljaW5nPw0KPiANCj4gDQo+IFRoYW5r IHlvdS4NCj4gDQo+IEppbndlaQ0KPiANCj4gPg0KPiA+Pg0KPiA+PiBJIHJlc3BlY3QgdGhlIHBy ZWZlcmVuY2Ugb2YgbWFqb3JpdHkgYW5kIG1vcmUgb3BpbmlvbnMgYXJlIHZlcnkNCj4gPj4gYXBw cmVjaWF0ZWQhDQo+ID4NCj4gPiBXZWxsLCBJIHdhbnQgdGhlIG9waW5pb24gb2YgYSBpbmZvcm1l ZCBtYWpvcml0eS4gV2hpY2ggZG8gcmVxdWlyZXMgdGhhdA0KPiA+IHdlIHdvcmsgdGhyb3VnaCB0 aGUgbW90aXZhdGlvbnMuDQo+ID4NCj4gPiBDaGVlcnMNCj4gPg0KPiA+IE1hZ251cyBXZXN0ZXJs dW5kDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMs IEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRXJpY3Nz b24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gPiBG5HL2Z2F0 YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiA+IFNFLTE2NCA4 MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5j b20NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGF2dGV4dCBtYWlsaW5nIGxpc3QNCj4gYXZ0ZXh0QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0ZXh0 From xiajinwei@huawei.com Wed Apr 13 08:09:24 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DF6CE06FC for ; Wed, 13 Apr 2011 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZqHbxKpH6Ny for ; Wed, 13 Apr 2011 08:09:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id E51ACE073E for ; Wed, 13 Apr 2011 08:09:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL009T9JEY5P@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 23:08:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJL00LFEJEYZ0@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 13 Apr 2011 23:08:58 +0800 (CST) Received: from jinwei ([183.208.25.0]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJL00BGTJEXEX@szxml12-in.huawei.com>; Wed, 13 Apr 2011 23:08:58 +0800 (CST) Date: Wed, 13 Apr 2011 23:08:38 +0800 From: Jinwei Xia To: David R Oran , "DRAGE, Keith (Keith)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> <7ED2691D-6625-4B4A-BE4B-7435F7E8EC11@orandom.net> Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:09:24 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmlkIFIgT3JhbiIgPGRh dmVvcmFuQG9yYW5kb20ubmV0Pg0KVG86ICJEUkFHRSwgS2VpdGggKEtlaXRoKSIgPGtlaXRoLmRy YWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4NCkNjOiAiSmlud2VpIFhpYSIgPHhpYWppbndlaUBodWF3 ZWkuY29tPjsgIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tPjsgPGF2dGV4dEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTEg OTo1NSBQTQ0KU3ViamVjdDogUmU6IFthdnRleHRdIFNwbGljaW5nOiBDb25maXJtYXRpb24gb2Yg ZGVjaXNpb25zIGF0IElFVEYjODANCg0KDQoNCk9uIEFwciAxMywgMjAxMSwgYXQgOToxNyBBTSwg RFJBR0UsIEtlaXRoIChLZWl0aCkgd3JvdGU6DQoNCj4+ICBbQXMgV0cgY29jaGFpcl0NCj4+ICAN Cj4+ICBJbiB0ZXJtcyBvZiB0aGUgY3VycmVudCBkaXJlY3Rpb24gZm9yd2FyZCwgSSdtIG5vdCBj b252aW5jZWQgYW55IG9uZSBwYXJ0aWN1bGFyIHNvbHV0aW9uIGhhcyB0byBiZSBzZWxlY3RlZCBi eSB0aGUgd29ya2luZyBncm91cC4NCj4+IA0KPj4gIE15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQg d2Ugd2FudGVkIGEgZG9jdW1lbnQgdGhhdCBkZXNjcmliZWQ6ICJIb3cgZG8gSSB1c2UgdGhlIGV4 aXN0aW5nIFJUUCB0byBwZXJmb3JtIHNwbGljaW5nPyIgU3VjaCBhIGRvY3VtZW50IGNvdWxkIGhh dmUgc2V2ZXJhbCBzb2x1dGlvbnMsIGZvbGxvd2VkIGJ5IHRleHQgdGhhdCBzdGF0ZWQ6ICJJZiB5 b3UgZG8gaXQgdGhpcyB3YXksIHRoZW4gdGhlc2UgYXJlIHRoZSBpbXBsaWNhdGlvbnMuIiANCj4+ ICANCj4gWWVzLCB0aGlzIG1ha2VzIHNlbnNlIHRvIG1lLCB1bmxlc3MgdGhlIHdvcmsgZ29lcyBp biB0aGUgZGlyZWN0aW9uIG9mIGFkZGluZyBwcm90b2NvbCBlbGVtZW50cyAoZS5nLiBoZWFkZXIg ZXh0ZW5zaW9ucyksIG9yIG1vZGlmeWluZyBSVFAgYWxnb3JpdGhtcy9ydWxlcyBpbiB3YXlzIHRo YXQgZXh0ZW5kIHRoZSBwcm90b2NvbC4NCg0KVGhlIGN1cnJlbnQgZHJhZnQgaXMgaW5mb3JtYXRp b25hbCBpbnRlbnRpb24gd2l0aG91dCBhbnkgcHJvdG9jb2wgZXh0ZW5zaW9uLg0KDQo+PiAgTmF0 dXJhbGx5LCB3aGVuIHRoZSBzb2x1dGlvbiBkb2N1bWVudCBiZWNvbWVzIGEgd29ya2luZyBncm91 cCBkcmFmdCwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBoYXZlIHRoZSBzYXkgd2hldGhlciBhbnkg cGFydGljdWxhciBzb2x1dGlvbiwgYWxvbmcgd2l0aCBpdHMgY29ycmVzcG9uZGluZyBpbXBsaWNh dGlvbnMsIGZvcm0gYW4gYWNjZXB0YWJsZSBzb2x1dGlvbi4gVGhhdCBwcm9jZXNzIGNvdWxkIG5h aWwgZG93biB0aGUgZmllbGQgdG8gb25lLCBidXQgSSdtIG5vdCBjdXJyZW50bHkgY29udmluY2Vk IHdlIGhhdmUgdG8gc3RhcnQgd2l0aCBvbmUuDQo+PiAgDQo+PiAgSSdkIHdlbGNvbWUgc29tZSB2 aWV3cyBvbiB0aGlzLg0KPj4gIA0KPj4gIEVzc2VudGlhbGx5IHRoaXMgd291bGQgYmUgc2F5aW5n IGFib3V0IHRoZSBjdXJyZW50IGRyYWZ0IC0gdGhpcyBpcyBvbmUgc29sdXRpb24uIFRoZSB1c2Ug b2YgdGhpcyBtZWNoYW5pc20gaGFzIHRoZXNlIGltcGxpY2F0aW9ucy4gSWYgeW91IHVzZSBpdCB0 YWtlIGludG8gYWNjb3VudCB0aGVzZSBpbXBsaWNhdGlvbnMuIEFuZCB0aGUgd2F5IGlzIGZyZWUg Zm9yIHRoZSBwcm9wb3NhbCBvZiBzb21ldGhpbmcgZWxzZSB0aGF0IGRvZXMgaXQgZGlmZmVyZW50 bHksIHdpdGggZGlmZmVyZW50IGltcGxpY2F0aW9ucy4NCj4+ICANCj4gSSdtIG5vdCBlbnRpcmVs eSBjb21mb3J0YWJsZSB3aXRoIHRoaXMsIGFzIHBhcnQgb2Ygb3VyIGpvYiBpcyB0byBwaWNrIG9u ZSwgb3IgYXQgbGVhc3QgYSBzbWFsbCBudW1iZXIgb2YgZ29vZCBkZXNpZ25zIGluIG9yZGVyIHRv IGhhdmUgbWF4aW11bSBpbnRlcm9wZXJhYmlsaXR5IGFuZCBnZW5lcmFsaXR5LiBJdCBpcyBub3Qg dG8gZXhwbG9yZSBhbGwgcGFydHMgb2YgdGhlIGRlc2lnbiBzcGFjZSBhbmQgZG9jdW1lbnQgdGhl bSBhbGwuDQoNCkFncmVlLCB3ZSBvbmx5IGNvbnNpZGVyIHRoZSByZWFzb25hYmxlIHJlcXVpcmVt ZW50cywgd2hpY2ggYXJlIGRlZXBseSBkaXNjdXNzZWQgaGVyZSwgYW5kIHRoZWlyIGNvcnJlc3Bv bmRpbmcgc29sdXRpb24uIEFueSBtYXJnaW4gY2FzZSBpcyBvdXQgb2Ygc2NvcGUgdW5sZXNzIGl0 IGhhcyBjb252aW5jaW5nIHJlYXNvbi4NCg0KVGhhbmsgeW91IA0KDQoNCkppbndlaQ0KDQo+IENo ZWVycywgRGF2ZS4NCg0KPiBCeSB0aGUgd2F5IHRoZSBtaWxlc3RvbmUgaGFzIGJlZW4gY3JlYXRl ZCBvbiB0aGUgY2hhcnRlciBwYWdlIC0gd2UgZWxlY3RlZCB0byB0cnkgYW5kIGNvbXBsZXRlIHRo aXMgd29yayBpbiBEZWNlbWJlci4gUGxlYXNlIGZvY3VzIHRoZSBkaXNjdXNzaW9uIG9uIHdoYXQg d2UgYXMgYSB3b3JraW5nIGdyb3VwIHNob3VsZCBiZSBwcm9kdWNpbmcuDQo+IA0KPiBSZWdhcmRz DQo+IA0KPiBLZWl0aA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBhdnRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dGV4dC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYNCj4+IE9mIEppbndlaSBYaWENCj4+IFNlbnQ6IDEzIEFwcmlsIDIwMTEgMDk6 MTMNCj4+IFRvOiBNYWdudXMgV2VzdGVybHVuZA0KPj4gQ2M6IGF2dGV4dEBpZXRmLm9yZw0KPj4g U3ViamVjdDogUmU6IFthdnRleHRdIFNwbGljaW5nOiBDb25maXJtYXRpb24gb2YgZGVjaXNpb25z IGF0IElFVEYjODANCj4+IA0KPj4gTWFnbnVzLA0KPj4gDQo+PiA8c25hcD4NCj4+IA0KPj4+PiAN Cj4+Pj4gVW5kZXRlY3RhYmlsaXR5IHJlcXVpcmVtZW50IGlzIHNwZWNpZmljIGZvciBzb21lIGFk IGluc2VydGlvbiB1c2UNCj4+Pj4gY2FzZXMgKHBvc3NpYmx5IG5vdCBmb3IgYWxsKSwgYnV0IHNv bWUgb3RoZXIgdXNlIGNhc2VzIHVzaW5nIHNwbGljaW5nDQo+Pj4+IG9wZXJhdGlvbiBkbyBub3Qg Y292ZXIgdGhlIHJlcXVpcmVtZW50IHN1Y2ggYXMgdGhvc2UgY2l0ZWQgYnkgRGF2ZS4NCj4+Pj4g VGh1cyBJIHdpbGwgY2hhbmdlIHRoaXMgdW5kZXRlY3RhYmlsaXR5IHJlcXVpcmVtZW50IHRvIGJl IG9wdGlvbmFsLg0KPj4+PiBJZiB1bmRldGVjdGFiaWxpdHkgaXMgY29uc2lkZXJlZCwgSU1PIGl0 IGlzIG5vdCBlYXN5IGVpdGhlciBmb3INCj4+Pj4gdHJhbnNsYXRvciBvciBtaXhlciB0byBjb25z aWRlciB1cHBlciBsYXllciBvcGVyYXRpb24uDQo+Pj4gDQo+Pj4gV2VsbCwgaXQgd2lsbCBiZSBk ZXRlY3RhYmxlLCB1bmxlc3Mgb25lIGRvZXMgdHJhbnNjb2RpbmcgaW4gdGhlIHNwbGljZXIsDQo+ Pj4gb3IgZm9yY2UgdGhlIHR3byBzdHJlYW0gdG8gYmUgZW5jb2RlZCBieSB0aGUgc2FtZSBlbmNv ZGVyLiBJZiBhbnkgdGltZQ0KPj4+IG9mIG1lZGlhIHBhcmFtZXRlciBhcmUgZGlmZmVyZW50IGJl dHdlZW4gdGhlIHR3byBzdHJlYW0gYSBkb3duc3RyZWFtDQo+Pj4gY2xpZW50IHdpbGwgYmUgYWJs ZSB0byBkZXRlY3QgdGhlIHN3aXRjaC4NCj4+IA0KPj4gUmlnaHQsIGluIGFib3ZlIGFuYWx5c2lz LCB0cmFuc2xhdG9yIGFuZCBtaXhlciBib3RoIGNhbiByZWFsaXplIHNwbGljaW5nDQo+PiBieSBj aGFuZ2luZyBkaWZmZXJlbnQgUlRQIHBhcmFtZXRlcnMuDQo+PiANCj4+PiANCj4+Pj4gDQo+Pj4+ IElmIHdlIHVzZSBtaXhlciwgd2hhdCdzIHRoZSB2YWx1ZSBpbiBDU1JDIGZpZWxkIHdoZW4gdGhl IHN1YnN0aXR1dGl2ZQ0KPj4+PiBjb250ZW50IGNvbWVzIGZyb20gbG9jYWwgbWVkaWEgZmlsZT8N Cj4+PiANCj4+PiBXZWxsLCB0aGF0IGNvdWxkIGJlIGFzc2lnbmVkLiBJIHRoaW5rIHdlIHNob3Vs ZCBnZXQgYmFjayB0aGUgdHJhbnNsYXRvcg0KPj4+IHZzIG1peGVyIHdoZW4gd2UgaGF2ZSBhcnJp dmVkIHdoYXQgdGhlIHJlYXNvbmFibGUgcmVxdWlyZW1lbnRzIHJlYWxseQ0KPj4+IGFyZS4gSXQg bWlnaHQgaW4gZmFjdCBiZSB0aGF0IHRyYW5zbGF0b3IgaXMgdGhlIGNvcnJlY3QgbW9kZWwgYW5k IHRoYXQNCj4+PiB0aGUgb3RoZXIgYXNwZWN0cyBvdmVyd2VpZ2h0cyBzb21lIG90aGVyLg0KPj4+ IA0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gV2hlbiBpdCBjb21lcyB0byB0aGUgbWl4ZXIgdnMgdHJh bnNsYXRvciBjYXNlLCBJIHRoaW5rIG9uZSByZWFzb24NCj4+Pj4+IHdhcyB0aGlzIG5vbi1kZXRl Y3RhYmxlIHJlcXVpcmVtZW50LiBBbm90aGVyIGFzcGVjdCBvZiBpdCBpcyBoYXMgdG8NCj4+Pj4+ IGRvIHdpdGggYml0LXJhdGUgYWRhcHRhdGlvbiB0byBoYW5kbGUgdmFyeWluZyBuZXR3b3JrIGNv bmRpdGlvbnMuIEENCj4+Pj4+IE1peGVyIGRvZXMga2luZCBvZiBjdXQgb2ZmIHRoZSBmZWVkYmFj ayBsb29wIGJldHdlZW4gdGhlIHJlY2VpdmVyDQo+Pj4+PiBhbmQgdGhlIHNlbmRlci4gVG8gYnJp ZGdlIHRoYXQgb25lIG5lZWRzIGFkZGl0aW9uYWwgUlRDUCBtZXNzYWdlcy4NCj4+Pj4gDQo+Pj4+ IE1peGVyIGlzIHNpbXBsZXIgb25lIGZvciBtZWRpYSBhZGFwdGF0aW9uLCB3aGlsZSB0cmFuc2xh dG9yIGlzIGFsc28NCj4+Pj4gc21hcnQgZW5vdWdoIHRvIGNhcnJ5IG91dCBhZGFwdGF0aW9uIHNp bmNlIHRyYW5zbGF0b3IgY2FuIGludGVyY2VwdA0KPj4+PiBFQ04gZmVlZGJhY2tzIGFuZCBtb2Rp ZnkgdGhlbSB3aGVuIGNvbmdlc3Rpb24gb2NjdXJzIGR1cmluZyBzcGxpY2UNCj4+Pj4gcGVyaW9k LiBCdXQgSSBkbyBub3Qgb3Bwb3NlIHRoYXQgdXNpbmcgbWl4ZXIgaXMgYSBvZmYtdGhlLXNoZWxm DQo+Pj4+IGFwcHJvYWNoLg0KPj4+IA0KPj4+IEkgd291bGRuJ3Qgc2F5IG9mZiB0aGUgc2hlbGYg YXBwcm9hY2guIENlcnRhaW4gYXNwZWN0cyBhcmUgY2xlYXJseSBtb3JlDQo+Pj4gc3RyYWlnaHQg Zm9yd2FyZC4gT3RoZXIgc3RpbGwgbmVlZHMgY29uc2lkZXJhdGlvbnMuDQo+Pj4gDQo+Pj4+IA0K Pj4+Pj4gDQo+Pj4+PiBJbiB0aGUgY29udGV4dCBvZiBhIHRyYW5zbGF0b3Igb25lIGNhbiBtYWtl IHRoaXMgb3BlcmF0ZSBhdCBsZWFzdA0KPj4+Pj4gaW4gdGhlIGZvbGxvd2luZyB3YXkuIEZyb20g cHJpbWFyeSBwZXJzcGVjdGl2ZSBpdCBjYW4gc2VlIHRoZSBmdWxsDQo+Pj4+PiBwYXRoIHRvIHRo ZSByZWNlaXZlciB3aGVuIHRoZSBzcGxpY2VyIGlzIHBhc3NpbmcgaXRzIGNvbnRlbnQuIEFuZA0K Pj4+Pj4gd2hlbiB0aGUgc3BsaWNlciBpbnNlcnQgdGhlIGFsdGVybmF0aXZlIGNvbnRlbnQgaXQg Y291bGQgZ2V0IGENCj4+Pj4+IHJlcG9ydCBvbiB0aGUgcGF0aCB1cCB0byB0aGUgc3BsaWNlciBp dHNlbGYuDQo+Pj4+IA0KPj4+PiBSaWdodC4gSXQgaXMgdGhlIGJlbmVmaXQgYnkgdXNpbmcgdHJh bnNsYXRvci4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEkgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNz IHdoYXQgb3VyIGdvYWxzIHJlYWxseSBhcmUgaGVyZS4NCj4+Pj4+IA0KPj4+Pj4gQXJlIHRoZXkg b25seSB0byBwcm92aWRlIHRoZSByZWNlaXZlciB3aXRoIGEgY29uc2lzdGVudCBtZWRpYQ0KPj4+ Pj4gc3RyZWFtIGRlc3BpdGUgdGhlIHNwbGljaW5nPw0KPj4+PiANCj4+Pj4gSXQgaXMgbm90IG1h bmRhdG9yeSBmb3IgYWxsIHNwbGljaW5nIHVzZSBjYXNlcywgYnV0IGFkIGluc2VydGlvbiBtYXkN Cj4+Pj4gYmUgYSBpbXBvcnRhbnQgc3BsaWNpbmcgY2FzZSBpbiBJUFRWIGNvbW1lcmNpYWwgZGVw bG95bWVudC4NCj4+Pj4gDQo+Pj4+PiBPciBkb2VzIG9uZSB0cnkgdG8gdGFrZSBhZGRpdGlvbmFs IHN0ZXBzIHRvIGhpZGUgdGhlIGV4aXN0ZW5jZSBvZg0KPj4+Pj4gdGhlIHNwbGljZXIgZnJvbSB0 aGUgcmVjZWl2ZXJzIHBlcnNwZWN0aXZlPw0KPj4+PiANCj4+Pj4gSU1ITyBpdCBpcyB1bm5lY2Vz c2FyeSB0byBoaWRlIGludGVybWVkaWF0ZSBub2RlcyBmcm9tIHJlY2VpdmVyLg0KPj4+IA0KPj4+ IEdvb2QsIHRoYXQgbWFrZXMgdGhpbmdzIHNpbXBsZXIuDQo+PiANCj4+IENhbiB3ZSBjb25jbHVk ZSB0aGF0Og0KPj4gDQo+PiBUcmFuc2xhdG9yOg0KPj4gICAgcHJvczogIGFsbG93IHByaW1hcnkg c291cmNlIGtub3cgdGhlIHNpdHVhdGlvbiBvZiBmdWxsIHBhdGguDQo+PiAgICBjb25zOiBtb3Jl IGNvbnNpZGVydGFpb24gZm9yIG1lZGlhIGFkYXB0YXRpb247IGNoYW5naW5nIFJUUCBTTiBhbmQv b3INCj4+IFRTLCBhbmQgdGhhdCBSVENQLg0KPj4gDQo+PiBNaXhlcjoNCj4+ICAgIHByb3M6IHN0 cmFpZ2h0IGZvcndhcmQgYXBwcm9hY2ggZm9yIG1lZGlhIGFkYXB0YXRpb24uDQo+PiAgICBjb25z OiBwcmltYXJ5IHNvdXJjZSBvbmx5IGtub3cgdGhlIHNpdHVhdGlvbiBiZXR3ZWVuIGl0c2VsZiBh bmQgbWl4ZXI7DQo+PiBjaGFuZ2luZyBSVFAgU04sIFRTLCBTU1JDIGFuZCBDU1JDLCBhbmQgdGhh dCBSVENQLg0KPj4gDQo+PiBJcyB0aGVyZSBhbnkgbWlzc2luZyBwcm9zICYgY29ucyBvZiB0cmFu c2xhdG9yIGFuZCBtaXhlciBvbiBzcGxpY2luZz8NCj4+IA0KPj4gDQo+PiBUaGFuayB5b3UuDQo+ PiANCj4+IEppbndlaQ0KPj4gDQo+Pj4gDQo+Pj4+IA0KPj4+PiBJIHJlc3BlY3QgdGhlIHByZWZl cmVuY2Ugb2YgbWFqb3JpdHkgYW5kIG1vcmUgb3BpbmlvbnMgYXJlIHZlcnkNCj4+Pj4gYXBwcmVj aWF0ZWQhDQo+Pj4gDQo+Pj4gV2VsbCwgSSB3YW50IHRoZSBvcGluaW9uIG9mIGEgaW5mb3JtZWQg bWFqb3JpdHkuIFdoaWNoIGRvIHJlcXVpcmVzIHRoYXQNCj4+PiB3ZSB3b3JrIHRocm91Z2ggdGhl IG1vdGl2YXRpb25zLg0KPj4+IA0KPj4+IENoZWVycw0KPj4+IA0KPj4+IE1hZ251cyBXZXN0ZXJs dW5kDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVz LCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IEVyaWNz c29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+Pj4gRuRy9mdh dGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4+PiBTRS0xNjQg ODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IGF2dGV4dCBtYWlsaW5nIGxpc3QNCj4+IGF2dGV4dEBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXZ0ZXh0 IG1haWxpbmcgbGlzdA0KPiBhdnRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg== From magnus.westerlund@ericsson.com Thu Apr 14 01:29:27 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C4DF8E0747 for ; Thu, 14 Apr 2011 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1C95oW-Cx5G for ; Thu, 14 Apr 2011 01:29:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id F0569E075E for ; Thu, 14 Apr 2011 01:29:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-4a-4da6b066e65d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 80.26.11171.660B6AD4; Thu, 14 Apr 2011 10:29:26 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 10:29:25 +0200 Message-ID: <4DA6B065.9000204@ericsson.com> Date: Thu, 14 Apr 2011 10:29:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Draft minutes for AVTEXT session IETF80 Prague X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:29:27 -0000 Hi, We have now upload minutes for AVTEXT, they are available here: http://www.ietf.org/proceedings/80/minutes/avtext.txt Please review them and provide comments if you have clarifications or questions. There are at least one unknown in there and some question marks to what actually was meant. 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 tom.van_caenegem@alcatel-lucent.com Tue Apr 19 09:10:59 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2AE99E07BB for ; Tue, 19 Apr 2011 09:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4nAk66Vob1A for ; Tue, 19 Apr 2011 09:10:52 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfc.amsl.com (Postfix) with ESMTP id 9B777E07B9 for ; Tue, 19 Apr 2011 09:10:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3JGAjpH008112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 18:10:45 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Apr 2011 18:10:45 +0200 From: "Van Caenegem, Tom (Tom)" To: "avtext@ietf.org" Date: Tue, 19 Apr 2011 18:10:43 +0200 Thread-Topic: draft-begen-avtext-rams-scenarios-00 : comments Thread-Index: Acv+rFXn1hPrCpaDTOyQVQL/SJRGtA== Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [avtext] draft-begen-avtext-rams-scenarios-00 : comments X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:10:59 -0000 Hi Ali, =20 I read through the draft draft-begen-avtext-rams-scenarios-00. -One general comment I have is that you mention multiple times "RAMS sessio= n", while "RAMS session" is not defined in the RAMS draft. Maybe it would b= e good to clarify this. =20 E.g. in the Intro section, you say: "In scenarios where multiple RAMS sessions will be simultaneously run by an RTP receiver, they need to be coordinated." I suggest to say:=20 =20 "In scenarios where multiple RAMS sessions, each initiated with an individua= l RAMS-R message to a different feedback target FT-ap,=20 will be simultaneously run by an RTP receiver, they need to be coordinated = by the RTP receiver." =20 -because the draft focuses on co-ordinated RAMS sessions/scenarios, maybe a= dd this in the title of the draft? -I do not identify easily what are the guidelines this draft proposes (as m= entioned in the intro/abstract). Is this about which multiplexing scenario = is best in terms of combination with RAMS, in terms of flexibility ?.. Perh= aps just stick to describing different scenarios, without mentioning guidel= ines? These are more detailed comments: =20 =20 Section introduction "However, the specification has mostly focused on the simplest case, which is when the RTP receiver acquires only one multicast stream at a time, to explain the protocol details." =20 I would rephrase this as follows: =20 The specification does not discuss scenarios where an RTP receiver makes us= e of RAMS to rapidly acquire multiple and associated multicast streams in p= arallel, or where different RTP sessions are part of the same SSM. E.g. the= example section 8.3 in the specification addresses only the simple case of= an RTP receiver rapidly acquiring only one multicast stream based on an SD= P which describes a single SSM composed of a single RTP stream." =20 =20 =20 section 4.3 : see my comments for section 6.3.. I do not understand scenari= o 3 =20 =20 =20 section 4.4: "and the retransmission and RAMS operations will not be able to be applied based on the payload type" DELETE: "retransmission" (..because retransmission is based on RTP SN.. no= need to distinguish among PT?) =20 section 5: "However, since this is not an easy requirement to satisfy, RAMS specification forbids to have more than one RTP session to be associated with a specific feedback target" =20 ADD: ..with a specific FB target on a specific port. =20 =20 =20 section 6.1 =20 "This is the preferred deployment model for FEC. Having FEC in a different multicast group provides flexibility for not only the RTP receivers that are not FEC capable but also the ones that are FEC capable but are not willing to receive FEC during the rapid acquisition." SUGGEST to DELETE: This is the preferred deployment model for FEC. =20 REPHRASE : Having FEC in a different multicast group provides two flexibility points: RTP receivers that are not FEC capable can receive the primary video stream = without FEC, and RTP receivers that are FEC capable can decide to not receive FEC during the rapid acquisition (but still join the FEC stream after RAMS for the primary vi= deo stream has finished). =20 =20 "In this case, the RTP receiver can request a Max Receive Bitrate of 22 Mbps in the RAMS Request message" =20 ADD: ..in the RAMS request message for the prmary video stream. =20 =20 =20 =20 section 6.2: =20 "The only difference from scenario #1 is that here the join time is the same for both the primary video and FEC streams". REPHRASE: .. is that here the join time is default the same for the primary= video and FEC stream. =20 (editor note: also in scenario 1 the join time can be the same) =20 =20 =20 section 6.3 =20 "This is similar to scenario #2. However, since we cannot explicitly specify the bitrates for the primary and FEC streams, the RTP receiver can request to rapidly acquire both streams in parallel. In this case, two separate RAMS Request messages have to be sent by the RTP receiver to the feedback target." =20 ..I am a bit confused here. Fact is that, following the RAMS specification,= normally a single RAMS-R message is sent. If we know the SSRCs of each str= eam, an RTP receiver can just request the primary video stream. However, a = single RAMS-R does not allow to specify e.g. "max receive bit rate" per str= eam.. but I do not think this is desired anyhow, as it will be the source o= f the two sub streams that determine the relative bursting of the two strea= ms. If we do not know the SSRC values, we cannot request separately the SSRC st= reams using a single RAMS-R. ..but why do we need to send two separate RAMS-R messages... and how will y= ou do that when there is only a single FT-ap? =20 =20 From petithug@acm.org Thu Apr 21 11:26:39 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5E3AE07FD for ; Thu, 21 Apr 2011 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.065 X-Spam-Level: X-Spam-Status: No, score=-101.065 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrXEfDvEeY-Z for ; Thu, 21 Apr 2011 11:26:38 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfc.amsl.com (Postfix) with ESMTP id B3F86E07E4 for ; Thu, 21 Apr 2011 11:26:38 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 1BCDBDBCC046; Thu, 21 Apr 2011 18:26:38 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id EE70ADBCC044; Thu, 21 Apr 2011 18:26:29 +0000 (UTC) Message-ID: <4DB076D5.3000501@acm.org> Date: Thu, 21 Apr 2011 11:26:29 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: Magnus Westerlund References: <4D8B107E.9000809@ericsson.com> <4D9001DB.3050106@acm.org> <4D903D27.50609@ericsson.com> In-Reply-To: <4D903D27.50609@ericsson.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:26:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Magnus, Going back to this topic after some vacations. See below. On 03/28/2011 12:47 AM, Magnus Westerlund wrote: > Marc, WG > > See Inline > > Marc Petit-Huguenin skrev 2011-03-28 05:34: >> Hi Magnus, >> >> Thanks for the review, and sorry to not responding sooner. >> >> On 03/24/2011 10:35 AM, Magnus Westerlund wrote: >>> Hi, >>> >>> This mail is my personal opinions and not as a WG chair. >>> >>> I have reviewed the draft and think it is a reasonable starting point >>> for meeting the WG's milestone. >>> >>> However, I do have some technical comments. >>> [...] >>> >>> In my view the method in 2.2.1 is incorrect in one important detail: >>> >>> timestamp = previous_timestamp + (current_capture_time - >>> previous_capture_time) * current_clock_rate >>> >>> The "current_clock_rate" should actually be previous clock rate. If one >>> uses the clock rate from the previous packet to cover the time period up >>> to a switch then one avoids any discontinuities and the jitter doesn't >>> make a jump before one knows what the new clock rate is. >>> >>> It is also consistent with logical thinking for any media that had >>> duration. Take for example audio with 20 ms frame lengths, the RTP TS >>> value for a packet with one frame provides the time at the start of the >>> frame. Then the frame has a duration of 20 ms, thus resulting in that >>> the timestamp value of any next frame that are aligned with the current >>> will be starting at last_TS+0.02*clock_rate. >>> >>> Thus resulting in that the formula should read: >>> timestamp = previous_timestamp + (current_capture_time - >>> previous_capture_time) * previous_clock_rate >>> >>> One also needs to reconsider the arrival formulas to use previous: >>> (1) current_time_capture = (current_timestamp - previous_timestamp) / >>> previous_clock_rate + previous_time_capture >>> (2) transit = previous_clock_rate * (time_arrival - >>> current_time_capture) >>> (3) previous_time_capture = current_time_capture >>> (4) previous_clock_rate = current_clock_rate >>> >>> >>> Using these formulas to update table 2: >>> >>> +-------+-------+-----------+---------+---------+--------+----------+ >>> | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | >>> | time | rate | timestamp | time | | | jitter | >>> +-------+-------+-----------+---------+---------+--------+----------+ >>> | 0 | 8000 | 0 | 0.1 | 800 | | | >>> | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | >>> | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | >>> | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | >>> | 0.08 | 16000 | 640 | 0.18 | 800 | 0 | 0 | >>> | 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 | >>> | 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 | >>> | 0.14 | 8000 | 1600 | 0.24 | 1600 | 0 | 0 | >>> | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 | >>> +-------+-------+-----------+---------+---------+--------+----------+ >>> >>> >>> Which I think avoids all the issues with the jitter etc. >>> >>> If a packet loss occur with the first packet with the new rate then >>> there will be a jitter value here due to the definition of jitter as >>> using the timestamp values of the older packet part of the calculation. >>> >>> >>> 2. Also I think Section 2.2.2 points to a naive implementation of that >>> method. As I see it when you do calculations based on that method you >>> need to use the more expanded formula: >> >> A the difference of the formula in 2.2.1 (which is what people actually use)), >> the formula in 2.2.2 is the one that the I-D tentatively set as the formula for >> future implementations that does not want to use a different SSRC (more about >> this below). >> >> Now you do not explain why this formula is better than the simpler formula >> capture_time * clock_rate. See also my response to the next comments. > > Well, it avoids the jump backwards in TS that you got unless you adjust > the start point. Yes, but - unless my calculations are incorrect - the jitter is still incorrect with this formula. I created a Google spreadsheet to illustrate this (in "Magnus proposal" tab): https://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdDhwMEhuOEVGdzVDdnNkMlluRGRnb1E&hl=en&authkey=CLaT9oAI Please let me know if I missed something. > >> >>> >>> timestamp = (capture_time-capture_start) * clock_rate + Start_offset >>> >>> Then every time you change the rate you need to set new values for >>> "capture_start" and Start_offset: >>> >>> Start_offset = (capture_time_start_of_new_rate-capture_start) >>> *previous_clock_rate >>> capture_start = capture_time_start_of_new_rate >>> [...] - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2wdtMACgkQ9RoMZyVa61eqZQCfakm4xLy1oX7l8RtlfIxnIG0o T2gAn3VbDWyeMkIvoZJwaqcAOq7XyVIZ =z6+c -----END PGP SIGNATURE----- From rjesup@wgate.com Thu Apr 21 20:01:29 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EBE0CE0792 for ; Thu, 21 Apr 2011 20:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5hPczB99NwM for ; Thu, 21 Apr 2011 20:01:29 -0700 (PDT) Received: from exchange10.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by ietfc.amsl.com (Postfix) with ESMTP id 569FBE078F for ; Thu, 21 Apr 2011 20:01:29 -0700 (PDT) Received: from jesup.eng.wgate.com (10.32.2.26) by exchange10.wgate.com (10.1.1.8) with Microsoft SMTP Server id 14.1.270.1; Thu, 21 Apr 2011 23:01:15 -0400 From: Randell Jesup To: Marc Petit-Huguenin References: <4D8B107E.9000809@ericsson.com> <4D9001DB.3050106@acm.org> <4D903D27.50609@ericsson.com> <4DB076D5.3000501@acm.org> Date: Thu, 21 Apr 2011 23:01:13 -0400 In-Reply-To: <4DB076D5.3000501@acm.org> (Marc Petit-Huguenin's message of "Thu, 21 Apr 2011 11:26:29 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 03:01:30 -0000 >>> A the difference of the formula in 2.2.1 (which is what people actually use)), >>> the formula in 2.2.2 is the one that the I-D tentatively set as the formula for >>> future implementations that does not want to use a different SSRC (more about >>> this below). >>> >>> Now you do not explain why this formula is better than the simpler formula >>> capture_time * clock_rate. See also my response to the next comments. >> >> Well, it avoids the jump backwards in TS that you got unless you adjust >> the start point. > >Yes, but - unless my calculations are incorrect - the jitter is still incorrect >with this formula. I created a Google spreadsheet to illustrate this (in >"Magnus proposal" tab): > >https://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdDhwMEhuOEVGdzVDdnNkMlluRGRnb1E&hl=en&authkey=CLaT9oAI > >Please let me know if I missed something. Well, I should note that "incorrect" implies that there's a canonical "correct" value. I would assert there isn't; there's merely the value calculated as per the spec. Since the original spec didn't anticipate clock-rate changes, the fact that the jitter readings for Magnus' proposal doesn't match what the legacy algorithm would calculate doesn't mean they're 'wrong'; just different. The jitter values reported in RTCP are rather imprecise to begin with, since if I remember they're affected by things like duplicate packets. Note: I have not reviewed the proposal (though I took part in discussions on this issue here 3 or 4 years ago) and have no opinion on it currently. -- Randell Jesup, Worldgate rjesup@wgate.com From petithug@acm.org Thu Apr 21 20:33:37 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5C13E07B2 for ; Thu, 21 Apr 2011 20:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oxbnbJ-FwYX for ; Thu, 21 Apr 2011 20:33:37 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfc.amsl.com (Postfix) with ESMTP id DCD96E0770 for ; Thu, 21 Apr 2011 20:33:36 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CFA01DBCC046; Fri, 22 Apr 2011 03:33:35 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 2E295DBCC044; Fri, 22 Apr 2011 03:33:35 +0000 (UTC) Message-ID: <4DB0F70E.4090809@acm.org> Date: Thu, 21 Apr 2011 20:33:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: Randell Jesup References: <4D8B107E.9000809@ericsson.com> <4D9001DB.3050106@acm.org> <4D903D27.50609@ericsson.com> <4DB076D5.3000501@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 03:33:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/21/2011 08:01 PM, Randell Jesup wrote: >>>> A the difference of the formula in 2.2.1 (which is what people actually use)), >>>> the formula in 2.2.2 is the one that the I-D tentatively set as the formula for >>>> future implementations that does not want to use a different SSRC (more about >>>> this below). >>>> >>>> Now you do not explain why this formula is better than the simpler formula >>>> capture_time * clock_rate. See also my response to the next comments. >>> >>> Well, it avoids the jump backwards in TS that you got unless you adjust >>> the start point. >> >> Yes, but - unless my calculations are incorrect - the jitter is still incorrect >> with this formula. I created a Google spreadsheet to illustrate this (in >> "Magnus proposal" tab): >> >> https://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdDhwMEhuOEVGdzVDdnNkMlluRGRnb1E&hl=en&authkey=CLaT9oAI >> >> Please let me know if I missed something. > > Well, I should note that "incorrect" implies that there's a canonical > "correct" value. I would assert there isn't; there's merely the value > calculated as per the spec. Since the original spec didn't anticipate > clock-rate changes, the fact that the jitter readings for Magnus' > proposal doesn't match what the legacy algorithm would calculate doesn't > mean they're 'wrong'; just different. The formula I proposed in 2.2.2 (capture_time * clock_rate) does not have this problem, and I think that if we recommend a formula for the new implementations that still insist on switching clock rates inside the same SSRC, it should be better than the legacy formula. Note also (I missed this in my previous email) that this formula does not seem to prevent the TS to jump backward, as shown in the spreadsheet. > > The jitter values reported in RTCP are rather imprecise to begin with, > since if I remember they're affected by things like duplicate packets. Right, but we should still try to do better than sending pseudo random values if we can. > > Note: I have not reviewed the proposal (though I took part in discussions on > this issue here 3 or 4 years ago) and have no opinion on it currently. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2w9wwACgkQ9RoMZyVa61cobQCfc29VMkfYmnpH/0/hN49/zZ/1 2JcAmwS25MaIa2uZCpeaOduv6gEKIy9l =nxlr -----END PGP SIGNATURE----- From csp@csperkins.org Mon Apr 25 05:02:23 2011 Return-Path: X-Original-To: avtext@ietfc.amsl.com Delivered-To: avtext@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 004F7E073B for ; Mon, 25 Apr 2011 05:02:22 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajzfZVzy0gGo for ; Mon, 25 Apr 2011 05:02:21 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfc.amsl.com (Postfix) with ESMTP id A0D68E06A4 for ; Mon, 25 Apr 2011 05:02:21 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QEKUe-0001Hg-pM; Mon, 25 Apr 2011 12:02:21 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: Date: Mon, 25 Apr 2011 13:02:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A99432E-A1C9-4667-8734-FC278272E722@csperkins.org> References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <7789B55F-FC01-4301-8B6C-4657078DE105@orandom.net> <51BAA831-B4C1-4D60-A4FB-B8A8C85CDCEE@csperkins.org> To: Jinwei Xia X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:02:23 -0000 On 13 Apr 2011, at 14:09, Jinwei Xia wrote: > ----- Original Message -----=20 > From: "Colin Perkins" > To: "David R Oran" > Cc: > Sent: Tuesday, April 12, 2011 4:12 AM > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >=20 >=20 >> On 8 Apr 2011, at 16:43, David R Oran wrote: >>> I tend to agree with Magnus' assessment. >>>=20 >>> There seems also to be an additional (only implicitly stated) = requirement that people need to internalize (at least I think there is = after a number of discussions with the proponents). >>>=20 >>> That is the ability of the translator to have minimal (or zero) = overhead when content is not being actively spliced. I believe the = system model the proponents have in their heads is one in which a system = sitting in the middle of the network somewhere can have many RTP = sessions flowing "through" , or "around" it, and only incur translator = overhead during an actual splice operation, and possibly for a short = period surrounding the splice. In other words, I'm presuming there's a = scalability requirement of the form: "the overhead must scale with the = number of active splices, not with the number of RTP sessions flowing = through the intermediary". >>=20 >> I'm not sure there's any solution for the combination of = non-detectable splicing and zero overhead when not actively splicing (at = least, not without revising RTP). All the solutions I envisage have a = per-stream overhead when not splicing in order to achieve non-detectable = behaviour: they either need to continually rewrite RTP sequence numbers = and RTCP, or act as a mixer and add a CSRC to the stream, and process = RTCP packets. As such, they all scale with the number of RTP streams = flowing through the intermediary.=20 >=20 > Agree, even if we do not support non-detectability, translator or = mixer still needs to rewrite related RTP parameters for main stream = while not actively splicing. More RTP session, more overhead on = translator or mixer. I don't think that's necessarily true. If you require non-detectability, = I believe the splicer will need to rewrite RTP headers while not = actively splicing. If you allow the splicer to be detectable, I think = you can avoid that overhead. This, to me, seems one of the main design = choices. --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Wed Apr 27 00:30:15 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DDEE06D9 for ; Wed, 27 Apr 2011 00:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qyJTqSoK74N for ; Wed, 27 Apr 2011 00:30:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D598E067B for ; Wed, 27 Apr 2011 00:30:13 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-70-4db7c60541e6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 86.FE.28525.506C7BD4; Wed, 27 Apr 2011 09:30:13 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 27 Apr 2011 09:30:12 +0200 Message-ID: <4DB7C604.60508@ericsson.com> Date: Wed, 27 Apr 2011 09:30:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4D8B107E.9000809@ericsson.com> <4D9001DB.3050106@acm.org> <4D903D27.50609@ericsson.com> <4DB076D5.3000501@acm.org> In-Reply-To: <4DB076D5.3000501@acm.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:30:15 -0000 Marc Petit-Huguenin skrev 2011-04-21 20:26: > Hi Magnus, > > Going back to this topic after some vacations. See below. > > On 03/28/2011 12:47 AM, Magnus Westerlund wrote: >> Marc, WG > >> See Inline > >> Marc Petit-Huguenin skrev 2011-03-28 05:34: >>> Hi Magnus, >>> >>> Thanks for the review, and sorry to not responding sooner. >>> >>> On 03/24/2011 10:35 AM, Magnus Westerlund wrote: >>>> Hi, >>>> >>>> This mail is my personal opinions and not as a WG chair. >>>> >>>> I have reviewed the draft and think it is a reasonable starting point >>>> for meeting the WG's milestone. >>>> >>>> However, I do have some technical comments. >>>> > > [...] > >>>> >>>> In my view the method in 2.2.1 is incorrect in one important detail: >>>> >>>> timestamp = previous_timestamp + (current_capture_time - >>>> previous_capture_time) * current_clock_rate >>>> >>>> The "current_clock_rate" should actually be previous clock rate. If one >>>> uses the clock rate from the previous packet to cover the time period up >>>> to a switch then one avoids any discontinuities and the jitter doesn't >>>> make a jump before one knows what the new clock rate is. >>>> >>>> It is also consistent with logical thinking for any media that had >>>> duration. Take for example audio with 20 ms frame lengths, the RTP TS >>>> value for a packet with one frame provides the time at the start of the >>>> frame. Then the frame has a duration of 20 ms, thus resulting in that >>>> the timestamp value of any next frame that are aligned with the current >>>> will be starting at last_TS+0.02*clock_rate. >>>> >>>> Thus resulting in that the formula should read: >>>> timestamp = previous_timestamp + (current_capture_time - >>>> previous_capture_time) * previous_clock_rate >>>> >>>> One also needs to reconsider the arrival formulas to use previous: >>>> (1) current_time_capture = (current_timestamp - previous_timestamp) / >>>> previous_clock_rate + previous_time_capture >>>> (2) transit = previous_clock_rate * (time_arrival - >>>> current_time_capture) >>>> (3) previous_time_capture = current_time_capture >>>> (4) previous_clock_rate = current_clock_rate >>>> >>>> >>>> Using these formulas to update table 2: >>>> >>>> +-------+-------+-----------+---------+---------+--------+----------+ >>>> | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | >>>> | time | rate | timestamp | time | | | jitter | >>>> +-------+-------+-----------+---------+---------+--------+----------+ >>>> | 0 | 8000 | 0 | 0.1 | 800 | | | >>>> | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | >>>> | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | >>>> | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | >>>> | 0.08 | 16000 | 640 | 0.18 | 800 | 0 | 0 | >>>> | 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 | >>>> | 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 | >>>> | 0.14 | 8000 | 1600 | 0.24 | 1600 | 0 | 0 | >>>> | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 | >>>> +-------+-------+-----------+---------+---------+--------+----------+ >>>> >>>> >>>> Which I think avoids all the issues with the jitter etc. >>>> >>>> If a packet loss occur with the first packet with the new rate then >>>> there will be a jitter value here due to the definition of jitter as >>>> using the timestamp values of the older packet part of the calculation. >>>> >>>> >>>> 2. Also I think Section 2.2.2 points to a naive implementation of that >>>> method. As I see it when you do calculations based on that method you >>>> need to use the more expanded formula: >>> >>> A the difference of the formula in 2.2.1 (which is what people actually use)), >>> the formula in 2.2.2 is the one that the I-D tentatively set as the formula for >>> future implementations that does not want to use a different SSRC (more about >>> this below). >>> >>> Now you do not explain why this formula is better than the simpler formula >>> capture_time * clock_rate. See also my response to the next comments. > >> Well, it avoids the jump backwards in TS that you got unless you adjust >> the start point. > > Yes, but - unless my calculations are incorrect - the jitter is still incorrect > with this formula. I created a Google spreadsheet to illustrate this (in > "Magnus proposal" tab): > > https://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdDhwMEhuOEVGdzVDdnNkMlluRGRnb1E&hl=en&authkey=CLaT9oAI > > Please let me know if I missed something. > > >>> >>>> >>>> timestamp = (capture_time-capture_start) * clock_rate + Start_offset >>>> >>>> Then every time you change the rate you need to set new values for >>>> "capture_start" and Start_offset: >>>> >>>> Start_offset = (capture_time_start_of_new_rate-capture_start) >>>> *previous_clock_rate >>>> capture_start = capture_time_start_of_new_rate >>>> > > [...] > To me it appears that the error in the spreadsheet is that you use "capture_start" in cell E7 as D6, instead of D7 as it should be. If you set it to that I think you will get the correct value for the timestap, i.e. 640 in E7. Then the jitter becomes 0. To me E7 should be =(A7-D7)*B7+C7 In other words for this method you need to update the base values Start_offset, and Capture_Start prior to calculating the first timestamp for the new clock rate. This is different from the other method I included in my previous method that first calculates and then updates. In similar fashion there is an error in the cells when switching back. 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 xiajinwei@huawei.com Wed Apr 27 23:43:41 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B03E062A for ; Wed, 27 Apr 2011 23:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=3.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKwtJPy8KkGp for ; Wed, 27 Apr 2011 23:43:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64FE067C for ; Wed, 27 Apr 2011 23:43:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00KDPNYS86@szxga04-in.huawei.com> for avtext@ietf.org; Thu, 28 Apr 2011 14:42:28 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00051NYSN4@szxga04-in.huawei.com> for avtext@ietf.org; Thu, 28 Apr 2011 14:42:28 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Apr 2011 14:42:26 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Apr 2011 14:42:27 +0800 Date: Thu, 28 Apr 2011 14:42:27 +0800 From: Xiajinwei In-reply-to: <6A99432E-A1C9-4667-8734-FC278272E722@csperkins.org> X-Originating-IP: [10.138.41.84] To: 'Colin Perkins' Message-id: <006701cc056f$70b683e0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcwDQMXn/cEOl4PFRZCZfVgZeh9puACLDUuw Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 06:43:41 -0000 Colin, > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, April 25, 2011 8:02 PM > To: Jinwei Xia > Cc: David R Oran; avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > > On 13 Apr 2011, at 14:09, Jinwei Xia wrote: > > ----- Original Message ----- > > From: "Colin Perkins" > > To: "David R Oran" > > Cc: > > Sent: Tuesday, April 12, 2011 4:12 AM > > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 > > > > > >> On 8 Apr 2011, at 16:43, David R Oran wrote: > >>> I tend to agree with Magnus' assessment. > >>> > >>> There seems also to be an additional (only implicitly > stated) requirement that people need to internalize (at least > I think there is after a number of discussions with the proponents). > >>> > >>> That is the ability of the translator to have minimal (or > zero) overhead when content is not being actively spliced. I > believe the system model the proponents have in their heads > is one in which a system sitting in the middle of the network > somewhere can have many RTP sessions flowing "through" , or > "around" it, and only incur translator overhead during an > actual splice operation, and possibly for a short period > surrounding the splice. In other words, I'm presuming there's > a scalability requirement of the form: "the overhead must > scale with the number of active splices, not with the number > of RTP sessions flowing through the intermediary". > >> > >> I'm not sure there's any solution for the combination of > non-detectable splicing and zero overhead when not actively > splicing (at least, not without revising RTP). All the > solutions I envisage have a per-stream overhead when not > splicing in order to achieve non-detectable behaviour: they > either need to continually rewrite RTP sequence numbers and > RTCP, or act as a mixer and add a CSRC to the stream, and > process RTCP packets. As such, they all scale with the number > of RTP streams flowing through the intermediary. > > > > Agree, even if we do not support non-detectability, > translator or mixer still needs to rewrite related RTP > parameters for main stream while not actively splicing. More > RTP session, more overhead on translator or mixer. > > I don't think that's necessarily true. If you require > non-detectability, I believe the splicer will need to rewrite > RTP headers while not actively splicing. If you allow the > splicer to be detectable, I think you can avoid that > overhead. This, to me, seems one of the main design choices. > > If we use mixer in detectability case, IMO the mixer still need to at least rewrite SSRC, SN and CSRC, while not actively splicing unless otherwise is used. Jinwei > -- > Colin Perkins > http://csperkins.org/ > > > From csp@csperkins.org Thu Apr 28 00:55:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885A0E06F1 for ; Thu, 28 Apr 2011 00:55:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Yw+xw7r95e for ; Thu, 28 Apr 2011 00:55:18 -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 06A39E06E8 for ; Thu, 28 Apr 2011 00:55:18 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QFM4D-0006n6-d2; Thu, 28 Apr 2011 07:55:17 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <006701cc056f$70b683e0$54298a0a@china.huawei.com> Date: Thu, 28 Apr 2011 08:55:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C62862A-8318-468E-A4EC-E31A98E21A3B@csperkins.org> References: <006701cc056f$70b683e0$54298a0a@china.huawei.com> To: Xiajinwei X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:55:21 -0000 On 28 Apr 2011, at 07:42, Xiajinwei wrote: >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org]=20 >> Sent: Monday, April 25, 2011 8:02 PM >> To: Jinwei Xia >> Cc: David R Oran; avtext@ietf.org >> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >>=20 >> On 13 Apr 2011, at 14:09, Jinwei Xia wrote: >>> ----- Original Message ----- >>> From: "Colin Perkins" >>> To: "David R Oran" >>> Cc: >>> Sent: Tuesday, April 12, 2011 4:12 AM >>> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >>>=20 >>>=20 >>>> On 8 Apr 2011, at 16:43, David R Oran wrote: >>>>> I tend to agree with Magnus' assessment. >>>>>=20 >>>>> There seems also to be an additional (only implicitly stated) = requirement that people need to internalize (at least I think there is = after a number of discussions with the proponents). >>>>>=20 >>>>> That is the ability of the translator to have minimal (or zero) = overhead when content is not being actively spliced. I believe the = system model the proponents have in their heads is one in which a system = sitting in the middle of the network somewhere can have many RTP = sessions flowing "through" , or "around" it, and only incur translator = overhead during an actual splice operation, and possibly for a short = period surrounding the splice. In other words, I'm presuming there's a = scalability requirement of the form: "the overhead must scale with the = number of active splices, not with the number of RTP sessions flowing = through the intermediary". >>>>=20 >>>> I'm not sure there's any solution for the combination of = non-detectable splicing and zero overhead when not actively splicing (at = least, not without revising RTP). All the solutions I envisage have a = per-stream overhead when not splicing in order to achieve non-detectable = behaviour: they either need to continually rewrite RTP sequence numbers = and RTCP, or act as a mixer and add a CSRC to the stream, and process = RTCP packets. As such, they all scale with the number of RTP streams = flowing through the intermediary.=20 >>>=20 >>> Agree, even if we do not support non-detectability, translator or = mixer still needs to rewrite related RTP parameters for main stream = while not actively splicing. More RTP session, more overhead on = translator or mixer. >>=20 >> I don't think that's necessarily true. If you require = non-detectability, I believe the splicer will need to rewrite RTP = headers while not actively splicing. If you allow the splicer to be = detectable, I think you can avoid that overhead. This, to me, seems one = of the main design choices. >=20 > If we use mixer in detectability case, IMO the mixer still need to at = least rewrite SSRC, SN and CSRC, while not actively splicing unless = otherwise isused. This is one of the reasons why I don't think a mixer is appropriate. --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Thu Apr 28 01:12:45 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4EFE06AF for ; Thu, 28 Apr 2011 01:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhBGK29gNDAV for ; Thu, 28 Apr 2011 01:12:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F17FEE06A6 for ; Thu, 28 Apr 2011 01:12:44 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-b2-4db9217be3f9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.43.28525.B7129BD4; Thu, 28 Apr 2011 10:12:43 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Apr 2011 10:12:43 +0200 Message-ID: <4DB9217B.4000104@ericsson.com> Date: Thu, 28 Apr 2011 10:12:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4D8B107E.9000809@ericsson.com> <4D9001DB.3050106@acm.org> <4D903D27.50609@ericsson.com> <4DB076D5.3000501@acm.org> <4DB7C604.60508@ericsson.com> In-Reply-To: <4DB7C604.60508@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-petithuguenin-avtext-multiple-clock-rates-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:12:46 -0000 Hi, Marc give me the rights to update his spreadsheet and I have figured out why he gotten spikes even after the update for the jitter. It has to do with the calculation of the jitter previously in the spread sheet. So the Section 2.2.2 formula proposal by me (clarified): timestamp = (capture_time-capture_start) * clock_rate + Start_offset Then every time you change the rate you need to set new values for "capture_start" and Start_offset prior to calculating the new rates timestamp value: Start_offset = (capture_time_start_of_new_rate-capture_start) *previous_clock_rate capture_start = capture_time_start_of_new_rate When it comes to jitter calculation I find that the calculation will become all 0 over a rate switch as long as one use the following version of the RFC 3550 interarrival formula D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) What is not specified in the RFC 3550 on this matter is the need for deriving Ri and Rj using the same clock rate and that clock rate to be the one of the older packet. The reason one needs to use the older rate is due to the packet duration aspect. I will note that if one loses the first packet for a new rate, there will be jitter values as the receiver will consider the timestamp different and the clock rate as all being according to the old one, when in fact it is one old and one new duration present in the interval. Thus I use in the spread sheet the calculation that is: ABS((Arrival_Time_i*Previous_clock_rate-timestamp_i)-(Previous_Arrival_Time*Previous_clock_rate-previous_timestamp) Where previous is the value for last prior received packets in this flow. I also applied this jitter calculation to the non-monotomic and legacy proposals to see what happens. I also verified my proposal for 2.2.1 and that also appears to be valid. 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 ----------------------------------------------------------------------