From harald@alvestrand.no Sat Feb 2 17:29:00 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129BA21F853E for ; Sat, 2 Feb 2013 17:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.381 X-Spam-Level: X-Spam-Status: No, score=-110.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 o9EdCQuLmrl6 for ; Sat, 2 Feb 2013 17:28:59 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9421F853C for ; Sat, 2 Feb 2013 17:28:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0D7639E151; Sun, 3 Feb 2013 02:28:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAAlplT8XslL; Sun, 3 Feb 2013 02:28:55 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1] (unknown [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7D77B39E070; Sun, 3 Feb 2013 02:28:55 +0100 (CET) Message-ID: <510DBD56.9090903@alvestrand.no> Date: Sun, 03 Feb 2013 02:28:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.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: Sun, 03 Feb 2013 01:29:00 -0000 I think I spotted two spelling mistakes: - Section 1: "During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media." This makes more sense to me if "syntactic" is replaced with "synthetic". - Section 3: "For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause." This makes more sense to me if "if it is used" is replaced by "if it is not being used". If I misunderstood the document, please holler! Content issues: - If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will interact with it. How and where should that interaction be described - in particular, after a pause (TMMBR=0), what value should the receiver use in the resume (TMMBR=N) message? - If muted / not rendered is unimportant enough that nobody's offered token text to drag in here, perhaps we should remove the sections? Conversely, if it is important, can someone suggest text? Harald On 01/24/2013 07:59 PM, Roni Even wrote: > Hi, > I resubmitted the draft since I noticed I did not have avtext in the draft name and it appeared as https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ > > Roni Even > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Thursday, January 24, 2013 8:56 PM > To: Roni Even > Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt > > A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt > has been successfully submitted by Roni Even and posted to the > IETF repository. > > Filename: draft-even-avtext-flow-control-to-zero > Revision: 00 > Title: Pausing an RTP Media Stream > Creation date: 2013-01-24 > WG ID: Individual Submission > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-00.txt > Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero > Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 > > > Abstract: > In Real-time multimedia applications using multiple media streams in > point to point and multipoint calls can benefit from options that > will enable them to pause and resume media streams as well as to > indicate a mute state. This document describes the difference > between pause and mute and describes how to provide this required > functionality. This document updates RFC5104. > > > > > The IETF Secretariat > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From bo.burman@ericsson.com Mon Feb 18 06:13:29 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29E821F8910 for ; Mon, 18 Feb 2013 06:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd457YqopsbF for ; Mon, 18 Feb 2013 06:13:29 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D085521F88CF for ; Mon, 18 Feb 2013 06:13:28 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-47-51223707f0ce Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 25.62.32353.70732215; Mon, 18 Feb 2013 15:13:28 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 15:13:27 +0100 From: Bo Burman To: Harald Alvestrand , Roni Even Thread-Topic: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Thread-Index: AQHN+mR/mWtP1OdQVU24n9ixJvzG65hY1FljgA6BwgCAGHghcA== Date: Mon, 18 Feb 2013 14:13:26 +0000 Message-ID: References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> <510DBD56.9090903@alvestrand.no> In-Reply-To: <510DBD56.9090903@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS6HuVKgweVAi4/3brBaHOvrYrN4 0vKD2YHZ48qEK6weS5b8ZPLYsfkBawBzFJdNSmpOZllqkb5dAlfG9Bn9rAVdshUbH09jbWDc JN7FyMkhIWAisffXe1YIW0ziwr31bF2MXBxCAocYJeYu3MwM4SxhlFi+uRmsik1AQ2L+jruM ILaIQLjE85P7wWxmAXWJw/uWgNnCAmkS62d2skHUpEssmtnG1MXIAWQ7SfxtFQAJswioSlyZ 3MUOEuYV8JVYuTEEYtVGRonFp86BtXIK6Eocaf8IZjMKyErc/36PBWKVuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1aQmRICihLL++UgynUkFuz+xAZha0ssW/garJxXQFDi5MwnLBMYxWYhmToL ScssJC2zkLQsYGRZxciem5iZk15uvokRGDMHt/w22MG46b7YIUZpDhYlcd5w1wsBQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhjP8X336RR4qeqy9EiV9aSiD9w/Uyaffj995ifL/PWsBn94 V7CtaZzIV924tfn6er2OcF6TgvhTBxt3MVovWFU043FNXL27yLR/r3mvqkx0TUx3VfjDLLFy W2GIS6BlEIf84wUpE3WSrAUsZ3/N2bFMmjmQ+8yTIpPTH812739oH7tl3q7tFilKLMUZiYZa zEXFiQCKVumFZwIAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:13:30 -0000 Hi, Regarding the anticipated spelling error in section 3, I believe the origin= al text to be correct. This is in fact a potential problem with TMMBR seman= tics being used as pause, since any sender of TMMBR 0 will unconditionally = pause the stream also for other listeners to that stream, if any. Cheers, Bo -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Sunday, February 03, 2013 2:29 AM To: Roni Even Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-fl= ow-control-to-zero-00.txt I think I spotted two spelling mistakes: - Section 1: "During a point to point or multipoint call a sender may mute = his microphone or camera but still continue to send media which may be some= syntactic media." This makes more sense to me if "syntactic" is replaced w= ith "synthetic". - Section 3: "For the pause request using TMMBR with bit rate "0" will make= an RTP media sender stop sending an RTP stream if it is used by others tha= t have not requested a pause." This makes more sense to me if "if it is use= d" is replaced by "if it is not being used". If I misunderstood the document, please holler! Content issues: - If TMMBR is used as a congestion control signal mechanism, TMMBR=3D0 will= interact with it. How and where should that interaction be described - in = particular, after a pause (TMMBR=3D0), what value should the receiver use i= n the resume (TMMBR=3DN) message? - If muted / not rendered is unimportant enough that nobody's offered token= text to drag in here, perhaps we should remove the sections?=20 Conversely, if it is important, can someone suggest text? Harald On 01/24/2013 07:59 PM, Roni Even wrote: > Hi, > I resubmitted the draft since I noticed I did not have avtext in the=20 > draft name and it appeared as=20 > https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ > > Roni Even > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Thursday, January 24, 2013 8:56 PM > To: Roni Even > Subject: New Version Notification for draft-even-avtext-flow-control-to= -zero-00.txt > > A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt > has been successfully submitted by Roni Even and posted to the IETF=20 > repository. > > Filename: draft-even-avtext-flow-control-to-zero > Revision: 00 > Title: Pausing an RTP Media Stream > Creation date: 2013-01-24 > WG ID: Individual Submission > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-even-avtext-fl= ow-control-to-zero-00.txt > Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-c= ontrol-to-zero > Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-contro= l-to-zero-00 > > > Abstract: > In Real-time multimedia applications using multiple media streams in > point to point and multipoint calls can benefit from options that > will enable them to pause and resume media streams as well as to > indicate a mute state. This document describes the difference > between pause and mute and describes how to provide this required > functionality. This document updates RFC5104. > > > > > The IETF Secretariat > _______________________________________________ > 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 harald@alvestrand.no Mon Feb 18 06:43:34 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFE421F896B for ; Mon, 18 Feb 2013 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.378 X-Spam-Level: X-Spam-Status: No, score=-110.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 f6qMZOrlbX43 for ; Mon, 18 Feb 2013 06:43:33 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF4221F8958 for ; Mon, 18 Feb 2013 06:43:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 406F939E0F3; Mon, 18 Feb 2013 15:43:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKXSbuFuZawy; Mon, 18 Feb 2013 15:43:29 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A968939E0E1; Mon, 18 Feb 2013 15:43:29 +0100 (CET) Message-ID: <51223E10.6020002@alvestrand.no> Date: Mon, 18 Feb 2013 15:43:28 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bo Burman References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> <510DBD56.9090903@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:43:34 -0000 On 02/18/2013 03:13 PM, Bo Burman wrote: > Hi, > > Regarding the anticipated spelling error in section 3, I believe the original text to be correct. This is in fact a potential problem with TMMBR semantics being used as pause, since any sender of TMMBR 0 will unconditionally pause the stream also for other listeners to that stream, if any. Thanks - after reading section 3.5.4.2 of RFC 5104, I agree that this will be the result. I believe a better formulation will then be "... will make an RTP media sender stop sending an RTP stream. This will happen even if it used by others that have not requested a pause." > > Cheers, > Bo > > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Sunday, February 03, 2013 2:29 AM > To: Roni Even > Cc: avtext@ietf.org > Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt > > I think I spotted two spelling mistakes: > > - Section 1: "During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media." This makes more sense to me if "syntactic" is replaced with "synthetic". > > - Section 3: "For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause." This makes more sense to me if "if it is used" is replaced by "if it is not being used". > > If I misunderstood the document, please holler! > > Content issues: > > - If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will interact with it. How and where should that interaction be described - in particular, after a pause (TMMBR=0), what value should the receiver use in the resume (TMMBR=N) message? > > - If muted / not rendered is unimportant enough that nobody's offered token text to drag in here, perhaps we should remove the sections? > Conversely, if it is important, can someone suggest text? > > Harald > > > On 01/24/2013 07:59 PM, Roni Even wrote: >> Hi, >> I resubmitted the draft since I noticed I did not have avtext in the >> draft name and it appeared as >> https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ >> >> Roni Even >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Thursday, January 24, 2013 8:56 PM >> To: Roni Even >> Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt >> >> A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt >> has been successfully submitted by Roni Even and posted to the IETF >> repository. >> >> Filename: draft-even-avtext-flow-control-to-zero >> Revision: 00 >> Title: Pausing an RTP Media Stream >> Creation date: 2013-01-24 >> WG ID: Individual Submission >> Number of pages: 5 >> URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-00.txt >> Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero >> Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 >> >> >> Abstract: >> In Real-time multimedia applications using multiple media streams in >> point to point and multipoint calls can benefit from options that >> will enable them to pause and resume media streams as well as to >> indicate a mute state. This document describes the difference >> between pause and mute and describes how to provide this required >> functionality. This document updates RFC5104. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 ron.even.tlv@gmail.com Mon Feb 18 07:25:39 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1629121F87C3 for ; Mon, 18 Feb 2013 07:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 3+r1WsuW3b0S for ; Mon, 18 Feb 2013 07:25:38 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id BC6DC21F87D4 for ; Mon, 18 Feb 2013 07:25:37 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so2885135eek.14 for ; Mon, 18 Feb 2013 07:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=H6S0p8unnCRCSL/agwN0lDvzPZj8MRiKdNjtV5xkX8M=; b=j7wFLXFvoMecUT7Xuy/Mr/qhDzlUz61RFbfX0DEL2lJ/akFY3G9DjcDU1E2NiRji6x EGG5FYfxAHBE89hOCgsVl+vjezlnfWTloZ0+561sTVnmYZSWSsNq2kegh4jo3yg4pdmg Cq33r9iy90OHtnwpxBd9JmZQvlXKkt/yBUpAKfKkd3VyB1Eu04yA4RjndjjVP7vdY5X6 SL6Rhy77LiV8G8RLqmQv/JomvyqxSlWKbrdRCGtGJVDEuE/VT0WUbOtN4F6MZWm3UJ64 eqfjEt6OxXqb7Bt7oy6DovAONBs1u5TZjcRxcnxlpd0BAUPIybCKU388bwCkUwhhRa6Q sDuw== X-Received: by 10.14.210.132 with SMTP id u4mr45632648eeo.19.1361201136862; Mon, 18 Feb 2013 07:25:36 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id q5sm99107250eeo.17.2013.02.18.07.25.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Feb 2013 07:25:35 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , "'Bo Burman'" References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> <510DBD56.9090903@alvestrand.no> <51223E10.6020002@alvestrand.no> In-Reply-To: <51223E10.6020002@alvestrand.no> Date: Mon, 18 Feb 2013 17:22:25 +0200 Message-ID: <005c01ce0deb$c3aa5a00$4aff0e00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8NEVLBu379Wznpiznmyr9iEDvkQIcJAzNAahopeIBJ2M8bAMQSg8Il2OI4CA= Content-Language: en-us Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:25:39 -0000 Hi Harald, I will fix the typo in section 1 and can use your text in section 3. About " muted / not rendered", H.32x video conferring systems indicate to the user if they are being currently seen by others. I raised this as part of the complete application usage and if there will be interest I can add text. As for congestion usage of TMMBR, RFC5104 says that TMMBR is not a congestion control mechanism and it does not discuss the change to higher rate based on change in the congestion state of the network. Roni Even -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 18 February, 2013 4:43 PM To: Bo Burman Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt On 02/18/2013 03:13 PM, Bo Burman wrote: > Hi, > > Regarding the anticipated spelling error in section 3, I believe the original text to be correct. This is in fact a potential problem with TMMBR semantics being used as pause, since any sender of TMMBR 0 will unconditionally pause the stream also for other listeners to that stream, if any. Thanks - after reading section 3.5.4.2 of RFC 5104, I agree that this will be the result. I believe a better formulation will then be "... will make an RTP media sender stop sending an RTP stream. This will happen even if it used by others that have not requested a pause." > > Cheers, > Bo > > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Sunday, February 03, 2013 2:29 AM > To: Roni Even > Cc: avtext@ietf.org > Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt > > I think I spotted two spelling mistakes: > > - Section 1: "During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media." This makes more sense to me if "syntactic" is replaced with "synthetic". > > - Section 3: "For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause." This makes more sense to me if "if it is used" is replaced by "if it is not being used". > > If I misunderstood the document, please holler! > > Content issues: > > - If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will interact with it. How and where should that interaction be described - in particular, after a pause (TMMBR=0), what value should the receiver use in the resume (TMMBR=N) message? > > - If muted / not rendered is unimportant enough that nobody's offered token text to drag in here, perhaps we should remove the sections? > Conversely, if it is important, can someone suggest text? > > Harald > > > On 01/24/2013 07:59 PM, Roni Even wrote: >> Hi, >> I resubmitted the draft since I noticed I did not have avtext in the >> draft name and it appeared as >> https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ >> >> Roni Even >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Thursday, January 24, 2013 8:56 PM >> To: Roni Even >> Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt >> >> A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt >> has been successfully submitted by Roni Even and posted to the IETF >> repository. >> >> Filename: draft-even-avtext-flow-control-to-zero >> Revision: 00 >> Title: Pausing an RTP Media Stream >> Creation date: 2013-01-24 >> WG ID: Individual Submission >> Number of pages: 5 >> URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-0 0.txt >> Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero >> Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 >> >> >> Abstract: >> In Real-time multimedia applications using multiple media streams in >> point to point and multipoint calls can benefit from options that >> will enable them to pause and resume media streams as well as to >> indicate a mute state. This document describes the difference >> between pause and mute and describes how to provide this required >> functionality. This document updates RFC5104. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 From ron.even.tlv@gmail.com Mon Feb 18 07:32:51 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8C121F8955 for ; Mon, 18 Feb 2013 07:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vw9-HS44cEYO for ; Mon, 18 Feb 2013 07:32:50 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB121F893D for ; Mon, 18 Feb 2013 07:32:49 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so2375948eaa.4 for ; Mon, 18 Feb 2013 07:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=pTTlS35e917kyMlqFXjlX0fNNBp3Oge1Q+z8KRKf/xo=; b=MEt3wFhikUSXPvFGsnnd8xsCik/bHbfl3Gum7eRviI6Rcp3GR2GcSi9YyKDo9qUo0t mH5YvyPqEB6hAxxNSjmq7cfzHMhzEumvOxHvicoZdeaS0g2HLhO9PDqLoIt34YquVHkv KN/Ag/IDPZK3MMPcusOjwaR461AWzlawJhMihHk8CJ9L9sRvQGzSuAvlIgMGRhrXuslO W1WpI3H2+WY2PqOcJ1xElpLiJjkiQ/9asxXofEyfk+uxWyvOu8umR+ZADbJDljtw5rch AuljoW3sk9IeLjeBj4OyRH529QYQr9l0RN1TGXDtuFbe4s7PufVfDmPjZU5T9TzbtA3K GE7A== X-Received: by 10.14.183.67 with SMTP id p43mr45784045eem.10.1361201569087; Mon, 18 Feb 2013 07:32:49 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id r4sm54668104eeo.12.2013.02.18.07.32.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Feb 2013 07:32:48 -0800 (PST) From: "Roni Even" To: "'Bo Burman'" , "'Harald Alvestrand'" , "'Roni Even'" References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> <510DBD56.9090903@alvestrand.no> In-Reply-To: Date: Mon, 18 Feb 2013 17:29:38 +0200 Message-ID: <005d01ce0dec$c57a1b80$506e5280$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8NEVLBu379Wznpiznmyr9iEDvkQIcJAzNAahopeIBJ2M8bJd8D4gg Content-Language: en-us Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:32:51 -0000 Hi Bo, My understanding of the initial algorithm in 3.5.4.2 of RFC 5104 is that if max total BR is 0 in the TMMBR message this is what will happen in point to point and the centralized multipoint cases Roni -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: 18 February, 2013 4:13 PM To: Harald Alvestrand; Roni Even Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Hi, Regarding the anticipated spelling error in section 3, I believe the original text to be correct. This is in fact a potential problem with TMMBR semantics being used as pause, since any sender of TMMBR 0 will unconditionally pause the stream also for other listeners to that stream, if any. Cheers, Bo -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Sunday, February 03, 2013 2:29 AM To: Roni Even Cc: avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt I think I spotted two spelling mistakes: - Section 1: "During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media." This makes more sense to me if "syntactic" is replaced with "synthetic". - Section 3: "For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause." This makes more sense to me if "if it is used" is replaced by "if it is not being used". If I misunderstood the document, please holler! Content issues: - If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will interact with it. How and where should that interaction be described - in particular, after a pause (TMMBR=0), what value should the receiver use in the resume (TMMBR=N) message? - If muted / not rendered is unimportant enough that nobody's offered token text to drag in here, perhaps we should remove the sections? Conversely, if it is important, can someone suggest text? Harald On 01/24/2013 07:59 PM, Roni Even wrote: > Hi, > I resubmitted the draft since I noticed I did not have avtext in the > draft name and it appeared as > https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ > > Roni Even > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Thursday, January 24, 2013 8:56 PM > To: Roni Even > Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt > > A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt > has been successfully submitted by Roni Even and posted to the IETF > repository. > > Filename: draft-even-avtext-flow-control-to-zero > Revision: 00 > Title: Pausing an RTP Media Stream > Creation date: 2013-01-24 > WG ID: Individual Submission > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-0 0.txt > Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero > Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 > > > Abstract: > In Real-time multimedia applications using multiple media streams in > point to point and multipoint calls can benefit from options that > will enable them to pause and resume media streams as well as to > indicate a mute state. This document describes the difference > between pause and mute and describes how to provide this required > functionality. This document updates RFC5104. > > > > > The IETF Secretariat > _______________________________________________ > 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 From jonathan@vidyo.com Mon Feb 18 15:01:30 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3021E8040 for ; Mon, 18 Feb 2013 15:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] 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 rgWGZq4VOStv for ; Mon, 18 Feb 2013 15:01:29 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9E90F21E8044 for ; Mon, 18 Feb 2013 15:01:29 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 35101556F41 for ; Mon, 18 Feb 2013 18:01:29 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EFF3A556F47 for ; Mon, 18 Feb 2013 18:01:23 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 18 Feb 2013 18:01:18 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Date: Mon, 18 Feb 2013 18:01:23 -0500 Thread-Topic: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt Thread-Index: Ac4OK9y9MWgXdT5PReeZyJhHFo4iOA== Message-ID: <07F601D3-34F0-4301-8713-DCB7310019D8@vidyo.com> References: <20130218225026.23440.63200.idtracker@ietfa.amsl.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 Subject: [avtext] Fwd: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 23:01:30 -0000 Hello, all -- At the AVTExt meeting at the Atlanta IETF, a group of us got together to di= scuss the various mechanisms by which RTP sources can be grouped together a= t the IETF, and to try to come up with a common framework and terminology f= or discussing such issues. This is an initial result of that effort. It's still very rough, but hopef= ully can serve as a starting point for future discussion and refinement. Comments are welcome. Since the document applies to work ongoing in many R= AI-area working groups (certainly including MMUSIC, CLUE, and RTCWEB) I've = titled it "raiarea"; but I think keeping discussion on the AVTExt mailing l= ist for now probably makes the most sense. Begin forwarded message: > From: "internet-drafts@ietf.org" > Subject: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt > Date: February 18, 2013 5:50:26 PM EST > To: "i-d-announce@ietf.org" > Reply-To: "internet-drafts@ietf.org" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : A Taxonomy of Grouping Semantics and Mechanisms for Re= al-Time Transport Protocol (RTP) Sources > Author(s) : Jonathan Lennox > Kevin Gross > Filename : draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt > Pages : 13 > Date : 2013-02-18 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. >=20 > This document is still very rough, but is submitted in the hopes of > making future discussion productive. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxono= my >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From bo.burman@ericsson.com Wed Feb 20 05:26:40 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1933621F873C for ; Wed, 20 Feb 2013 05:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKc7PXC9yWhi for ; Wed, 20 Feb 2013 05:26:39 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B09F421F871F for ; Wed, 20 Feb 2013 05:26:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-e5-5124cf0d9d41 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F5.96.10459.D0FC4215; Wed, 20 Feb 2013 14:26:37 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 14:26:37 +0100 From: Bo Burman To: Roni Even , "avtext@ietf.org" Thread-Topic: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Thread-Index: AQHN+mR/mWtP1OdQVU24n9ixJvzG65hY1FljgCb78+A= Date: Wed, 20 Feb 2013 13:26:36 +0000 Message-ID: References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjS7veZVAg5Oz9Cw+3rvBavGk5Qez A5PHkiU/mTx2bH7AGsAUxWWTkpqTWZZapG+XwJXx8+VmxoL5shWLVj5kbGC8JN7FyMkhIWAi ceTrTyYIW0ziwr31bF2MXBxCAocYJXZc3skM4SxhlNj3YwVYFZuAhsT8HXcZQWwRgSCJnpWb WEBsYYE0ifUzO9kg4ukSi2a2MUHYVhLb781kB7FZBFQl3q38A9bLK+Ar8XXKDahtfYwSXyd8 ZAZJcAqES8z9t4kVxGYUkJW4//0e2AJmAXGJW0/mQ50qILFkz3lmCFtU4uXjf0D1HEC2osTy fjmIcj2JG1OnsEHY2hLLFr5mhtgrKHFy5hOWCYyis5BMnYWkZRaSlllIWhYwsqxiZM9NzMxJ LzfcxAiMhoNbfuvuYDx1TuQQozQHi5I4b5jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jGwnb3Feni9a9zPZpjpnbr/YzdaQn8LMwo9WF8oEbjb98+HflR8TNdMSwq7bXJvtYeypnTtz cwVDXnJcZYNNMaNslnDd9+ehc78f89ilFX46eu9Gwdc6aho+9bPe67qnSK7k+vj+hfgp6wW/ kmbyss4o3uzAu4briGq7+s6yvEbdotuqDRVuSizFGYmGWsxFxYkAKqUcYlQCAAA= Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.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: Wed, 20 Feb 2013 13:26:40 -0000 Hi Roni, Here are a few comments from me: * I agree that TMMBR 0 can be used as "PAUSE" in the point-to-point case, but I would like to see a description of how a media sender can know that it is a point-to-point session, alternatively how it may learn that it is not and how it should react in that case * You say that the major reason that TMMBR has a delay on rate increase is that it may go above SDP "b" attribute. I don't believe this is correct. See for example RFC 5104 section 3.5.4 "The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling". The same section also clearly states the reason for the delay: "This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower", taking into account that the raised value could be too high for another media receiver that did not yet send any TMMBR because it was happy with the previous one, and the raised value would exceed its limit. If this other media receiver is not given sufficient time to be pro-active and set an acceptable new limit before actually increasing the bitrate, the increased bitrate could cause problems until a new TMMBR limit is established Cheers, Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- =20 -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Roni Even Sent: Thursday, January 24, 2013 7:59 PM To: avtext@ietf.org Subject: [avtext] FW: New Version Notification for draft-even-avtext-flow-c= ontrol-to-zero-00.txt Hi, I resubmitted the draft since I noticed I did not have avtext in the draft = name and it appeared as https://datatracker.ietf.org/doc/draft-even-flow-co= ntrol-to-zero/ Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Thursday, January 24, 2013 8:56 PM To: Roni Even Subject: New Version Notification for draft-even-avtext-flow-control-to-z= ero-00.txt A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt has been successfully submitted by Roni Even and posted to the IETF reposit= ory. Filename: draft-even-avtext-flow-control-to-zero Revision: 00 Title: Pausing an RTP Media Stream Creation date: 2013-01-24 WG ID: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow= -control-to-zero-00.txt Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-con= trol-to-zero Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-= to-zero-00 Abstract: In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. The IETF Secretariat _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From ron.even.tlv@gmail.com Wed Feb 20 06:54:27 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06E21F8726 for ; Wed, 20 Feb 2013 06:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2ts-kSTNTwND for ; Wed, 20 Feb 2013 06:54:26 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id F079C21F8802 for ; Wed, 20 Feb 2013 06:54:25 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so4307776eek.16 for ; Wed, 20 Feb 2013 06:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=ZBu5D0rn0m560vOjoNA2QflA+aZmLHJ4YIQ20tzgRTA=; b=cWYstd9c+SS6pIg0N0cLBS7ElQMucpzgLF13R9B6LeT1C5Ogf6IoRm1CJ3vO5WYCMA k2i5Dlw20lXbcN+NXCsbcOMFkQGheHDTXa3f9UL2SHQiFEizABQPeayHf1/dxxmyRUlx ZJRAfY4ftUADVGtjpj6vC5hhI9UwXFI0fmpQHkgo1ZWMBYz2W2LpMi9j/s6huNcLNAHH u5KLwk+Pe2MVM+gTG7cplz4IcgqbE3Jvk+xhC7F7Zox10RiAH9GkLoHglmU7JZm7bGUC gHQe1ygLcMwr+c/nMe+geISyFiivh2mCR6lc4e+ZATfe4HNOUo+WusFTICxbgvL2Q5GM XEjw== X-Received: by 10.14.184.68 with SMTP id r44mr69340073eem.40.1361372065117; Wed, 20 Feb 2013 06:54:25 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id o3sm109764424eem.15.2013.02.20.06.54.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:54:24 -0800 (PST) From: "Roni Even" To: "'Bo Burman'" , "'Roni Even'" , References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Date: Wed, 20 Feb 2013 16:51:14 +0200 Message-ID: <025a01ce0f79$bd084ba0$3718e2e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8NEVLBu379Wznpiznmyr9iEDvkQIcJAzNAeLA4n6XhpKQAA== Content-Language: en-us Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.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: Wed, 20 Feb 2013 14:54:27 -0000 Hi Bo, All these problems are not relevant in point to point and centralized multipoint. I am not sure what you mean by knowing. If the EP is not in = a broadcast/multicast session.=20 In unicast the other side may be an endpoint which is clear from the = RTCP receiver report and the received streams. In the multipoint case this is = up to the central MCU to decide what is the behavior and the MCU knows what = is the connection Roni -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf = Of Bo Burman Sent: 20 February, 2013 3:27 PM To: Roni Even; avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Hi Roni, Here are a few comments from me: * I agree that TMMBR 0 can be used as "PAUSE" in the point-to-point case, but I would like to see a description of how a media sender can know that it is a point-to-point session, alternatively how it may learn that it is not and how it should react in that case * You say that the major reason that TMMBR has a delay on rate increase is that it may go above SDP "b" attribute. I don't believe this is correct. See for example RFC 5104 section 3.5.4 "The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling". The same section also clearly states the reason for the delay: "This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower", taking into account that the raised value could be too high for another media receiver that did not yet send any TMMBR because it was happy with the previous one, and the raised value would exceed its limit. If this other media receiver is not given sufficient time to be pro-active and set an acceptable new limit before actually increasing the bitrate, the increased bitrate could cause problems until a new TMMBR limit is established Cheers, Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- =20 -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf = Of Roni Even Sent: Thursday, January 24, 2013 7:59 PM To: avtext@ietf.org Subject: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Hi, I resubmitted the draft since I noticed I did not have avtext in the = draft name and it appeared as https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/ Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Thursday, January 24, 2013 8:56 PM To: Roni Even Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-avtext-flow-control-to-zero Revision: 00 Title: Pausing an RTP Media Stream Creation date: 2013-01-24 WG ID: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zer= o-0 0.txt Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 Abstract: In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. The IETF Secretariat _______________________________________________ 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 jonathan@vidyo.com Sat Feb 23 09:51:20 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610C21F8B8F for ; Sat, 23 Feb 2013 09:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] 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 RPI5yIrNUoWJ for ; Sat, 23 Feb 2013 09:51:20 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFAB21F88E2 for ; Sat, 23 Feb 2013 09:51:12 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 95DC18BE474 for ; Sat, 23 Feb 2013 12:51:11 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 0B2038BE449 for ; Sat, 23 Feb 2013 12:51:08 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Sat, 23 Feb 2013 12:51:01 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Date: Sat, 23 Feb 2013 12:51:09 -0500 Thread-Topic: AVTExt session in Orlando Thread-Index: Ac4R7lg6iFRHnXiTRMKWlNWBv/MfbQ== Message-ID: <7273A3AA-8D22-4D34-BA77-E2007C350B88@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] AVTExt session in Orlando 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: Sat, 23 Feb 2013 17:51:20 -0000 AVTExt will have one session in Orlando: FRIDAY, March 15, 2013 0900-1100 Friday Morning Session I Caribbean 3 RAI avtext=09 Audio/Video Transport Extensions=20 Combined with MMUSIC Please send the WG chairs requests for agenda time (if you have not already= done so). -- Jonathan Lennox jonathan@vidyo.com From bo.burman@ericsson.com Wed Feb 27 05:31:47 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19521F8602 for ; Wed, 27 Feb 2013 05:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOXkOTeDL19U for ; Wed, 27 Feb 2013 05:31:46 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1A21F8611 for ; Wed, 27 Feb 2013 05:31:45 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-e8-512e0abce4a2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.0B.19728.CBA0E215; Wed, 27 Feb 2013 14:31:40 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 14:31:39 +0100 From: Bo Burman To: Roni Even , 'Roni Even' , "avtext@ietf.org" Thread-Topic: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt Thread-Index: AQHOD23tmn93lLNHnkKGVHirYO4tS5iCw9YAgArzoNA= Date: Wed, 27 Feb 2013 13:31:39 +0000 Message-ID: References: <20130124185618.30213.93095.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E0F0@szxpml504-mbx.exmail.huawei.com> <025a01ce0f79$bd084ba0$3718e2e0$@gmail.com> In-Reply-To: <025a01ce0f79$bd084ba0$3718e2e0$@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje4eLr1AgxnvhC0+3rvBavG3ndni ScsPZgdmj52z7rJ7LFnyk8ljx+YHrAHMUVw2Kak5mWWpRfp2CVwZe7avZCx4blAx68kh9gbG 0+pdjJwcEgImEt8W72KHsMUkLtxbz9bFyMUhJHCIUeLW6o1gCSGBJYwSv25JgdhsAhoS83fc Zexi5OAQEaiQOHm7CiQsLJAmMWtuGyOILSKQLvFy8kdmCNtKonX5Y1aQchYBVYnVd1hAwrwC vhLnjs5khljVwCTR8WUxWC+ngIXExucfmEBsRgFZifvf74E1MAuIS9x6Mp8J4k4BiSV7zjND 2KISLx//A5svIaAosbxfDqJcT+LG1ClsELa2xLKFr5kh9gpKnJz5hGUCo+gsJFNnIWmZhaRl FpKWBYwsqxjZcxMzc9LLjTYxAiPj4JbfqjsY75wTOcQozcGiJM4b7nohQEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjb8b/RI/l/WzbJ/s/2y/l2dS1M9//+6NDzGJfFsuv/lab8l/fpXpf qZjoK0PleOk780/ovLly866C7Yt9ESUP/j0P3LLt5TnuCJ7Jk147rpkqx1pzR8r8lUi4kNnU elcWcaltH/flZRrLng5MzrBYV3ZOPfa9fNXDNSxL/7T5h7TsUeYOiNujxFKckWioxVxUnAgA R7YlOFoCAAA= Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.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: Wed, 27 Feb 2013 13:31:47 -0000 Hi Roni, Will it always be entirely clear to an endpoint that it is sending media to= only a single receiver, and that an immediate response to TMMBR >0 is thus= OK? I can at least see two different cases where it is not sufficient for the m= edia sender to rely on RTCP reporting only: 1. An RTP Transport Translator is used between the media sender and a set of receivers. From an RTCP reporting perspective, the media sender cannot distinguish RTCP reports from this set of separate receivers (with separate reporting SSRC) from a single receiver with several listening and thus reporting SSRC. The media sender thus cannot safely assume that it is a point-to-point session. 2. A Source Projecting Mixer is used between the media sender and a set of receivers. This is not that different from the above, only that the source SSRC seen by the media sender in the RTCP reports are the Mixer's own. There are however, to the media sender, apparently several receiving SSRC even if the link between the media sender and the Source Projecting Mixer is in fact point-to-point. The media sender thus needs some other indication that it is really sending= to a single media receiver and that immediate increase of bitrate based on= a TMMBR >0 is OK. You do not suggest any such mechanism in your draft. Cheers, Bo -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Wednesday, February 20, 2013 3:51 PM To: Bo Burman; 'Roni Even'; avtext@ietf.org Subject: RE: [avtext] FW: New Version Notification for draft-even-avtext-fl= ow-control-to-zero-00.txt Hi Bo, All these problems are not relevant in point to point and centralized multi= point. I am not sure what you mean by knowing. If the EP is not in a broadc= ast/multicast session.=20 In unicast the other side may be an endpoint which is clear from the RTCP r= eceiver report and the received streams. In the multipoint case this is up = to the central MCU to decide what is the behavior and the MCU knows what is= the connection Roni -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Bo Burman Sent: 20 February, 2013 3:27 PM To: Roni Even; avtext@ietf.org Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-fl= ow-control-to-zero-00.txt Hi Roni, Here are a few comments from me: * I agree that TMMBR 0 can be used as "PAUSE" in the point-to-point case, but I would like to see a description of how a media sender can know that it is a point-to-point session, alternatively how it may learn that it is not and how it should react in that case * You say that the major reason that TMMBR has a delay on rate increase is that it may go above SDP "b" attribute. I don't believe this is correct. See for example RFC 5104 section 3.5.4 "The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling". The same section also clearly states the reason for the delay: "This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower", taking into account that the raised value could be too high for another media receiver that did not yet send any TMMBR because it was happy with the previous one, and the raised value would exceed its limit. If this other media receiver is not given sufficient time to be pro-active and set an acceptable new limit before actually increasing the bitrate, the increased bitrate could cause problems until a new TMMBR limit is established Cheers, Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- =20 -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Roni Even Sent: Thursday, January 24, 2013 7:59 PM To: avtext@ietf.org Subject: [avtext] FW: New Version Notification for draft-even-avtext-flow-c= ontrol-to-zero-00.txt Hi, I resubmitted the draft since I noticed I did not have avtext in the draft = name and it appeared as https://datatracker.ietf.org/doc/draft-even-flow-co= ntrol-to-zero/ Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Thursday, January 24, 2013 8:56 PM To: Roni Even Subject: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt has been successfully submitted by Roni Even and posted to the IETF reposit= ory. Filename: draft-even-avtext-flow-control-to-zero Revision: 00 Title: Pausing an RTP Media Stream Creation date: 2013-01-24 WG ID: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-= 0 0.txt Status: http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero Htmlized: http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00 Abstract: In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. The IETF Secretariat _______________________________________________ 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 Feb 27 08:29:05 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310621F8780 for ; Wed, 27 Feb 2013 08:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.312 X-Spam-Level: X-Spam-Status: No, score=-107.312 tagged_above=-999 required=5 tests=[AWL=-1.063, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6yoRNbcEUWj for ; Wed, 27 Feb 2013 08:29:05 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3FC21F877A for ; Wed, 27 Feb 2013 08:29:04 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1RGSXMm021725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Feb 2013 17:29:01 +0100 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, 27 Feb 2013 17:28:56 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 27 Feb 2013 17:28:55 +0100 Thread-Topic: Draft agenda for IETF 86 Thread-Index: Ac4VB4ky1LtedZZbSfmLM+TXdsCSfA== 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.69 on 155.132.188.83 Subject: [avtext] Draft agenda for IETF 86 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 Feb 2013 16:29:05 -0000 (As AVTEXT cochair) I have uploaded a draft agenda and it follows below. Note that we are sharing a 2 hour slot with MMUSIC, and I have yet to hear = back from the MMUSIC chairs on how this fits with their plans, so please ex= pect some flexibility in time allocations and order. Comments are welcome. Can proposed presenters please check and if necessary indicate their altern= ates. We would expect slides at the latest by breakfast Thursday morning (1= 4th March). Regards Keith AVTEXT agenda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Keith Drage, Jonathan Lennox Grouping (joint discussion with MMUSIC) --------------------------------------- 30 min A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Pro= tocol (RTP) Sources draft-lennox-raiarea-rtp-grouping-taxonomy-00 Jonathan Lennox UML model Magnus Westerlund Agenda bash and status update ----------------------------- 5 min Chairs Media stream pause ------------------ 20 min Pausing an RTP Media Stream draft-even-avtext-flow-control-to-zero-00 Roni Even RTP Media Stream Pause and Resume draft-westerlund-avtext-rtp-stream-pause-03 Magnus Westerlund (already presented at IETF 85 - see also http://www.ietf.org/proceedings/85= /slides/slides-85-avtext-2.pdf) Splicing notification --------------------- 10 min RTP/RTCP extension for RTP Splicing Notification draft-xia-avtext-splicing-notification-01 Rachel Huang From keith.drage@alcatel-lucent.com Wed Feb 27 17:35:22 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C374B21F87E0 for ; Wed, 27 Feb 2013 17:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.336 X-Spam-Level: X-Spam-Status: No, score=-109.336 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 DkJ6qmz2gEF6 for ; Wed, 27 Feb 2013 17:35:22 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B344B21F8853 for ; Wed, 27 Feb 2013 17:28:30 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1S1SMuL007219 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Feb 2013 02:28:23 +0100 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; Thu, 28 Feb 2013 02:28:22 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Thu, 28 Feb 2013 02:28:21 +0100 Thread-Topic: Draft agenda for IETF 86 Thread-Index: Ac4VB4ky1LtedZZbSfmLM+TXdsCSfAAStuMw 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.69 on 155.132.188.84 Subject: Re: [avtext] Draft agenda for IETF 86 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 Feb 2013 01:35:22 -0000 (As AVTEXT cochair) I have just uploaded a slightly revised agenda. As indicated we are sharing with MMUSIC and we will go first. As a result I have moved the taxonomy discussion to the end of the agenda, = because that is joint with MMUSIC. https://datatracker.ietf.org/meeting/86/agenda/avtext/=20 Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 27 February 2013 16:29 > To: avtext@ietf.org > Subject: Draft agenda for IETF 86 >=20 > (As AVTEXT cochair) >=20 > I have uploaded a draft agenda and it follows below. >=20 > Note that we are sharing a 2 hour slot with MMUSIC, and I have yet to hea= r > back from the MMUSIC chairs on how this fits with their plans, so please > expect some flexibility in time allocations and order. >=20 > Comments are welcome. >=20 > Can proposed presenters please check and if necessary indicate their > alternates. We would expect slides at the latest by breakfast Thursday > morning (14th March). >=20 > Regards >=20 > Keith >=20 > AVTEXT agenda > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Chairs: Keith Drage, Jonathan Lennox >=20 > Grouping (joint discussion with MMUSIC) > --------------------------------------- >=20 > 30 min >=20 > A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport > Protocol (RTP) Sources > draft-lennox-raiarea-rtp-grouping-taxonomy-00 > Jonathan Lennox >=20 > UML model > Magnus Westerlund >=20 > Agenda bash and status update > ----------------------------- >=20 > 5 min > Chairs >=20 > Media stream pause > ------------------ >=20 > 20 min >=20 > Pausing an RTP Media Stream > draft-even-avtext-flow-control-to-zero-00 > Roni Even >=20 > RTP Media Stream Pause and Resume > draft-westerlund-avtext-rtp-stream-pause-03 > Magnus Westerlund > (already presented at IETF 85 - see also > http://www.ietf.org/proceedings/85/slides/slides-85-avtext-2.pdf) >=20 > Splicing notification > --------------------- >=20 > 10 min >=20 > RTP/RTCP extension for RTP Splicing Notification > draft-xia-avtext-splicing-notification-01 > Rachel Huang