From richard@shockey.us Mon Sep 3 10:52:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3900721F8597 for ; Mon, 3 Sep 2012 10:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.699 X-Spam-Level: X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 QYxYTPGvW52p for ; Mon, 3 Sep 2012 10:52:37 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 8DBA421F8592 for ; Mon, 3 Sep 2012 10:52:37 -0700 (PDT) Received: (qmail 9031 invoked by uid 0); 3 Sep 2012 17:52:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 3 Sep 2012 17:52:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=WOUjl+kk41/QQMPV1P8It1JyYRTcyjq6dMYyWWEdeg4=; b=RZ6XyQ8jY8JDSb5m0jDJJMphC4R3qScq6JBdbw/mhqidyqshonpGXnzUJ4ce7AQbxio5CZNa5jQ1E5rNMTcHUDG5KHm6mTu/GLoGPs15gnWgSvF5FU+JRG33op2zc69K; Received: from [71.191.243.130] (port=50912 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T8ap8-0007qJ-Su; Mon, 03 Sep 2012 11:52:35 -0600 From: "Richard Shockey" To: "'Randall Gellens'" , "'John Leslie'" , "'Randell Jesup'" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> In-Reply-To: Date: Mon, 3 Sep 2012 13:52:34 -0400 Message-ID: <00a701cd89fc$e681e9d0$b385bd70$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac2HxqG2c5DJCB41TMOsT9VUjD9raQCNYdFQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:52:38 -0000 So why, pray tell, did the IETF go through the grief of developing OPUS if its most useful application will not mandate its implementation. SHOULD for 722 AMR-WB is very helpful in integration with Enterprise and Mobile networks. Its August .. clearly the silly season for technical discussions. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Friday, August 31, 2012 6:09 PM To: John Leslie; Randell Jesup Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec At 11:12 AM -0400 8/31/12, John Leslie wrote: > Our issue here is Mandatory-to-Implement. It is very important to > have at least one MTI audio codec. I could live with that being G.711, > because I trust the market to _actually_ implement others. Exactly. The discussion has been going in my view off-track into debates about which codec is best for which environments. The real issue is mandatory versus recommended. We can pick G.711 as MTI and rely on implementers to support others. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One never sits in hotel lobby chairs, my dear. One never knows whom has been sitting in them before one. --unknown _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randy@qualcomm.com Mon Sep 3 11:31:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F091D21F8697 for ; Mon, 3 Sep 2012 11:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Vkzl3RwmyjbF for ; Mon, 3 Sep 2012 11:31:21 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 466F021F847B for ; Mon, 3 Sep 2012 11:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346697081; x=1378233081; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=suwgX0haXatEj//mrdd2kTB0nuwZWARgN3Uuf8PoNnE=; b=Oz6r06RkUltex4P0UdggTTHJ5+wp0OXBi9WekaNZSI4YmJTqNiXjb1Ao qZLUJ/cG68LJEi9U6sArcMdiqgsxXVSEKt4LMawJRUUeshrEFVlqOlwE4 CJHsCSyC7xna+WrdPh/mckybGzJmA8hyxFOKkZWebEiqS0p3rATzfl8RH w=; X-IronPort-AV: E=McAfee;i="5400,1158,6824"; a="232424150" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 03 Sep 2012 11:31:20 -0700 X-IronPort-AV: E=Sophos;i="4.80,361,1344236400"; d="scan'208";a="294188062" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Sep 2012 11:31:20 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 3 Sep 2012 11:31:19 -0700 Message-ID: In-Reply-To: <00a701cd89fc$e681e9d0$b385bd70$@us> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> X-Mailer: Eudora for Mac OS X Date: Mon, 3 Sep 2012 11:23:36 -0700 To: Richard Shockey , 'John Leslie' , 'Randell Jesup' From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 18:31:22 -0000 At 1:52 PM -0400 9/3/12, Richard Shockey wrote: > So why, pray tell, did the IETF go through the grief of developing OPUS if > its most useful application will not mandate its implementation. So OPUS won't be used unless it's mandated? If OPUS has the benefits ascribed to it here, then developers will flock to it and it doesn't need to be mandated. (If it doesn't have the benefits, then it shouldn't be mandated.) > SHOULD for 722 AMR-WB is very helpful in integration with Enterprise and > Mobile networks. > > Its August .. clearly the silly season for technical discussions. > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Randall Gellens > Sent: Friday, August 31, 2012 6:09 PM > To: John Leslie; Randell Jesup > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCWEB needs an Internet Codec > > At 11:12 AM -0400 8/31/12, John Leslie wrote: > >> Our issue here is Mandatory-to-Implement. It is very important to >> have at least one MTI audio codec. I could live with that being G.711, >> because I trust the market to _actually_ implement others. > > Exactly. The discussion has been going in my view off-track into debates > about which codec is best for which environments. The real issue is > mandatory versus recommended. > > We can pick G.711 as MTI and rely on implementers to support others. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- One never sits in > hotel lobby chairs, my dear. One never knows whom has been sitting in them > before one. > --unknown > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I Think We're All Bozos on This Bus. --Firesign Theatre From richard@shockey.us Mon Sep 3 12:50:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FDA21F86AA for ; Mon, 3 Sep 2012 12:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.585 X-Spam-Level: X-Spam-Status: No, score=-100.585 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJAThWQ8CUUJ for ; Mon, 3 Sep 2012 12:50:07 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id EAABC21F86A3 for ; Mon, 3 Sep 2012 12:50:06 -0700 (PDT) Received: (qmail 16953 invoked by uid 0); 3 Sep 2012 19:50:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 3 Sep 2012 19:50:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=vBJ4NNE7U/xMptbWCG2zP7hcRQAIEfXqpSCBb83ItBo=; b=csF9Em1jp4UWPfG/dVDfIwjpjl2gFDQuY4mFJxH/xX/hc+Fa1n8wcmYPVMH2342NBVzxw1O/WBU9HS6TReuIdPa5P1fwT2TIcE1exTtV1bm22ABuZ/IG8DEBgDYkD3Gs; Received: from [71.191.243.130] (port=51543 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T8cep-0006x0-QV; Mon, 03 Sep 2012 13:50:04 -0600 From: "Richard Shockey" To: "'Randall Gellens'" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> In-Reply-To: Date: Mon, 3 Sep 2012 15:50:02 -0400 Message-ID: <00d401cd8a0d$4ff81a00$efe84e00$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac2KAlErvWZRI7gCTya8SNG4ps6/owACn42Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 19:50:07 -0000 -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Monday, September 03, 2012 2:24 PM To: Richard Shockey; 'John Leslie'; 'Randell Jesup' Cc: rtcweb@ietf.org Subject: RE: [rtcweb] RTCWEB needs an Internet Codec At 1:52 PM -0400 9/3/12, Richard Shockey wrote: > So why, pray tell, did the IETF go through the grief of developing > OPUS if its most useful application will not mandate its implementation. So OPUS won't be used unless it's mandated? [RS> ] Presumably we should try and make things better rather than just accept the status quo which is the very definition of G.711 If OPUS has the benefits ascribed to it here, then developers will flock to it and it doesn't need to be mandated. (If it doesn't have the benefits, then it shouldn't be mandated.) [RS> ] Humm should like a old argument for IPv6. From basilgohar@librevideo.org Mon Sep 3 20:13:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14F21F8554 for ; Mon, 3 Sep 2012 20:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 7ulWGJ7nwVD0 for ; Mon, 3 Sep 2012 20:13:07 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 477A321F8552 for ; Mon, 3 Sep 2012 20:13:04 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 24E67656F6B for ; Mon, 3 Sep 2012 23:13:03 -0400 (EDT) Message-ID: <504571BC.9020103@librevideo.org> Date: Mon, 03 Sep 2012 23:13:00 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 03:13:08 -0000 History has shown time and again the companies with sufficient market power will opt to implement their own proprietary and/or patented formats, or formats which benefit them financially, over royalty free, widely-available formats, even when their own formats are technically inferiors. Take, for example, Windows Media Audio, MP3, and AAC in the audio realm (in contrast to Vorbis) and Windows Media Video and also Quicktime formats (when, at the time, technically superior, more standardized formats exists, such as the MPEG family, though that has it's own problems). Mandating the implementation a royalty free format is about the only way to get such corporations to implement it, even if it is technically superior, as the above examples demonstrate. On 09/03/2012 02:23 PM, Randall Gellens wrote: > At 1:52 PM -0400 9/3/12, Richard Shockey wrote: > >> So why, pray tell, did the IETF go through the grief of developing >> OPUS if >> its most useful application will not mandate its implementation. > > So OPUS won't be used unless it's mandated? > > If OPUS has the benefits ascribed to it here, then developers will > flock to it and it doesn't need to be mandated. (If it doesn't have > the benefits, then it shouldn't be mandated.) > >> SHOULD for 722 AMR-WB is very helpful in integration with Enterprise >> and >> Mobile networks. >> >> Its August .. clearly the silly season for technical discussions. >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of >> Randall Gellens >> Sent: Friday, August 31, 2012 6:09 PM >> To: John Leslie; Randell Jesup >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >> >> At 11:12 AM -0400 8/31/12, John Leslie wrote: >> >>> Our issue here is Mandatory-to-Implement. It is very important to >>> have at least one MTI audio codec. I could live with that being >>> G.711, because I trust the market to _actually_ implement others. >> >> Exactly. The discussion has been going in my view off-track into >> debates >> about which codec is best for which environments. The real issue is >> mandatory versus recommended. >> >> We can pick G.711 as MTI and rely on implementers to support others. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- One never sits in >> hotel lobby chairs, my dear. One never knows whom has been sitting >> in them >> before one. >> --unknown >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Libre Video http://librevideo.org From sergio.garcia.murillo@gmail.com Tue Sep 4 02:30:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ADB21F865C for ; Tue, 4 Sep 2012 02:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6gsQy2fd9m2 for ; Tue, 4 Sep 2012 02:30:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7FDC21F865B for ; Tue, 4 Sep 2012 02:30:22 -0700 (PDT) Received: by bkty12 with SMTP id y12so2575880bkt.31 for ; Tue, 04 Sep 2012 02:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=eU6aGHer8kAd/V1Gnh5mCeu4TpUVrjZMYOXJiMMRZ0Y=; b=gBKcFOVI9fT8poZjySl+yRdyyRC5KKy67ufvuf1evXV5deyxOlUVrmO8oOTpIrAUbC q3Y73VrbdVnH6HgxQaRyXmqVxcf+85sAZpDFH1pl6kbo2Zh6ELEVvipq66FosJN9GMli LUjiifIEr4qqEZrXmRbYtlDEjeD40eSmeSZZWccTl4njjktNRU41bg+L/VwuDexgXchZ 5CpioMDFvr9DtG9bh6XWhnGc61zLiu7AD65tsNdURJTAUkSy7DmqjAd1I+owIPKCzIGr cU5rBByzXCc4a7qk2KCAoFszDOhDBrNyyQIITKkYr1kXQMGuwsS9YySTFWoBPU40b9g3 yeFQ== Received: by 10.204.148.86 with SMTP id o22mr8057552bkv.59.1346751021702; Tue, 04 Sep 2012 02:30:21 -0700 (PDT) Received: from [192.168.1.11] (252.pool80-103-134.dynamic.orange.es. [80.103.134.252]) by mx.google.com with ESMTPS id n17sm9709145bks.6.2012.09.04.02.30.19 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 02:30:20 -0700 (PDT) Message-ID: <5045CA2B.2070406@gmail.com> Date: Tue, 04 Sep 2012 11:30:19 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> In-Reply-To: <504571BC.9020103@librevideo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:30:23 -0000 Maybe an stupid question, but how it is planned to enforce the mandated codecs implementation? What prevents any of those "corporations" not implementing a mandated codec in their WebRTC products? Best regards Sergio El 04/09/2012 5:13, Basil Mohamed Gohar escribió: > History has shown time and again the companies with sufficient market > power will opt to implement their own proprietary and/or patented > formats, or formats which benefit them financially, over royalty free, > widely-available formats, even when their own formats are technically > inferiors. Take, for example, Windows Media Audio, MP3, and AAC in > the audio realm (in contrast to Vorbis) and Windows Media Video and > also Quicktime formats (when, at the time, technically superior, more > standardized formats exists, such as the MPEG family, though that has > it's own problems). > > Mandating the implementation a royalty free format is about the only > way to get such corporations to implement it, even if it is > technically superior, as the above examples demonstrate. > > On 09/03/2012 02:23 PM, Randall Gellens wrote: >> At 1:52 PM -0400 9/3/12, Richard Shockey wrote: >> >>> So why, pray tell, did the IETF go through the grief of developing >>> OPUS if >>> its most useful application will not mandate its implementation. >> >> So OPUS won't be used unless it's mandated? >> >> If OPUS has the benefits ascribed to it here, then developers will >> flock to it and it doesn't need to be mandated. (If it doesn't have >> the benefits, then it shouldn't be mandated.) >> >>> SHOULD for 722 AMR-WB is very helpful in integration with >>> Enterprise and >>> Mobile networks. >>> >>> Its August .. clearly the silly season for technical discussions. >>> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of >>> Randall Gellens >>> Sent: Friday, August 31, 2012 6:09 PM >>> To: John Leslie; Randell Jesup >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>> >>> At 11:12 AM -0400 8/31/12, John Leslie wrote: >>> >>>> Our issue here is Mandatory-to-Implement. It is very important to >>>> have at least one MTI audio codec. I could live with that being >>>> G.711, because I trust the market to _actually_ implement others. >>> >>> Exactly. The discussion has been going in my view off-track into >>> debates >>> about which codec is best for which environments. The real issue is >>> mandatory versus recommended. >>> >>> We can pick G.711 as MTI and rely on implementers to support others. >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself >>> only >>> -------------- Randomly selected tag: --------------- One never >>> sits in >>> hotel lobby chairs, my dear. One never knows whom has been sitting >>> in them >>> before one. >>> --unknown >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > From harald@alvestrand.no Tue Sep 4 05:25:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420DF21F8525 for ; Tue, 4 Sep 2012 05:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5rImMYH+boL8 for ; Tue, 4 Sep 2012 05:25:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1362421F84D4 for ; Tue, 4 Sep 2012 05:25:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0225639E127 for ; Tue, 4 Sep 2012 14:25:39 +0200 (CEST) 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 ZZrfkfcKwyU0 for ; Tue, 4 Sep 2012 14:25:37 +0200 (CEST) Received: from [137.194.56.116] (eduroam-0-116.enst.fr [137.194.56.116]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5315439E04C for ; Tue, 4 Sep 2012 14:25:37 +0200 (CEST) Message-ID: <5045F343.9030107@alvestrand.no> Date: Tue, 04 Sep 2012 14:25:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> In-Reply-To: <5045CA2B.2070406@gmail.com> Content-Type: multipart/alternative; boundary="------------050308080108080204090904" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 12:25:41 -0000 This is a multi-part message in MIME format. --------------050308080108080204090904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 09/04/2012 11:30 AM, Sergio Garcia Murillo wrote: > Maybe an stupid question, but how it is planned to enforce the > mandated codecs implementation? What prevents any of those > "corporations" not implementing a mandated codec in their WebRTC > products? My first chance to quote the new, Web-page-format Tao of IETF: "One more thing that is important for newcomers: the IETF in no way "runs the Internet", despite what some people mistakenly might say. The IETF makes voluntary standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF." http://www.ietf.org/tao.html There is no protocol police; anyone can implement a product that implements only part of an IETF standard. They just can't truthfully claim to have implemented that IETF standard. > > Best regards > Sergio > > El 04/09/2012 5:13, Basil Mohamed Gohar escribió: >> History has shown time and again the companies with sufficient market >> power will opt to implement their own proprietary and/or patented >> formats, or formats which benefit them financially, over royalty >> free, widely-available formats, even when their own formats are >> technically inferiors. Take, for example, Windows Media Audio, MP3, >> and AAC in the audio realm (in contrast to Vorbis) and Windows Media >> Video and also Quicktime formats (when, at the time, technically >> superior, more standardized formats exists, such as the MPEG family, >> though that has it's own problems). >> >> Mandating the implementation a royalty free format is about the only >> way to get such corporations to implement it, even if it is >> technically superior, as the above examples demonstrate. >> >> On 09/03/2012 02:23 PM, Randall Gellens wrote: >>> At 1:52 PM -0400 9/3/12, Richard Shockey wrote: >>> >>>> So why, pray tell, did the IETF go through the grief of developing >>>> OPUS if >>>> its most useful application will not mandate its implementation. >>> >>> So OPUS won't be used unless it's mandated? >>> >>> If OPUS has the benefits ascribed to it here, then developers will >>> flock to it and it doesn't need to be mandated. (If it doesn't have >>> the benefits, then it shouldn't be mandated.) >>> >>>> SHOULD for 722 AMR-WB is very helpful in integration with >>>> Enterprise and >>>> Mobile networks. >>>> >>>> Its August .. clearly the silly season for technical discussions. >>>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of >>>> Randall Gellens >>>> Sent: Friday, August 31, 2012 6:09 PM >>>> To: John Leslie; Randell Jesup >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>>> >>>> At 11:12 AM -0400 8/31/12, John Leslie wrote: >>>> >>>>> Our issue here is Mandatory-to-Implement. It is very important >>>>> to have at least one MTI audio codec. I could live with that >>>>> being G.711, because I trust the market to _actually_ implement >>>>> others. >>>> >>>> Exactly. The discussion has been going in my view off-track into >>>> debates >>>> about which codec is best for which environments. The real issue is >>>> mandatory versus recommended. >>>> >>>> We can pick G.711 as MTI and rely on implementers to support others. >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>> only >>>> -------------- Randomly selected tag: --------------- One never >>>> sits in >>>> hotel lobby chairs, my dear. One never knows whom has been >>>> sitting in them >>>> before one. >>>> --unknown >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050308080108080204090904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/04/2012 11:30 AM, Sergio Garcia Murillo wrote:
Maybe an stupid question, but how it is planned to enforce the mandated codecs implementation? What prevents any of those "corporations" not implementing a mandated codec in their WebRTC products?

My first chance to quote the new, Web-page-format Tao of IETF:

"One more thing that is important for newcomers: the IETF in no way "runs the Internet", despite what some people mistakenly might say. The IETF makes voluntary standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF."

http://www.ietf.org/tao.html

There is no protocol police; anyone can implement a product that implements only part of an IETF standard. They just can't truthfully claim to have implemented that IETF standard.


Best regards
Sergio

El 04/09/2012 5:13, Basil Mohamed Gohar escribió:
History has shown time and again the companies with sufficient market power will opt to implement their own proprietary and/or patented formats, or formats which benefit them financially, over royalty free, widely-available formats, even when their own formats are technically inferiors.  Take, for example, Windows Media Audio, MP3, and AAC in the audio realm (in contrast to Vorbis) and Windows Media Video and also Quicktime formats (when, at the time, technically superior, more standardized formats exists, such as the MPEG family, though that has it's own problems).

Mandating the implementation a royalty free format is about the only way to get such corporations to implement it, even if it is technically superior, as the above examples demonstrate.

On 09/03/2012 02:23 PM, Randall Gellens wrote:
At 1:52 PM -0400 9/3/12, Richard Shockey wrote:

 So why, pray tell, did the IETF go through the grief of developing OPUS if
 its most useful application will not mandate its implementation.

So OPUS won't be used unless it's mandated?

If OPUS has the benefits ascribed to it here, then developers will flock to it and it doesn't need to be mandated.  (If it doesn't have the benefits, then it shouldn't be mandated.)

 SHOULD for 722 AMR-WB is very helpful in integration with Enterprise and
 Mobile networks.

 Its August .. clearly the silly season for technical discussions.

 -----Original Message-----
 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
 Randall Gellens
 Sent: Friday, August 31, 2012 6:09 PM
 To: John Leslie; Randell Jesup
 Cc: rtcweb@ietf.org
 Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

 At 11:12 AM -0400 8/31/12, John Leslie wrote:

  Our issue here is Mandatory-to-Implement. It is very important to  have at least one MTI audio codec. I could live with that being G.711,  because I trust the market to _actually_ implement others.

 Exactly.  The discussion has been going in my view off-track into debates
 about which codec is best for which environments.  The real issue is
 mandatory versus recommended.

 We can pick G.711 as MTI and rely on implementers to support others.

 --
 Randall Gellens
 Opinions are personal;    facts are suspect;    I speak for myself only
 -------------- Randomly selected tag: --------------- One never sits in
 hotel lobby chairs, my dear.  One never knows whom has been sitting in them
 before one.
     --unknown
 _______________________________________________
 rtcweb mailing list
 rtcweb@ietf.org
 https://www.ietf.org/mailman/listinfo/rtcweb





_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------050308080108080204090904-- From gettysjim@gmail.com Tue Sep 4 07:28:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E383F11E8097 for ; Tue, 4 Sep 2012 07:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5NtPZLHylZR for ; Tue, 4 Sep 2012 07:28:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81F21F8543 for ; Tue, 4 Sep 2012 07:28:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7714361vbb.31 for ; Tue, 04 Sep 2012 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t65cXIFZ3cWNt54kWT63K9TzqjVqCbVbigH4IzxwAFA=; b=B49GtW9c7Gx8BoA4elLa/KVEGxWxCU8H2ycWHmENEVQwFRuK1s+vqfIWQo8E9+s+6a 2OD7JiijAt9NbqsywjEmHMPN06lZeMbcvbJv2JVtAINndpDk1XIVnnEBiPnVXICGFyD7 XtRyx7RPmNbgSwYTgZYsR+M+4IzjCSBCXMvH3mW9B2iLrl+frq+zyOWqgKN+d/WK02OS clYV5kfZidCYT+Y8WqqL9vgH5th2GHsdbZbBl1utVZwl0BSrae3G0xD39yNTV42ZkYGl zfEIj6p1/3cfkscbQTQYRNwRuwp66ivUJTPRd6tOyCNLmqdJeldrcVj8X5IvplXeOxXl w5Cw== Received: by 10.52.35.99 with SMTP id g3mr12773699vdj.21.1346768887714; Tue, 04 Sep 2012 07:28:07 -0700 (PDT) Received: from [192.168.1.112] (c-50-138-166-22.hsd1.ma.comcast.net. [50.138.166.22]) by mx.google.com with ESMTPS id g1sm1160956vdk.8.2012.09.04.07.28.04 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 07:28:06 -0700 (PDT) Sender: Jim Gettys Message-ID: <50460FF1.30708@freedesktop.org> Date: Tue, 04 Sep 2012 10:28:01 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Harald Alvestrand References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> In-Reply-To: <5045F343.9030107@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:28:11 -0000 On 09/04/2012 08:25 AM, Harald Alvestrand wrote: > On 09/04/2012 11:30 AM, Sergio Garcia Murillo wrote: >> Maybe an stupid question, but how it is planned to enforce the >> mandated codecs implementation? What prevents any of those >> "corporations" not implementing a mandated codec in their WebRTC >> products? > > My first chance to quote the new, Web-page-format Tao of IETF: > > "One more thing that is important for newcomers: the IETF in no way > "runs the Internet", despite what some people mistakenly might say. > The IETF makes voluntary standards that are often adopted by Internet > users, but it does not control, or even patrol, the Internet. If your > interest in the IETF is because you want to be part of the overseers, > you may be badly disappointed by the IETF." > > http://www.ietf.org/tao.html > > There is no protocol police; anyone can implement a product that > implements only part of an IETF standard. They just can't truthfully > claim to have implemented that IETF standard. To the extent that the IETF has any power, it is an *indirect* power. If a standard is valued, then organisations (at their own discretion) may start to write "Must implement RFCxxxx" into requests for proposals, and choose (or not choose) to spend their money buying products that conform or do not conform. RFC's are littered with ignored mandatory features; similarly for RFC's themselves. - Jim > >> >> Best regards >> Sergio >> >> El 04/09/2012 5:13, Basil Mohamed Gohar escribió: >>> History has shown time and again the companies with sufficient >>> market power will opt to implement their own proprietary and/or >>> patented formats, or formats which benefit them financially, over >>> royalty free, widely-available formats, even when their own formats >>> are technically inferiors. Take, for example, Windows Media Audio, >>> MP3, and AAC in the audio realm (in contrast to Vorbis) and Windows >>> Media Video and also Quicktime formats (when, at the time, >>> technically superior, more standardized formats exists, such as the >>> MPEG family, though that has it's own problems). >>> >>> Mandating the implementation a royalty free format is about the only >>> way to get such corporations to implement it, even if it is >>> technically superior, as the above examples demonstrate. >>> >>> On 09/03/2012 02:23 PM, Randall Gellens wrote: >>>> At 1:52 PM -0400 9/3/12, Richard Shockey wrote: >>>> >>>>> So why, pray tell, did the IETF go through the grief of >>>>> developing OPUS if >>>>> its most useful application will not mandate its implementation. >>>> >>>> So OPUS won't be used unless it's mandated? >>>> >>>> If OPUS has the benefits ascribed to it here, then developers will >>>> flock to it and it doesn't need to be mandated. (If it doesn't >>>> have the benefits, then it shouldn't be mandated.) >>>> >>>>> SHOULD for 722 AMR-WB is very helpful in integration with >>>>> Enterprise and >>>>> Mobile networks. >>>>> >>>>> Its August .. clearly the silly season for technical discussions. >>>>> >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf Of >>>>> Randall Gellens >>>>> Sent: Friday, August 31, 2012 6:09 PM >>>>> To: John Leslie; Randell Jesup >>>>> Cc: rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>>>> >>>>> At 11:12 AM -0400 8/31/12, John Leslie wrote: >>>>> >>>>>> Our issue here is Mandatory-to-Implement. It is very important >>>>>> to have at least one MTI audio codec. I could live with that >>>>>> being G.711, because I trust the market to _actually_ implement >>>>>> others. >>>>> >>>>> Exactly. The discussion has been going in my view off-track into >>>>> debates >>>>> about which codec is best for which environments. The real issue is >>>>> mandatory versus recommended. >>>>> >>>>> We can pick G.711 as MTI and rely on implementers to support others. >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for >>>>> myself only >>>>> -------------- Randomly selected tag: --------------- One never >>>>> sits in >>>>> hotel lobby chairs, my dear. One never knows whom has been >>>>> sitting in them >>>>> before one. >>>>> --unknown >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ron@debian.org Tue Sep 4 14:01:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420A21E8040 for ; Tue, 4 Sep 2012 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 nhh92XX2kcP1 for ; Tue, 4 Sep 2012 14:01:01 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 8145E11E80A4 for ; Tue, 4 Sep 2012 14:01:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD5rRlB20ve5/2dsb2JhbABFuyOBCIIgAQEFOhwzCxguFBgNQBKHcbsNiwkbhxcDiE6FKIdiAYsVhQWCcw Received: from ppp118-210-247-185.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.247.185]) by ipmail06.adl2.internode.on.net with ESMTP; 05 Sep 2012 06:30:58 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id EF9044F8F3 for ; Wed, 5 Sep 2012 06:30:56 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bR4wDPQ+dtcT for ; Wed, 5 Sep 2012 06:30:55 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 7AF744F902; Wed, 5 Sep 2012 06:30:55 +0930 (CST) Date: Wed, 5 Sep 2012 06:30:55 +0930 From: Ron To: rtcweb@ietf.org Message-ID: <20120904210055.GN23434@audi.shelbyville.oz> References: <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50460FF1.30708@freedesktop.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:01:02 -0000 On Tue, Sep 04, 2012 at 10:28:01AM -0400, Jim Gettys wrote: > On 09/04/2012 08:25 AM, Harald Alvestrand wrote: > > On 09/04/2012 11:30 AM, Sergio Garcia Murillo wrote: > >> Maybe an stupid question, but how it is planned to enforce the > >> mandated codecs implementation? What prevents any of those > >> "corporations" not implementing a mandated codec in their WebRTC > >> products? > > > > My first chance to quote the new, Web-page-format Tao of IETF: > > > > "One more thing that is important for newcomers: the IETF in no way > > "runs the Internet", despite what some people mistakenly might say. > > The IETF makes voluntary standards that are often adopted by Internet > > users, but it does not control, or even patrol, the Internet. If your > > interest in the IETF is because you want to be part of the overseers, > > you may be badly disappointed by the IETF." > > > > http://www.ietf.org/tao.html > > > > There is no protocol police; anyone can implement a product that > > implements only part of an IETF standard. They just can't truthfully > > claim to have implemented that IETF standard. > > To the extent that the IETF has any power, it is an *indirect* power. > If a standard is valued, then organisations (at their own discretion) > may start to write "Must implement RFCxxxx" into requests for proposals, > and choose (or not choose) to spend their money buying products that > conform or do not conform. Which in turn is of course precisely the compelling reason for Opus to be explicitly specified here - so that _rtcweb_ *can* have a chance of being a standard of value, which promises the people who follow it high-quality results and interoperability with any others who implement the standard. There are already plenty of Go It Alone, ad hoc solutions, which to date have little to no market traction. Anything which performs worse than they do is unlikely to be attractive, and anything which doesn't promise real interoperability doesn't solve the problem which has prevented them from being widely used outside of small disjoint circles. "The Market" has already decided. It decided it wanted a Real standard for this. Our job here is to give them one that doesn't totally suck. It's not about "forcing Opus on people who don't want it", it's about making rtcweb actually work for all those people who are serious about wanting something that actually works. We're clearly not going to give them that by saying: "Here's some valve-age technology that's been all but obsolete for decades now - if you want this to be Any Good, you'll have to figure that part out for yourselves. Good Luck with that!" However much valves might be the stuff of True Audiophile wet dreams, that just won't fly. And I'm pretty sure almost everyone here knows it. If there's something _better_ than Opus for this, I'd love to hear all about it. But talk of things that are strictly and/or vastly worse is kind of hard to take seriously. I can see how some people might be feeling a little frustrated at watching that tack push ever closer to the wind. Luff and KISSes, Ron From hoene@uni-tuebingen.de Wed Sep 5 03:48:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C013F21F869D for ; Wed, 5 Sep 2012 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=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 Y5aISw2r5gBP for ; Wed, 5 Sep 2012 03:48:18 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id F403921F8694 for ; Wed, 5 Sep 2012 03:48:17 -0700 (PDT) Received: from ChristianHoene (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q85Alwfj023569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 12:48:07 +0200 From: "Hoene" To: "Jean-Marc Valin" , Date: Wed, 5 Sep 2012 12:47:59 +0200 Message-ID: <007401cd8b53$f4dbbbc0$de933340$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: de Thread-Index: Ac2LU5f0bIItQKPmTvG86JwBgp7RJA== X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx08); id=3003-uFHzcw Subject: [rtcweb] Collecting Opus Test Results X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:48:20 -0000 Hi all, please do not forget to forward any new characterization test results of Opus to the Opus mailing so that I can collect them. =09 These days, I hardly have time to follow all discussions on the rtcweb mailing list. Thanks Christian Hoene -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag = von Randell Jesup Gesendet: Freitag, 31. August 2012 23:18 An: rtcweb@ietf.org Betreff: Re: [rtcweb] Opus vs AMR-WB for packet loss On 8/31/2012 4:50 PM, Jean-Marc Valin wrote: > OK, here's something concrete for comparing Opus to AMR-WB in packet > loss conditions. I've simulated 30% bursty packet loss in the > following conditions: > 1) AMR-WB mode 8 (23.85 kb/s) > 2) Opus at 24 kb/s (no FEC) > 3) Opus at 24 kb/s with FEC (24 kb/s is the total including FEC) > > I've uploaded the results at: http://jmvalin.ca/plc/ > > I think everyone will agree that even without FEC, Opus sounds much > better than AMR-WB. And when you turn FEC on, then you barely even > notice the losses. That's really, really good. :-) Especially with FEC. --=20 Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randy@qualcomm.com Wed Sep 5 16:31:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D774C21F86EC for ; Wed, 5 Sep 2012 16:31:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUoLJbgdFmnp for ; Wed, 5 Sep 2012 16:31:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 360F321F86EB for ; Wed, 5 Sep 2012 16:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346887895; x=1378423895; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=fU241l+XiIdS8YIccgjJuUC92C3RCZyCMciK8BF3Eq8=; b=TTJ691rrEDy+RJi69N32vxoLUS2urOKppCu8Fm4bcKHeaVRwR8T0ZrHw IayGvksbij5tcWk8R1wn2KlKzg5xu0xRh7HszF+9rVcAZQQdFvPQ4N5B1 xy7L9CFkL5aFY0ls+DkzelO8GGiBYI5ujthFu73OojJNub62XUM/m8U6/ M=; X-IronPort-AV: E=McAfee;i="5400,1158,6826"; a="233315208" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 05 Sep 2012 16:31:34 -0700 X-IronPort-AV: E=Sophos;i="4.80,376,1344236400"; d="scan'208";a="382094093" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Sep 2012 16:31:34 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 5 Sep 2012 16:31:33 -0700 Message-ID: In-Reply-To: <20120901061236.GH23434@audi.shelbyville.oz> <20120904210055.GN23434@audi.shelbyville.oz> References: <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <20120901031955.GF23434@audi.shelbyville.oz> <20120901061236.GH23434@audi.shelbyville.oz> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> X-Mailer: Eudora for Mac OS X Date: Wed, 5 Sep 2012 16:29:28 -0700 To: Ron , Cameron Byrne From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:31:35 -0000 At 6:30 AM +0930 9/5/12, Ron wrote: > It's not about "forcing Opus on people who don't want it", it's about > making rtcweb actually work for all those people who are serious about > wanting something that actually works. We're clearly not going to give > them that by saying: "Here's some valve-age technology that's been all > but obsolete for decades now - if you want this to be Any Good, you'll > have to figure that part out for yourselves. Good Luck with that!" > > However much valves might be the stuff of True Audiophile wet dreams, > that just won't fly. And I'm pretty sure almost everyone here knows it. At 3:42 PM +0930 9/1/12, Ron wrote: > The question is what is the minimum > guarantee that any rtcweb user will have when talking to any other > rtcweb user, without first needing to sign consent forms and download > optional extras (possibly for a reasonably non-discriminatory fee, > and even possibly trojaned). I'm puzzled by the repeated statements that imply that any non-mandatory codec can't be supported without separate downloads (now extended to include signed consent forms and fees). That's simply not true. Any implementation is free to support any codec out-of-the-box. One of the goals of rtcweb is to encourage greater use of native codecs, and greater access to such codecs by applications such as those running in browsers. These are worthy goals, since native codecs often have better performance within the environment. (Examples include AMR and EVRC on handsets.) These codecs also can be supported out-of-the-box, no separate downloads, no signed forms. The discussion is over which codecs MUST be supported. Since mandatory codecs are required, with no choice, they should have the lowest possible burden to implement, taking into account all aspects of the implementation burden. Then, implementers are free to consider which additional codecs they will support, taking into account the costs and benefits. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The single biggest problem in communication is the illusion that it has taken place. --G. B. Shaw From ted.ietf@gmail.com Wed Sep 5 17:02:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAA521F8508 for ; Wed, 5 Sep 2012 17:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UK4c1YxRrcI for ; Wed, 5 Sep 2012 17:02:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9C321F8505 for ; Wed, 5 Sep 2012 17:02:39 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1761145vcb.31 for ; Wed, 05 Sep 2012 17:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZD9ZatdWoLLjm6kzMvqjemRV97oB7EqyYbpu8u8W6Tg=; b=PoJKLWvKq8oDYpS8fHLRfb56SElXMatlATsy4qbjAQ8qnjBS2Hr9rgyKfe1Bu5NS/J 1JO+59+XK7g2llRuWhfwzY43+pJEQmNQkGySQb6QJcmL1Q18kQeVAw6OVKVvMAdfsQG5 0jVJgtlCE/VtRhcL1Clcu6IWzWGmaA2Dti8e1sJ56lOg04xC9dy2rSL71KvWUViEbJQL P8uaDAOqytubrDBPrGcOs3+UVmqqes2S3NC2nfw0L5yMo+CwIb/wgTowf2ZGjaEPuVjQ QJLafhY7wDIobqy5W1aCGeO0h4SePkdYLgirm9ZmTUrlW/UqVGmRIeNiuwZIMmI3aL0w dBFw== MIME-Version: 1.0 Received: by 10.52.32.99 with SMTP id h3mr138152vdi.108.1346889759112; Wed, 05 Sep 2012 17:02:39 -0700 (PDT) Received: by 10.58.201.226 with HTTP; Wed, 5 Sep 2012 17:02:39 -0700 (PDT) In-Reply-To: References: <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120901031955.GF23434@audi.shelbyville.oz> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120901061236.GH23434@audi.shelbyville.oz> <20120904210055.GN23434@audi.shelbyville.oz> Date: Wed, 5 Sep 2012 17:02:39 -0700 Message-ID: From: Ted Hardie To: Randall Gellens Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 00:02:40 -0000 On Wed, Sep 5, 2012 at 4:29 PM, Randall Gellens wrote: > The discussion is over which codecs MUST be supported. Since mandatory > codecs are required, with no choice, they should have the lowest possible > burden to implement, taking into account all aspects of the implementation > burden. Speaking personally, I would put this slightly differently. After all, a codec with low implementation burdens may have very poor bandwidth consumption characteristics, relatively inferior acoustic range, or other problematic aspects which don't read on the implementation burden. As you note below, the overall problem is one of cost/benefit analysis. In the end, we need to find a way to avoid implementation failure with a set of choices that represent the best overall cost/benefit ratio in the contexts identified by our use cases. >Then, implementers are free to consider which additional codecs > they will support, taking into account the costs and benefits. Absolutely. regards, Ted Hardie From jmvalin@mozilla.com Wed Sep 5 18:11:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6396121F86EB for ; Wed, 5 Sep 2012 18:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 2flzl2oeqwcW for ; Wed, 5 Sep 2012 18:11:48 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0404121F85C0 for ; Wed, 5 Sep 2012 18:11:47 -0700 (PDT) Received: from [192.168.1.14] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2F3F5F267B; Wed, 5 Sep 2012 18:11:46 -0700 (PDT) Message-ID: <5047F829.1000200@mozilla.com> Date: Wed, 05 Sep 2012 21:11:05 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Randall Gellens References: <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <20120901031955.GF23434@audi.shelbyville.oz> <20120901061236.GH23434@audi.shelbyville.oz> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 01:11:51 -0000 On 12-09-05 07:29 PM, Randall Gellens wrote: > The discussion is over which codecs MUST be supported. Since mandatory > codecs are required, with no choice, they should have the lowest > possible burden to implement, taking into account all aspects of the > implementation burden. Then, implementers are free to consider which > additional codecs they will support, taking into account the costs and > benefits. Following the same reasoning, I think we should consider ROT13 as the MTI encryption algorithm in rtcweb, since it's clearly the one with the lowest possible burden to implement. Then, implementers would be free to consider AES, 3DES, Blowfish or Enigma, taking into account the costs and benefits. Jean-Marc From ron@debian.org Wed Sep 5 20:03:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BBC21F854F for ; Wed, 5 Sep 2012 20:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 4Ld+NqBQX7TR for ; Wed, 5 Sep 2012 20:03:10 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 00B3F21F84D6 for ; Wed, 5 Sep 2012 20:03:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIPAFsRSFB20ve5/2dsb2JhbABFtnSDHwOBC4EIgiABAQQBOhweBQULCw4KFRkUGA0kM4VxgXYFunCLEYEGgheDKAOIToUoh2IBkBqCc4FR Received: from ppp118-210-247-185.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.247.185]) by ipmail05.adl6.internode.on.net with ESMTP; 06 Sep 2012 12:33:07 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id DC0A04F8F3; Thu, 6 Sep 2012 11:30:40 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dXAbchWqHxAa; Thu, 6 Sep 2012 11:30:40 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 0B7344F902; Thu, 6 Sep 2012 11:30:40 +0930 (CST) Date: Thu, 6 Sep 2012 11:30:40 +0930 From: Ron To: Randall Gellens Message-ID: <20120906020039.GP23434@audi.shelbyville.oz> References: <20120831151247.GY72831@verdi> <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 03:03:11 -0000 On Wed, Sep 05, 2012 at 04:29:28PM -0700, Randall Gellens wrote: > At 6:30 AM +0930 9/5/12, Ron wrote: > > It's not about "forcing Opus on people who don't want it", it's about > > making rtcweb actually work for all those people who are serious about > > wanting something that actually works. We're clearly not going to give > > them that by saying: "Here's some valve-age technology that's been all > > but obsolete for decades now - if you want this to be Any Good, you'll > > have to figure that part out for yourselves. Good Luck with that!" > > > > However much valves might be the stuff of True Audiophile wet dreams, > > that just won't fly. And I'm pretty sure almost everyone here knows it. > > > At 3:42 PM +0930 9/1/12, Ron wrote: > > The question is what is the minimum > > guarantee that any rtcweb user will have when talking to any other > > rtcweb user, without first needing to sign consent forms and download > > optional extras (possibly for a reasonably non-discriminatory fee, > > and even possibly trojaned). > > > I'm puzzled by the repeated statements that imply that any > non-mandatory codec can't be supported without separate downloads > (now extended to include signed consent forms and fees). That's > simply not true. I'm not sure exactly what you find puzzling about the idea that if non-mandatory codecs are _required_ for adequate performance, then for people using different implementations, that provide different subsets of all the available codecs by default, *someone* is almost certain to have to add on something extra to enable interoperability with adequate performance. That should be simply self-evident. Enough so that I'll leave deeper study of venn-diagrams as a homework exercise for any still-bewildered readers. > Any implementation is free to support any codec out-of-the-box. Especially since this point was repeated alongside the others with approximately equal frequency. I'm pretty sure we have a clear consensus on that. I'm a little puzzled myself why you trimmed that from the messages you quoted, only to repeat it again. But we have list archives for anyone who wants the full context. > One of the goals of rtcweb is to encourage greater use of native > codecs, and greater access to such codecs by applications such as > those running in browsers. These are worthy goals, since native > codecs often have better performance within the environment. > (Examples include AMR and EVRC on handsets.) These codecs also can > be supported out-of-the-box, no separate downloads, no signed forms. The unspoken assumption there being "provided you both happen to be using the same platform with the same native codecs", (and of course provided your vendor already signed the forms and payed the fees to obtain a licence for you for the specific examples you cite). That's fine if you do happen to. It's when you don't that the MTI codecs are what is relevant for interoperability. The tiny performance difference between AMR and Opus might be of value to some people, and if both their devices support it, and both of them have a licence to use it, then great. But if rtcweb sucks if you don't have those things, then this group will have failed to meet its charter. Which does explicitly consider interoperability as a deliverable (but doesn't seem to actually mention anything about native codecs at all?). It does mention that the IETF has a codec working group whose work should be considered though. > The discussion is over which codecs MUST be supported. Since > mandatory codecs are required, with no choice, they should have the > lowest possible burden to implement, taking into account all aspects > of the implementation burden. Then, implementers are free to > consider which additional codecs they will support, taking into > account the costs and benefits. The libopus reference implementation source can be freely download by anyone, at any time, and redistributed at will by any party with no other "burden" placed upon them to do anything else. Much of the (small amount of) extra work needed to interface that to many existing audio processing abstractions is already done too. How does that compare to the burden of your preferred example AMR? Let's see. Wikipedia tells me: "The initial fee for professional content creation tools and "real-time channel" products is $6,500. The minimum annual royalty shall be $10,000, excluding the initial fee in year 1 of the license agreement" 3GPP apparently provides a reference implementation, though it's not clear to me at this stage if that implementation actually provides the quality claimed by the people who say it is better than Opus for the extreme low-bandwidth niche. What does appear to be clear though is that I'm not able to redistribute the source of that, so I couldn't actually provide it with my rtcweb implementation if I also wanted to give my users the source for that (whether they paid me for it or not). If those people wanted to use it, they'd have to jump through all the hoops themselves to obtain it and a licence to use it. So it's not at all clear to me how Opus isn't convincingly the winner of the "lowest possible burden" test you propose either. "Lowest possible" is of course a silly extreme. That would be raw PCM (modulo endianness trouble). So I'm assuming you meant something more sensible than that like lowest practical. One codec, which covers all ranges and is as near as possible in this modern world to being completely unencumbered would seem to be the obvious answer there. Luckily for us, such a thing actually exists, and the IETF even has change control over it. What more could we wish for, Ron From john@jlc.net Thu Sep 6 09:51:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85E521F8744 for ; Thu, 6 Sep 2012 09:51:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-VcGuG3Yy08 for ; Thu, 6 Sep 2012 09:51:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 77DC321F8722 for ; Thu, 6 Sep 2012 09:51:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED1F633C26; Thu, 6 Sep 2012 12:51:42 -0400 (EDT) Date: Thu, 6 Sep 2012 12:51:42 -0400 From: John Leslie To: Ron Message-ID: <20120906165142.GF79075@verdi> References: <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> <20120906020039.GP23434@audi.shelbyville.oz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906020039.GP23434@audi.shelbyville.oz> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:51:53 -0000 Ron wrote: > > The libopus reference implementation source can be freely download > by anyone, at any time, and redistributed at will by any party with > no other "burden" placed upon them to do anything else. See: www.opus-codec.org/downloads/ (the libopus.sourceforge.net is quite unrelated). http://downloads.xiph.org/releases/opus/opus-1.0.0-rc.tar.gz is the release-candidate. Note: ] ] The codec is still under development, in the final stages preparing ] the first production release. I find this very encouraging, but not quite enough to justify MTI today. Note also: https://developer.mozilla.org/en-US/docs/Media_formats_supported_by_the_audio_and_video_elements#Ogg_Opus which shows some level of support already in Mozilla (but not Chrome, Explorer, Opera, or Safari) Here is a case where "Google's position is" could actually be helpful -- were they to announce Opus support in Chrome... -- John Leslie From jmvalin@mozilla.com Thu Sep 6 10:30:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF621F8746 for ; Thu, 6 Sep 2012 10:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 w9ylzF9gy+7p for ; Thu, 6 Sep 2012 10:30:20 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF221F8745 for ; Thu, 6 Sep 2012 10:30:20 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id ACB5CF230D; Thu, 6 Sep 2012 10:30:17 -0700 (PDT) Message-ID: <5048DDA8.3090900@mozilla.com> Date: Thu, 06 Sep 2012 13:30:16 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: John Leslie References: <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> <20120906020039.GP23434@audi.shelbyville.oz> <20120906165142.GF79075@verdi> In-Reply-To: <20120906165142.GF79075@verdi> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:30:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2012 12:51 PM, John Leslie wrote: > is the release-candidate. Note: ] ] The codec is still under > development, in the final stages preparing ] the first production > release. Thanks for reporting this. It was old text that hadn't been updated in a long time and which I have now fixed. In fact, the code has been in a stable state for about one year now. The only reason we haven't called it 1.0 yet is because we wanted to wait for the official RFC. The good news is that RFC 6716 should be published any day now. > which shows some level of support already in Mozilla (but not > Chrome, Explorer, Opera, or Safari) > > Here is a case where "Google's position is" could actually be > helpful -- were they to announce Opus support in Chrome... Quoting from Harald Alvestrand's email on this topic: > Since the number of people stating their opinion has been large, > I'll just reiterate the opinion I had (and hummed for) in > Vancouver: Opus and G.711 should be mandatory to implement for > RTCWEB. Since the question of whether there's any value to making > the decision now has been raised: The first interoperable products > implementing RTCWEB are shipping within a very short timeframe. > Those first implementations will shape the market for what's > actually used in practice. In order to allow applications requiring > high quality sound to be among the first ones developed, those > first products need to include a common choice of a high quality > codec. I think that can be counted as Google going with Opus. As for Microsoft, I haven't seen their official position, but I can only assume that considering their investment in this codec, they'd probably like to use it. Regarding Opera, some people have reported Opus already working (even before Firefox) through GStreamer builds that included Opus. I don't know what Opera's official position is on Opus, but support is definitely trivial for them. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQSN2oAAoJEJ6/8sItn9q9g1QH/iwXmlWeDuKYFtV5Pl2AdMhO 5E42l+AfPlTB0dlhyjDBwnoTP/fqroS0NdNKq8vgtoouQUjTIJyY59XVKVvm4qV2 xqwi3z73yxwS9I0WX5p1w5WKKAc75/lm7ErL2w1gTCX2z/3zZk9P246OizE8yXTJ Nhd5D1zfrBGJZ6Y0r47LUWaXSVHBbAOSvvJ3nC+02I7ud/E31uN7Oxo3C6YysZs5 34UacCambe9AqX2JfA0AoRCKpApCDIbBPwli39xCYkOq5WeLc8uIGxbc0Z1GYA61 jUATyv4xktxHNUu2bmRdbqN1uS5B066XsqwRyCjJjTuJW6jQGHJ5eASlK6+Gb0g= =vlof -----END PGP SIGNATURE----- From tterriberry@mozilla.com Thu Sep 6 13:18:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178B821F862B for ; Thu, 6 Sep 2012 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 nrmzNx6IxHtv for ; Thu, 6 Sep 2012 13:18:00 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id B155421F8628 for ; Thu, 6 Sep 2012 13:18:00 -0700 (PDT) Received: from [10.109.24.6] (static-88.131.8.202.addr.tdcsong.se [88.131.8.202]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B5B54F25BE for ; Thu, 6 Sep 2012 13:17:58 -0700 (PDT) Message-ID: <504904F5.4020704@mozilla.com> Date: Thu, 06 Sep 2012 13:17:57 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <00a701cd89fc$e681e9d0$b385bd70$@us> <504571BC.9020103@librevideo.org> <5045CA2B.2070406@gmail.com> <5045F343.9030107@alvestrand.no> <50460FF1.30708@freedesktop.org> <20120904210055.GN23434@audi.shelbyville.oz> <20120906020039.GP23434@audi.shelbyville.oz> <20120906165142.GF79075@verdi> <5048DDA8.3090900@mozilla.com> In-Reply-To: <5048DDA8.3090900@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:18:01 -0000 Jean-Marc Valin wrote: > that included Opus. I don't know what Opera's official position is on > Opus, but support is definitely trivial for them. I spoke with Simon Peters at FOMS this week in Paris, and he told me that Opera did plan to enable Opus on platforms that do not provide their own version of gstreamer (where, of course, it is already enabled, providing they ship at least version 0.10.23). From fluffy@cisco.com Fri Sep 7 07:23:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C221F8513 for ; Fri, 7 Sep 2012 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTK0WBwDb4LR for ; Fri, 7 Sep 2012 07:23:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6321F84FE for ; Fri, 7 Sep 2012 07:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1572; q=dns/txt; s=iport; t=1347027783; x=1348237383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1j0EX/iTkxDUPpdYR8lEKoPqWJ20AM6Ns4MX8TfhZbA=; b=E8EE4hoezreD4vZNLcp6CTSvXph6beKoNIitTu1qxKV0FTTfGrN6F3l0 CiAlnidxkfIGAheGXmiUQxE25xByvUUu/jOHuZH3zWIZ+c7BbN22BkwYi md/UIOzYObH9Yap3maXOGeo1RiP8Xr8E6+Kp1Vt3a5CBOU+RPVoJdCk9M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADECSlCtJXG//2dsb2JhbABFuzqBB4IgAQEBAwESASc/BQsCAQgYHhAyJQIEDgUih2gGmyegSYsShVRgA5VdjjWBZ4Jk X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="119325892" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 07 Sep 2012 14:22:51 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q87EMpUO015094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 14:22:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.253]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 09:22:51 -0500 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [rtcweb] Appropriateness of bypass mechanisms (Re: HTTP Fallback draft) Thread-Index: AQHNjQRDzKB1tIUge060+/uXq+3R1A== Date: Fri, 7 Sep 2012 14:22:51 +0000 Message-ID: References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> <502285B2.8080007@alvestrand.no> In-Reply-To: <502285B2.8080007@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--28.806700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7A873E7259F3AC438D1A6B1EB4DD7CC8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Appropriateness of bypass mechanisms (Re: HTTP Fallback draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:23:04 -0000 On Aug 8, 2012, at 9:28 AM, Harald Alvestrand wrote: > Forking thread.... >=20 > On 08/08/2012 05:05 PM, Cameron Byrne wrote: >>=20 >>=20 >> Is this thread really about the ietf engineering a way to by-pass netwo= rk policy set by network operators? >>=20 > It's about getting stuff done in the presence of rules that hinder the "s= imple way". > Those rules may be set that way deliberately, by ignorance, because of im= plementation limitations, or in error; there's no way to know. >=20 >> I do not believe that is acceptable. >>=20 > We've already done TURN, including TURN over TLS. TURN was specifically designed to allow the network operator to be able to = continue to control and enforce policies similar to what they currently do = in their firewalls. You will note Kaufman strongly disagreed with this desi= gn principle and would have done the permissions in TURN significantly diff= erently - that would have actually made TURN faster and easier to use but w= ould have removed this property. We choice to stay on the path of "not viol= ating or circumventing the will of network administrators".=20 That said, I think the discussion about making media relay / tunnel protoco= l that masquerades as HTTPS is leaping of the edge of the slippery slope. I= have mixed feelings about if that is wise or not but that's a long discuss= ion. >=20 > Old quote: "This is not about starting down the slippery slope; this is a= bout how far we slide into the muck at the bottom". Agree with that :-)= From magnus.westerlund@ericsson.com Fri Sep 7 08:11:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235821F85AF for ; Fri, 7 Sep 2012 08:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThcTCdmetYF1 for ; Fri, 7 Sep 2012 08:11:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3783721F85A4 for ; Fri, 7 Sep 2012 08:11:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-dc-504a0e8c50b6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 76.48.25676.C8E0A405; Fri, 7 Sep 2012 17:11:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Fri, 7 Sep 2012 17:11:08 +0200 Message-ID: <504A0E8C.5070405@ericsson.com> Date: Fri, 7 Sep 2012 17:11:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3VreXzyvAYGYDq8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPb9BUvBVP6KxQs2sDcwLufpYuTkkBAwkVjVs4sVwhaTuHBv PVsXIxeHkMApRonmA+ugnGWMEmf/LGAGqeIV0JZ4+vE4C4jNIqAisa7hGZjNJmAhcfNHIxuI LSoQKLH67EcmiHpBiZMzn4DViAgIS2x91QsWFxaIlFhwYw9YXEjARuLgv81g8zkFbCX2njrE DnGRpMSbyTfBapgFDCSOLJrDCmHLS2x/O4cZoldboqGpg3UCo+AsJOtmIWmZhaRlASPzKkbh 3MTMnPRyI73Uoszk4uL8PL3i1E2MwMA8uOW36g7GO+dEDjFKc7AoifNab93jLySQnliSmp2a WpBaFF9UmpNafIiRiYNTqoEx074w7bryyRk5lSZr/iVfvabeybKuXXnCv5U+J5rreV2OVuz2 Xxi11kNkQ9W0oNC9lz7OXe5VZfdIVI1dudD/iI/T/aRmodmaJ7gORf2TUM536vus68itVSC0 TuxC1gzWHWsbHsX5f1v6oXR73aKloYdfqq/5e0afXXnHv72JT5KEn+RKGLUosRRnJBpqMRcV JwIAHvEvaRoCAAA= Subject: [rtcweb] Consensus Statement for Re: Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:11:11 -0000 WG, We chairs can confirm a strong consensus for both G.711 and Opus as mandatory to implement audio codecs for RTCWeb based on the WG meeting and the mailing list. There have been individuals with other views. Several wanted G.711 only, which is one of the alternative in the WG meeting's consensus decision. These additional opinions have not altered the chairs view that there is strong consensus for G.711 and Opus. The Chairs take note of two other aspects which were raised in the discussion on the mailing list; First, that some argued for including also G.722 as mandatory to implement codec and several more have proposed it to be listed as SHOULD be implemented. Based on the consensus in the WG this is clearly not mandatory to implement. When it comes recommending additional codecs to be implemented there has been views expressed previously that any such recommendations would not be particular useful and only increase the amount of contention in the WG. Based on the discussion to date, the chairs will run a consensus call on whether the WG should recommend specific codecs which will not be mandatory to implement (i.e. will the document contain SHOULDs as well as MUSTs for codec implementation)". If the response to that consensus call indicates consensus for non-mandatory to implement recommendations, we will run consensus calls on those codecs to be included at that level. Secondly, there were views and suggestions that we should not make a decision for mandatory to implement codecs at this point in time. The working group had previously indicated strong consensus to choose a mandatory to implement codec in this space, to avoid interoperability failure. We do not believe that reconsideration of this decision is required at this time, and we believe that the support for the current consensus is strong, if not perfect. The WG chairs Ted, Cullen and Magnus From ted.ietf@gmail.com Fri Sep 7 08:27:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C292A21F86C2 for ; Fri, 7 Sep 2012 08:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyOLKt2W11OP for ; Fri, 7 Sep 2012 08:27:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3731B21F86BE for ; Fri, 7 Sep 2012 08:27:55 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3848006vbb.31 for ; Fri, 07 Sep 2012 08:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TKEnDgG8W4GWMjNKJN+/MoDVHojv8R1hkt+FYy1jULg=; b=YL+v3737SyDTAgKnvk2gxwuWYNrW4CrDxXRbiHMzLRGsFWkkYrsOHSN2IhW3xmStro QVshYG4YSgAXPLRid5wutRxaRVEycSOAS2XJhjrY5Aa4QwowI43UTjcIui4LRQKXUR7z 3kgCgMp8J198sc3IEJmag+CGh1Lnv8+QU4dY2zxQp5uLm/J/1wKADqh57VLO2jnQEc8M Zy5SqpJBMnRU8fqcYnxLuDKnOAPCnIYOe5YyARcKoX9UyaPHq4t/L5BJ4AqBCkm+LyUg OPWVf15hvYUDzql0wxGw1KrJTcXzaVQaxxfvX75b2yBnZp+BIaJcNp0nOouxF+oqQcpZ UzzA== MIME-Version: 1.0 Received: by 10.221.13.72 with SMTP id pl8mr7710679vcb.5.1347031653759; Fri, 07 Sep 2012 08:27:33 -0700 (PDT) Received: by 10.58.201.226 with HTTP; Fri, 7 Sep 2012 08:27:33 -0700 (PDT) Date: Fri, 7 Sep 2012 08:27:33 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:27:55 -0000 Based on the feedback at the last working group meeting, the chairs believe that there is general support for creating a document that describes the QoS issues relating to RTCWEB. We would like to call for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan Druta has agreed to serve as the WG document editor, should this document move forward. Please send comments to the list by September 16, 2012 Ted and Magnus From internet-drafts@ietf.org Fri Sep 7 13:10:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372B21E80D5; Fri, 7 Sep 2012 13:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 H4YbYOHuNAf5; Fri, 7 Sep 2012 13:10:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7033521E805F; Fri, 7 Sep 2012 13:10:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907201055.21152.87457.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 13:10:55 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:10:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : WebRTC Audio Codec and Processing Requirements Author(s) : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-00.txt Pages : 6 Date : 2012-09-07 Abstract: This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 7 13:16:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581D421E80E1; Fri, 7 Sep 2012 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 OBPrPRtFrt-z; Fri, 7 Sep 2012 13:16:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2821E80DD; Fri, 7 Sep 2012 13:16:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907201611.1013.74459.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 13:16:11 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:16:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWeb Datagram Connection Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-01.txt Pages : 12 Date : 2012-09-07 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From igor.faynberg@alcatel-lucent.com Fri Sep 7 14:04:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089621F8672 for ; Fri, 7 Sep 2012 14:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 DhR8+pMT2rZS for ; Fri, 7 Sep 2012 14:04:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A921F8671 for ; Fri, 7 Sep 2012 14:04:28 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q87L4Rl8005541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Sep 2012 16:04:28 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q87L4R0J020117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 16:04:27 -0500 Received: from [135.244.193.66] (faynberg.lra.lucent.com [135.244.193.66]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q87L4OCp010223; Fri, 7 Sep 2012 16:04:26 -0500 (CDT) Message-ID: <504A6157.90604@alcatel-lucent.com> Date: Fri, 07 Sep 2012 17:04:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:04:35 -0000 I am all for it, especially that with Dan's agreeing to edit it, the document will be in good hands! Igor On 9/7/2012 11:27 AM, Ted Hardie wrote: > Based on the feedback at the last working group meeting, the chairs > believe that there is general support for creating a document that > describes the QoS issues relating to RTCWEB. We would like to call > for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > Druta has agreed to serve as the WG document editor, should this > document move forward. > > Please send comments to the list by September 16, 2012 > > Ted and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tterriberry@mozilla.com Fri Sep 7 14:29:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B804021F8533 for ; Fri, 7 Sep 2012 14:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 vX1BwHeKZWrR for ; Fri, 7 Sep 2012 14:29:20 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6068321F8530 for ; Fri, 7 Sep 2012 14:29:20 -0700 (PDT) Received: from [10.43.3.128] (unknown [94.42.88.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 83802F2562 for ; Fri, 7 Sep 2012 14:29:19 -0700 (PDT) Message-ID: <504A672D.7080601@mozilla.com> Date: Fri, 07 Sep 2012 14:29:17 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:29:20 -0000 Ted Hardie wrote: > describes the QoS issues relating to RTCWEB. We would like to call > for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan I support the publication of this draft as a working group item with Dan Druta as the editor. From ekr@rtfm.com Fri Sep 7 14:33:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3893221E80CB for ; Fri, 7 Sep 2012 14:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pt2hBFT3VjFl for ; Fri, 7 Sep 2012 14:33:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCE21E808F for ; Fri, 7 Sep 2012 14:33:22 -0700 (PDT) Received: by eaai11 with SMTP id i11so13432eaa.31 for ; Fri, 07 Sep 2012 14:33:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=u4eDUr2yGKOXgix0mnaPmIKp5Z6axuzqsEcVqJ9KIsw=; b=GQb7UcGByi+iyxR6CxNTn7qwfrp8gqqE0NhtBu6i4j2URUP/6nPxzGnj1xylJXpZtJ EmtmhB0/6zKy/fJEtFalwa+t+jb9Xnq632bdJRhy5oNEDGpCo93Vc6/Haq5kRtGzl+NM TQaHgOvr0TxW+bq0tvGzrC8oU32EywipFxDDckcAFSOMqMq7Fo+5cU59VERxUUywFcJx mz7qhNmjvJ8rFYHcVSxtVIFw7a+cuLLt0C1pBlDqjdSxG46KobzuSNDgp/nTRZlPFbyc o8nWtCOlJ7FtDEYw57y7pIwrpEXdgC02TDkGxLCi+4GRLbkoTMZzCpKq0b5JOjwtUUUL /qlg== Received: by 10.14.181.132 with SMTP id l4mr10001513eem.17.1347053601506; Fri, 07 Sep 2012 14:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Fri, 7 Sep 2012 14:32:38 -0700 (PDT) X-Originating-IP: [216.239.55.106] In-Reply-To: <504A672D.7080601@mozilla.com> References: <504A672D.7080601@mozilla.com> From: Eric Rescorla Date: Fri, 7 Sep 2012 14:32:38 -0700 Message-ID: To: "Timothy B. Terriberry" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmKw1zJ6y6kQUUuKecN/g3jlVtIEGC+I0byZUO7IWjiZGBYdVy5wCMFfrdlDgZCKipQSdD1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:33:23 -0000 +1 On Fri, Sep 7, 2012 at 2:29 PM, Timothy B. Terriberry wrote: > Ted Hardie wrote: >> >> describes the QoS issues relating to RTCWEB. We would like to call >> for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > > > I support the publication of this draft as a working group item with Dan > Druta as the editor. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Fri Sep 7 18:14:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDED21E8044 for ; Fri, 7 Sep 2012 18:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 BnQwZtBT8u0p for ; Fri, 7 Sep 2012 18:14:03 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id CA68121E80DF for ; Fri, 7 Sep 2012 18:14:03 -0700 (PDT) Received: from userPC (unknown [122.179.42.4]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id E763B3E34FE; Sat, 8 Sep 2012 01:13:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1347066843; bh=HXXPGnMQhOBVAt4IrlwIm81Hu3APYRR7hehpSad6mHw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KG0tPFSW7PiGlDdx/PAqcGpCZB6j+Om7gG5itRDEqisNdp0QYEhARP0Tp6oi8+PPP vBHfWB4n8VHCzX9o5DBp40Mt3l0ud2yCXwGcs78MKOSLtHvwHZhxG/KOPzMlbVq0Gm LxN5Woi7k1wp9ILxaC4Gb8ELXLfe5d9T9mBT4HsA= From: "Parthasarathi R" To: "'Eric Rescorla'" , "'Timothy B. Terriberry'" References: <504A672D.7080601@mozilla.com> In-Reply-To: Date: Sat, 8 Sep 2012 06:43:50 +0530 Message-ID: <000f01cd8d5f$3892d990$a9b88cb0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2NQGs6P3DgsNszTNacGYt9DZaw9QAHrfbg Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0202.504A9BDB.003D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 01:14:04 -0000 +1 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Saturday, September 08, 2012 3:03 AM To: Timothy B. Terriberry Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft +1 On Fri, Sep 7, 2012 at 2:29 PM, Timothy B. Terriberry wrote: > Ted Hardie wrote: >> >> describes the QoS issues relating to RTCWEB. We would like to call >> for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > > > I support the publication of this draft as a working group item with Dan > Druta as the editor. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From denglingli@chinamobile.com Fri Sep 7 19:43:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5118721E80B4 for ; Fri, 7 Sep 2012 19:43:04 -0700 (PDT) X-Quarantine-ID: <9q4zrZ-GDkcF> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 4.673 X-Spam-Level: **** X-Spam-Status: No, score=4.673 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222] 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 9q4zrZ-GDkcF for ; Fri, 7 Sep 2012 19:43:03 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59C21E805A for ; Fri, 7 Sep 2012 19:43:03 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 0BB37E465; Sat, 8 Sep 2012 10:43:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 01C88E450; Sat, 8 Sep 2012 10:43:04 +0800 (CST) To: "Parthasarathi R" MIME-Version: 1.0 From: denglingli@chinamobile.com Date: Sat, 8 Sep 2012 10:43:02 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-08 10:43:03 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19170.003 X-TM-AS-Result: No--12.197-7.0-31-10 X-imss-scan-details: No--12.197-7.0-31-10;No--12.197-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 02:43:04 -0000 +1 Lingli =20 =3D=3D=3D=3D=3D=3D=3D=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=BD=A3=BA=3D=3D= =3D=3D=3D=3D=3D +1 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Saturday, September 08, 2012 3:03 AM To: Timothy B. Terriberry Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft +1 On Fri, Sep 7, 2012 at 2:29 PM, Timothy B. Terriberry wrote: > Ted Hardie wrote: >> >> describes the QoS issues relating to RTCWEB. We would like to call >> for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > > > I support the publication of this draft as a working group item with Dan > Druta as the editor. > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =B5=CB=C1=E9=C0=F2 =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA denglingli@chinamobile.com= From bernard_aboba@hotmail.com Sun Sep 9 03:59:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF821F84D7 for ; Sun, 9 Sep 2012 03:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 MB3hG4CZfiPa for ; Sun, 9 Sep 2012 03:59:26 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 77C8821F8437 for ; Sun, 9 Sep 2012 03:59:26 -0700 (PDT) Received: from BLU401-EAS60 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Sep 2012 03:59:25 -0700 X-Originating-IP: [198.134.88.56] X-EIP: [08d2tcSDRBZkP0McQhZ11yYhibWBqqin] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: Content-Transfer-Encoding: base64 From: Bernard Aboba Content-Type: text/plain; charset="utf-8" In-Reply-To: Date: Sun, 9 Sep 2012 04:05:31 -0700 To: "denglingli@chinamobile.com" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 09 Sep 2012 10:59:25.0933 (UTC) FILETIME=[2D36C1D0:01CD8E7A] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 10:59:27 -0000 KzENCg0KDQoNCk9uIFNlcCA3LCAyMDEyLCBhdCAxOTo0MywgZGVuZ2xpbmdsaUBjaGluYW1vYmls ZS5jb20gd3JvdGU6DQoNCj4gKzENCj4gDQo+IExpbmdsaSAgDQo+IA0KPiANCj4gDQo+ID09PT09 PT3mgqjlnKjmnaXkv6HkuK3lhpnliLDvvJo9PT09PT09DQo+ICsxDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gRXJpYyBSZXNjb3JsYQ0K PiBTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDA4LCAyMDEyIDM6MDMgQU0NCj4gVG86IFRpbW90 aHkgQi4gVGVycmliZXJyeQ0KPiBDYzogcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb cnRjd2ViXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBRb1MgZHJhZnQNCj4gDQo+ICsxDQo+IA0KPiBP biBGcmksIFNlcCA3LCAyMDEyIGF0IDI6MjkgUE0sIFRpbW90aHkgQi4gVGVycmliZXJyeQ0KPiA8 dHRlcnJpYmVycnlAbW96aWxsYS5jb20+IHdyb3RlOg0KPj4gVGVkIEhhcmRpZSB3cm90ZToNCj4+ PiANCj4+PiBkZXNjcmliZXMgdGhlIFFvUyBpc3N1ZXMgcmVsYXRpbmcgdG8gUlRDV0VCLiAgV2Ug d291bGQgbGlrZSB0byBjYWxsDQo+Pj4gZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWplbm5pbmdzLXJ0 Y3dlYi1xb3MtMDAgYXMgdGhlIGlucHV0IGRyYWZ0LiAgRGFuDQo+PiANCj4+IA0KPj4gSSBzdXBw b3J0IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEgd29ya2luZyBncm91cCBpdGVt IHdpdGggRGFuDQo+PiBEcnV0YSBhcyB0aGUgZWRpdG9yLg0KPj4gDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRjd2ViIG1haWxpbmcgbGlz dA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcg bGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCj4gDQo+IA0KPiDpgpPngbXojokNCj4g5Lit5Zu956e75Yqo6YCa5L+h 56CU56m26ZmiDQo+IGRlbmdsaW5nbGlAY2hpbmFtb2JpbGUuY29tDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QN Cj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQo= From eckert@cisco.com Sun Sep 9 05:27:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B155921F846C for ; Sun, 9 Sep 2012 05:27:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ZPyOYF46IR for ; Sun, 9 Sep 2012 05:27:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E663B21F8435 for ; Sun, 9 Sep 2012 05:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=672; q=dns/txt; s=iport; t=1347193661; x=1348403261; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=RrZ505t0NGC7IO7pGOd1BsxXP/yhRcg1sPKEAWUA7sE=; b=FEqt9aOwTTpzCAMgnF+md1ddT5e5lldL2pCiABhRdxTuDCh3nqMDa2Fx DJG5EL8uhNIyGsixfGSp9R6yb01YJzdqFHkG7VD/gIQGUy2glr3wa7qVe F9Mc5xk9Q6m6pI89cEtusNt3r09VDZ8nmQRTflLpbOMqC5bRtstkcPTRw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALaKTFCrRDoG/2dsb2JhbABFu1OBB4IgAQEBBAEBAQ8BCh00GwsYLhQTSSKHbQyabp50BIsTgxeCP2ADiFONCQGONoFngwY X-IronPort-AV: E=Sophos;i="4.80,394,1344211200"; d="scan'208";a="57698932" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 09 Sep 2012 12:27:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q89CRcd9028156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Sep 2012 12:27:38 GMT Received: from mcast-linux1.cisco.com (mdt-linux4 [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id q89CRbXa030772 for ; Sun, 9 Sep 2012 05:27:37 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id q89CRbEM030771 for rtcweb@ietf.org; Sun, 9 Sep 2012 05:27:37 -0700 Date: Sun, 9 Sep 2012 05:27:37 -0700 From: Toerless Eckert To: rtcweb@ietf.org Message-ID: <20120909122737.GA30733@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 12:27:42 -0000 +1 On Fri, Sep 07, 2012 at 08:27:33AM -0700, Ted Hardie wrote: > Based on the feedback at the last working group meeting, the chairs > believe that there is general support for creating a document that > describes the QoS issues relating to RTCWEB. We would like to call > for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > Druta has agreed to serve as the WG document editor, should this > document move forward. > > Please send comments to the list by September 16, 2012 > > Ted and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Sep 10 07:10:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BEC21F8694 for ; Mon, 10 Sep 2012 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiGTe9tiO7GL for ; Mon, 10 Sep 2012 07:10:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E784B21F867E for ; Mon, 10 Sep 2012 07:10:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 176E339E0CE for ; Mon, 10 Sep 2012 16:10:49 +0200 (CEST) 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 Sf8nQPp5UopT for ; Mon, 10 Sep 2012 16:10:48 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2A7F739E090 for ; Mon, 10 Sep 2012 16:10:48 +0200 (CEST) Message-ID: <504DF4F4.9080401@alvestrand.no> Date: Mon, 10 Sep 2012 16:11:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:10:53 -0000 I support the adoption of this draft. Comments separately. On 09/07/2012 05:27 PM, Ted Hardie wrote: > Based on the feedback at the last working group meeting, the chairs > believe that there is general support for creating a document that > describes the QoS issues relating to RTCWEB. We would like to call > for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > Druta has agreed to serve as the WG document editor, should this > document move forward. > > Please send comments to the list by September 16, 2012 > > Ted and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Sep 10 07:15:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31321F8653 for ; Mon, 10 Sep 2012 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWZMa1gGqGug for ; Mon, 10 Sep 2012 07:15:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2021F865B for ; Mon, 10 Sep 2012 07:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0F2539E0CE for ; Mon, 10 Sep 2012 16:14:59 +0200 (CEST) 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 6gi+zgVeLuUS for ; Mon, 10 Sep 2012 16:14:59 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E045339E090 for ; Mon, 10 Sep 2012 16:14:58 +0200 (CEST) Message-ID: <504DF5EF.7070602@alvestrand.no> Date: Mon, 10 Sep 2012 16:15:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:15:12 -0000 Since this draft is mercifully short, I did a quick review. Notes: - Pointers to documentation on how browsers are expected to be able to set QCI and WiFI markings would be a good addition. Compared to those, DSCP codepoint setting is well understood. - I find it good that these 3 mechanisms are the only ones considered in the draft. I'm making the leap of faith that we intend to state that an implementation MUST implement DSCP codepoint marking, SHOULD implement QCI and WiFI markings when attached to appropriate interfaces, and that no other mechanism is going to get a MUST or SHOULD recommendation from the WG. If I'm right, can we make that explicit? - The restriction to 3 levels of priority seems to me like a reasonable simplification. Again, I want to make sure that this is an explicit and supported choice of the group. Harald On 09/07/2012 05:27 PM, Ted Hardie wrote: > Based on the feedback at the last working group meeting, the chairs > believe that there is general support for creating a document that > describes the QoS issues relating to RTCWEB. We would like to call > for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan > Druta has agreed to serve as the WG document editor, should this > document move forward. > > Please send comments to the list by September 16, 2012 > > Ted and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Mon Sep 10 09:38:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6513921E8037 for ; Mon, 10 Sep 2012 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAfjUs5BQUYG for ; Mon, 10 Sep 2012 09:38:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8008021E8034 for ; Mon, 10 Sep 2012 09:38:17 -0700 (PDT) Received: by lbky2 with SMTP id y2so1458344lbk.31 for ; Mon, 10 Sep 2012 09:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rQhrdpStYuYFg4kMtfRmYpm8cNxzNx/aqjh8U/aqdWg=; b=RvKtszxnROsuCQFFfLNFFKe/3AW6MLZhLOvYGGdrPJmWfORbyE2fEOzYMN6XTTVWy+ EoVMiokTkQhecDH4zfVA3qth0ZYLKnUrXIYxpQV87kEfk3asrK6xrnZgGHZjUm8UswpO 92h8lvMwpK5ulQoOSNsqZhALf8/2UzMlH310PKYdN2IB/9HmAq5Clx3RvGgtHxe2uqi0 8Kw/nJHcgq8PWy9oNHPQqEcGduYSo+aa6wri98VeOdf7SIfmttekmrZrFjyrONI+UR3d yEKbE6VNfekyHMKX5jvLbVfrNDF5tEbh0SLasGRfLQ6jSLeRKtC3SJygjsOh8eGq4WwN FzaQ== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr13124698lab.11.1347295096425; Mon, 10 Sep 2012 09:38:16 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 09:38:16 -0700 (PDT) In-Reply-To: <504DF5EF.7070602@alvestrand.no> References: <504DF5EF.7070602@alvestrand.no> Date: Mon, 10 Sep 2012 09:38:16 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:38:18 -0000 On 10 September 2012 07:15, Harald Alvestrand wrote: > - Pointers to documentation on how browsers are expected to be able to set > QCI and WiFI markings would be a good addition. Compared to those, DSCP > codepoint setting is well understood. I agree that this would be useful, if the draft really did make implementation (and use) of those markings a "SHOULD". See below. > - I find it good that these 3 mechanisms are the only ones considered in the > draft. I'm making the leap of faith that we intend to state that an > implementation MUST implement DSCP codepoint marking, SHOULD implement QCI > and WiFI markings when attached to appropriate interfaces, and that no other > mechanism is going to get a MUST or SHOULD recommendation from the WG. If > I'm right, can we make that explicit? What do people think about NOT including QCI/WiFi markings? Is it not possible for a wireless interface to examine DSCP markings in order to determine the markings for the link? We should endeavour to maintain the proper abstractions. > - The restriction to 3 levels of priority seems to me like a reasonable > simplification. Again, I want to make sure that this is an explicit and > supported choice of the group. Like Cullen, I don't see much room for a fourth priority. Nor do I see any particular advantage in having the fourth. 2 just doesn't seem like enough though. From martin.thomson@gmail.com Mon Sep 10 09:51:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1932721E8037 for ; Mon, 10 Sep 2012 09:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ3PurKovs3a for ; Mon, 10 Sep 2012 09:50:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E50521E803C for ; Mon, 10 Sep 2012 09:50:59 -0700 (PDT) Received: by lbky2 with SMTP id y2so1467869lbk.31 for ; Mon, 10 Sep 2012 09:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ueEd5jLHApEAeOv4oQwApwfIFf1lxlQepc8BkoSuqc8=; b=fuhU1ShR0fd2bD3mDnDrWY1CcpK7BWNPUgQ8iadR0Gmvxn3pDAzS/X1UAMHY1MXcgj yt+6J88mvKAh2S1349c6JfGoKs1NVjQIrehkHSzG0Dh4FjreGse6bQkgPdoPhJxlDXMJ R+LOsC5+4VGiKdGWsWDAMP4trvcv93Q4INnT9L3X1awHJTWh3oTwgwpJlhtPd8NkUIiu EVKz2d5GbdhbNAxygYyEzbyyH2ijqQ7bLHzY7UVW8ay+TlwfU4C4SKHLGH0tj2AGeQgg VzazhARCdS+INUcXycciMzJQVQKl281+z01uZk0EyqV8170n0TFOlpfFZF5JOfrV+iae Rtkg== MIME-Version: 1.0 Received: by 10.152.106.81 with SMTP id gs17mr1650979lab.2.1347295857869; Mon, 10 Sep 2012 09:50:57 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 09:50:57 -0700 (PDT) In-Reply-To: <504DF4F4.9080401@alvestrand.no> References: <504DF4F4.9080401@alvestrand.no> Date: Mon, 10 Sep 2012 09:50:57 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:51:00 -0000 I think that the work is valuable and useful. However, I have concerns about how priorities are communicated to the browser. I know that this introduces an interesting case of where the artificial division of labour between rtcweb and WebRTC breaks down, but the recent ruling in the W3C implies that this would require SDP work (unless there is something that I missed). That would then imply that this (new) work doesn't fit the rtweb charter and should go to MMUSIC. Did I miss a detail? --Martin On 10 September 2012 07:11, Harald Alvestrand wrote: > I support the adoption of this draft. > > Comments separately. > > > > On 09/07/2012 05:27 PM, Ted Hardie wrote: >> >> Based on the feedback at the last working group meeting, the chairs >> believe that there is general support for creating a document that >> describes the QoS issues relating to RTCWEB. We would like to call >> for adoption of draft-jennings-rtcweb-qos-00 as the input draft. Dan >> Druta has agreed to serve as the WG document editor, should this >> document move forward. >> >> Please send comments to the list by September 16, 2012 >> >> Ted and Magnus >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Mon Sep 10 09:55:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6990721E803C for ; Mon, 10 Sep 2012 09:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 v99bVSwdMSY9 for ; Mon, 10 Sep 2012 09:55:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 798F921E8037 for ; Mon, 10 Sep 2012 09:55:21 -0700 (PDT) Received: by eaai11 with SMTP id i11so1032061eaa.31 for ; Mon, 10 Sep 2012 09:55:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=iw1P59xEZyUS6XGHJSRS1K6vT2IA6lUigxnx9l3CJPo=; b=i8pxzmqKHmfN7UM4vBW4rxjxYdgZDs7q339zxSnSIIMO/xfAdo7cdxT4Tkd7Tx4AXC 6CCSG3RXtATpHFugV2kKImhzan0sTitqXbLoaEWNddrOJbfE8JOD/BjV94X5s3Ij6yGg lIJzwkNgE2RIGGqtGzmCUHO/9ZX4jEJgV6eRVFGGKfzMlmWY9ISxjP5Zptyx4KJXgDnk vu5zgd95G/cqu662uJkNB6SDrk3tNT/nD3YduCnONL2KOCy42ibddfu47j7sBxVhm9ih n4BjVndPab1SwuwYYJLLB70irnnp4U3KbrzCnntR7tcqKY0dzX7DkpgVJrsQ/LFxoF7a qIYg== Received: by 10.14.224.4 with SMTP id w4mr20896865eep.21.1347296120626; Mon, 10 Sep 2012 09:55:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Mon, 10 Sep 2012 09:54:40 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <504DF4F4.9080401@alvestrand.no> From: Eric Rescorla Date: Mon, 10 Sep 2012 09:54:40 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm3MerUTCW/JvvYUqKSMW7VELr/932Wrigyf1qX4/2PsGsv3Wd471iyT9mS8V87YKLrCqAG Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:55:27 -0000 On Mon, Sep 10, 2012 at 9:50 AM, Martin Thomson wrote: > I think that the work is valuable and useful. > > However, I have concerns about how priorities are communicated to the browser. > > I know that this introduces an interesting case of where the > artificial division of labour between rtcweb and WebRTC breaks down, > but the recent ruling in the W3C implies that this would require SDP > work (unless there is something that I missed). That would then imply > that this (new) work doesn't fit the rtweb charter and should go to > MMUSIC. Why would this require SDP work? I would assume that this would be a setting on the media stream/track. or alternately, a hint. -Ekr From martin.thomson@gmail.com Mon Sep 10 10:43:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90721E8045 for ; Mon, 10 Sep 2012 10:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-WlqUNs8IOv for ; Mon, 10 Sep 2012 10:43:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3882021E8041 for ; Mon, 10 Sep 2012 10:43:39 -0700 (PDT) Received: by lahm15 with SMTP id m15so1422313lah.31 for ; Mon, 10 Sep 2012 10:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cKw7lkzR2Ciuf+bfujo00YLoDPbj/OT6yalxaJ2D+Co=; b=Jz6P12BtNh/s18kjCCl4+nw25mivLNrs1j46K6/sA/yURU7mUk1lXfKTxNrC65BURc /mswax5OZGZ35X8usD8D05aqTEioDbVLQJiT9vph5XAAnkOe40m7z6R31MdCtYKQXLA3 UxOXUI7yw1IXwdilo9zoVVGUF7P4goQbRKgZnXDbDZ1AnoXHTrrPaUy97kjwjkvFsATM IcJPBcMV9szvuPKQBYr0N6tY4wHSNVYWY4yqyHRwOezCBGDqeCzGQ4CE25uKJYvn6UMy IT/VDiXeWYFhsKW2F7MCejqm0LNkdsWxNzpsgTJ/P9uXDoI3t01/9yT1o2eGkma49zVJ aMHQ== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr5224020lbf.123.1347299018105; Mon, 10 Sep 2012 10:43:38 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 10:43:38 -0700 (PDT) In-Reply-To: References: <504DF4F4.9080401@alvestrand.no> Date: Mon, 10 Sep 2012 10:43:38 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:43:40 -0000 On 10 September 2012 09:54, Eric Rescorla wrote: > Why would this require SDP work? > > I would assume that this would be a setting on the media stream/track. > or alternately, a hint. You could, but that means that you have a more complicated API to use. You have to set priority locally, signal the chosen priority, set the signalled priority, etc... As a session characteristic, I assumed that you would want to put it in the SDP. Or is this something that is extra specific to WebRTC such that you don't want to provide this to other SDP users? --Martin From ekr@rtfm.com Mon Sep 10 10:52:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECFB21E8050 for ; Mon, 10 Sep 2012 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 kiXWssgXMGPD for ; Mon, 10 Sep 2012 10:52:22 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD621E8041 for ; Mon, 10 Sep 2012 10:52:21 -0700 (PDT) Received: by weyu54 with SMTP id u54so1492285wey.31 for ; Mon, 10 Sep 2012 10:52:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=pcsow6KB+nzFqX2uiJXriJev/SrzTnRYt2CA8WVTFLM=; b=N97+qDyZ0AbFAmriJVGDJYuxrvJ9g4I0wnSCklFuNiI97Ts7UyLus74rY8b7q4sWDA w8YdvLP+86QZOXj6DfJFDMQZQpSl9fzIpuRVK8qiUydLcQ7wRnMSPhhngd9JOvs6BLgC /VafLUT8xT+jHi18doSBimr3BxZpFAvHxYzI1+4t/NYHiLlXGufVzB1jotTLIDidRuz7 MH1khb2cKEPkJbHMiXXeCTPwASDKUwijYPulBICSQszwFQ4yuGp4bTkya2x7510x5WL1 oH9sygzZJX32aFkHGwnQ8h1+Aq1uVxd/LPESVJStdaU64pKLOdEzD09hTYZJ9pgwCcgE x6ug== Received: by 10.180.106.97 with SMTP id gt1mr18771078wib.5.1347299540843; Mon, 10 Sep 2012 10:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.1.197 with HTTP; Mon, 10 Sep 2012 10:51:40 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <504DF4F4.9080401@alvestrand.no> From: Eric Rescorla Date: Mon, 10 Sep 2012 10:51:40 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmRd8s3agJCBHldGZZ1BbOEf9S0381hSz6rCGTS0TffXKH6NGConL7xVsm6iXXwcP4Ashy+ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:52:22 -0000 On Mon, Sep 10, 2012 at 10:43 AM, Martin Thomson wrote: > On 10 September 2012 09:54, Eric Rescorla wrote: >> Why would this require SDP work? >> >> I would assume that this would be a setting on the media stream/track. >> or alternately, a hint. > > You could, but that means that you have a more complicated API to use. > You have to set priority locally, signal the chosen priority, set the > signalled priority, etc... It's not clear to me that these values need to be the same on both sides. But if it *is* true that we want that, then of course it should be in SDP so that the functionality is available to endpoints that don't have anything to do with WebRTC. -Ekr From jmpolk@cisco.com Mon Sep 10 14:13:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297ED21F8514 for ; Mon, 10 Sep 2012 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJBgldTFj5PK for ; Mon, 10 Sep 2012 14:13:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8A21F8512 for ; Mon, 10 Sep 2012 14:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1236; q=dns/txt; s=iport; t=1347311582; x=1348521182; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=myPCXW42xMoBiYGvt4oR+FqAaAPJVrvOEovucWfunlg=; b=g/Xfv4kaRE+WH6LXuyyT9hjS0bQwySkBb9W2uLRZS6kjY/JFVF/jszp3 4p2T3hlbD766BW4P4BU4UU3iWamn1hOKYw9T29symWxsMj/sxkeufTUHN IgeeVfLl0GHPEDzARy+kr+N706JE7u8E3MGCjncIVdDxFQTE+E7ajNMMe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMJWTlCrRDoH/2dsb2JhbABFu1iBB4IgAQEBBAEBAQ8BChsCNAsQBwQOCh4QGQgGMAYBEgkZh1wDDgybVpY+DYlTiiljhjYDiFOLNYxqgyGBZ4ME X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="57750160" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 10 Sep 2012 21:13:01 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8ALD0qQ018125; Mon, 10 Sep 2012 21:13:00 GMT Message-Id: <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Sep 2012 16:12:58 -0500 To: Eric Rescorla , Martin Thomson From: James Polk In-Reply-To: References: <504DF4F4.9080401@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:13:03 -0000 At 12:51 PM 9/10/2012, Eric Rescorla wrote: >On Mon, Sep 10, 2012 at 10:43 AM, Martin Thomson > wrote: > > On 10 September 2012 09:54, Eric Rescorla wrote: > >> Why would this require SDP work? > >> > >> I would assume that this would be a setting on the media stream/track. > >> or alternately, a hint. > > > > You could, but that means that you have a more complicated API to use. > > You have to set priority locally, signal the chosen priority, set the > > signalled priority, etc... > >It's not clear to me that these values need to be the same on both >sides. > >But if it *is* true that we want that, then of course it should be in SDP so >that the functionality is available to endpoints that don't have anything >to do with WebRTC.' MMUSIC has a WG item that should provide this indication/hint, in a trafficclass label attribute. Browsers identifying a small set of labels from that effort should do the trick. See http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-02.txt James >-Ekr >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Mon Sep 10 14:27:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300B21F859E for ; Mon, 10 Sep 2012 14:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFBrYUWAjgxy for ; Mon, 10 Sep 2012 14:27:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7525F21F858F for ; Mon, 10 Sep 2012 14:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1949; q=dns/txt; s=iport; t=1347312475; x=1348522075; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=H4YGAid0nNudf1rVZTtQqNhSQzJX6E/pmcPwo+2beLk=; b=Epb3GRRBcFgKYF67/+lk9rv77dTd4VXP6WznKBwDYlSa2fRFwOiTU+oE nH75NwixTInXiWFk2dyCYBUwrMQg6dTm8kuZ/Q+Pz48Axf7kQpbRPyXZR GVgc4AhfVLHtq/7LW27HslFF7KadOivXbhofWGXoApn7ygt/s2r2CQBUc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEVaTlCrRDoJ/2dsb2JhbABFq1eQAYEHgiABAQEDAQEBAQUKAQoNEDQLBQcBAwIJDgECBAEBAScHGQgGFQoJCAEBBAESCxeHXAMJBQybVpZBDYlPBIopY4Y2A4hThQ6GJ4xqgyGBZ4MG X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="55251999" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Sep 2012 21:27:53 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8ALRrIf009766; Mon, 10 Sep 2012 21:27:53 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Martin Thomson'" References: <504DF4F4.9080401@alvestrand.no> In-Reply-To: Date: Mon, 10 Sep 2012 14:27:53 -0700 Message-ID: <045601cd8f9b$23435310$69c9f930$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2PfQpLSuDBffVpQNaqEdI8K9BmbwAHXltA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:27:56 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Monday, September 10, 2012 10:52 AM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for adoption of QoS draft > > On Mon, Sep 10, 2012 at 10:43 AM, Martin Thomson > wrote: > > On 10 September 2012 09:54, Eric Rescorla wrote: > >> Why would this require SDP work? > >> > >> I would assume that this would be a setting on the media > stream/track. > >> or alternately, a hint. > > > > You could, but that means that you have a more complicated API to > use. > > You have to set priority locally, signal the chosen priority, set > the > > signalled priority, etc... > > It's not clear to me that these values need to be the same on both > sides. They don't need to be the same. But, once a packet comes into a network that needs a certain DSCP value to get certain quality of service, the packet needs to be treated accordingly. For example, let's say Alice and Bob are on different networks. Someone decided Alice's network needs DSCP of "1" for its high priority traffic, and someone else decided Bob's network needs DSCP of "2" for high priority traffic. When Alice and Bob have a real time phone call with each other, their outgoing packets will receive QoS treatment, but the incoming packets won't. Do the network managers that configured Alice and Bob's network need to use the same DSCP configuration, or do we want to solve this some other way? -d > But if it *is* true that we want that, then of course it should be in > SDP so > that the functionality is available to endpoints that don't have > anything > to do with WebRTC. > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Mon Sep 10 14:28:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF52221F8762 for ; Mon, 10 Sep 2012 14:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XkxRdOvW9eH for ; Mon, 10 Sep 2012 14:28:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAA4121F8760 for ; Mon, 10 Sep 2012 14:27:59 -0700 (PDT) Received: by lbky2 with SMTP id y2so1661612lbk.31 for ; Mon, 10 Sep 2012 14:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DIC1RP+9nTMeiI6hKVskMgnXby1zLVFcAgVvVHbCQRU=; b=IT+89SAEVblS7520mcxFWVmHwpKgxXWHpqC0H484iOLH8vwJDrjxQVDP4VbkczfQ1r vWIMuuhyBUy8L0bH3DS4TYGNPKAn3HQhZW+U+Ax/5JePrbVva1OT2d7wXCSMheO/NFop JyCf7goRB/Ga82IGyxp6v5RtGO1xQKQSBTicyVqTTLLNSjl3t7/T+qqlsV+7ZxW8YvXw bC9z/bvICZi/VdlN6aDpEWgeOGa6Ogw1vmbtS9+3fABtXVa4Xka54Fxd3mRJBF/8e1D/ pmDFLZcrXC+avTWOONi2kXtVCQbE4rPJQDT5HQXur+Em0PKjyXOSTuMzkTPQDs8+URbz LDdw== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr13746976lab.30.1347312478889; Mon, 10 Sep 2012 14:27:58 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 14:27:58 -0700 (PDT) In-Reply-To: <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> References: <504DF4F4.9080401@alvestrand.no> <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> Date: Mon, 10 Sep 2012 14:27:58 -0700 Message-ID: From: Martin Thomson To: James Polk Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:28:00 -0000 On 10 September 2012 14:12, James Polk wrote: > MMUSIC has a WG item that should provide this indication/hint, in a > trafficclass label attribute. Browsers identifying a small set of labels > from that effort should do the trick. See > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-02.txt Thanks James, that looks like what is needed. It's not exactly the same thing as the priority draft, so I'm not sure how I'd map all the way from priority (1-3) to traffic class labels to the DSCP markings described in Cullen's draft. It looks like some more definition work is needed. From jmpolk@cisco.com Mon Sep 10 17:23:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AC121F864A for ; Mon, 10 Sep 2012 17:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIBwsE7n0dsS for ; Mon, 10 Sep 2012 17:23:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 875D021F870E for ; Mon, 10 Sep 2012 17:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2162; q=dns/txt; s=iport; t=1347323038; x=1348532638; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=YyqhRDDgc/AndwAgByUr3v6CAFmDvaGTgiUWGkDwmLY=; b=TDqYwgZUjxvnSQjTJ6Apoujo24h9qROnmzs/6emSihAI1r05uDXT9Ji0 Sp6o9VcfjkOUQ0jBpy6mxOPH7R35pgc7DngP9Lp56ZR+j3KOZUJW2QEKa J4q5sARPh4i+R3xEI7zBoXP/I1Cyfya5C8KVH5NfvCml3V1fTXqjBu+Mn o=; X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="55268557" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Sep 2012 00:16:27 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8B0GQ6x025835; Tue, 11 Sep 2012 00:16:26 GMT Message-Id: <201209110016.q8B0GQ6x025835@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Sep 2012 19:16:25 -0500 To: Martin Thomson From: James Polk In-Reply-To: References: <504DF4F4.9080401@alvestrand.no> <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 00:23:59 -0000 At 04:27 PM 9/10/2012, Martin Thomson wrote: >On 10 September 2012 14:12, James Polk wrote: > > MMUSIC has a WG item that should provide this indication/hint, in a > > trafficclass label attribute. Browsers identifying a small set of labels > > from that effort should do the trick. See > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-02.txt > >Thanks James, that looks like what is needed. It's not exactly the >same thing as the priority draft, so I'm not sure how I'd map all the >way from priority (1-3) to traffic class labels to the DSCP markings >described in Cullen's draft. I'm not sure only 3 priorities are needed, though I believe 3 will get used. The point of the trafficclass labels (TCL) is to add a level of abstraction to what the actual DSCPs need to be by allowing each domain that is aware of the type of traffic choose the appropriate DSCP for that type of traffic. After all, some bright spark might just come along and suggest that even though RTCweb uses the same 5-tuple for all traffic, they propose that the audio packets use a different DSCP than the video packets. Further, someone might consider the type of AV conference they are in to determine which DSCP they are to use. Say the difference between a small window av call and an immersive telepresence room experience? Both types of calls have the exact same types of packets (audio and video, and maybe preservation sharing or whiteboarding). Another is Dan's point in which Alice uses her highest priority marking (DSCP 1) when she contacts Bob, who uses his highest priority marking (DSCP 2) for the same call. Now, which DSCP is the highest priority marking, 1 or 2? Does it depend on the network/domain the packet is in? The TCL draft explores that, and we already have customer feedback that's caused us to allow greater flexibility than we originally planned. >It looks like some more definition work is needed. perhaps, and I'm not at all opposed to comments to the TCL draft within MMUSIC to address whatever folks think is important. James From martin.thomson@gmail.com Mon Sep 10 17:30:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834AB21F8701 for ; Mon, 10 Sep 2012 17:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2viQ9fQL4+2 for ; Mon, 10 Sep 2012 17:30:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA79221F84B6 for ; Mon, 10 Sep 2012 17:30:08 -0700 (PDT) Received: by lbky2 with SMTP id y2so14811lbk.31 for ; Mon, 10 Sep 2012 17:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O/KxgWowQNsibc9Geg5d4uUn8E1o1lVOpEBXR7hRqj4=; b=iCHpxZuyHnZXsN7Zcskyc0bqa9SzmY5cE7O8b5ceHcqMViZcj8zdk2CzXRZstdTyKW 9DGCoSd9hJk6WOXvg1ViDRM5f5A0/es0tgwUmuNq5eXLpzSSc28CHI837Fw8qvxyH9Ba pbYZdbqw+DKbMSS9znTBmjSOkai6CGaTmNaJVXBcU43YfwDeRbz8dGCNz9e6rLWxLHPU lpI3ZtRGD9msMB+hyjNYXMklofrDywNmKE8IQretpJebQdg8i2PhFb2vJszVvatxF0l6 QlNZUR867mLIijv+6s/GHB3GgoA0NEFMCTxFsFX3ybIa5wD5vsE6bVx88gkjEBNTA6gx pDNQ== MIME-Version: 1.0 Received: by 10.112.38.228 with SMTP id j4mr5478776lbk.111.1347323407499; Mon, 10 Sep 2012 17:30:07 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 17:30:07 -0700 (PDT) Date: Mon, 10 Sep 2012 17:30:07 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla , rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 00:30:10 -0000 What specific properties of a STUN Binding request does the browser use to determine that the peer has consented to receive packets? >From what I can infer, it's simply the existence of a response. That is insufficient. -security says: [...] ICE provides this verification as well, by using the STUN credentials as a form of per-session shared secret. Those credentials are known to the Web application, but would need to also be known and used by the STUN-receiving element to be useful. But that's not strictly correct. The Binding response necessarily does not include MESSAGE-INTEGRITY, which is the critical tie to per-session credentials. What then would prevent the browser from mistaking a response from a STUN server as consent? The STUN server doesn't need to check MESSAGE-INTEGRITY and USERNAME is systematically ignored where it is not used, so we can't rely on the server doing something helpful for itself. I imagine that stunserver.org could be made safe because it doesn't provide FINGERPRINT in responses (it's 3489 compliant, not 5389). But what a 5389 STUN server? Hopefully, I'm just missing something. But this has been bugging me. --Martin From martin.thomson@gmail.com Mon Sep 10 17:32:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F6F21F862A for ; Mon, 10 Sep 2012 17:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7YyAwpIsNIO for ; Mon, 10 Sep 2012 17:32:42 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94AB321F861F for ; Mon, 10 Sep 2012 17:32:41 -0700 (PDT) Received: by lahm15 with SMTP id m15so1665222lah.31 for ; Mon, 10 Sep 2012 17:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d5dlIFQKB1hMFm3bb3HCk3FCY0UsUXAACRGOnVyv0/Q=; b=N8jOgP3n48ytkcsehsOHw1bJJNoW94axNs0H/VUp5ghryueewDRwuNtxhUe9xJ/Mfe AmgEGY3KjJY5/KYAOILZ99iU2S/FsYEphZn6jKfNJ8pR/RUeKDuZSGVN/2DylQy8il38 b2UUO9Ux5Wm2pKpM9O+0qDZSPyVutYuCcJhBE6PiKCApie0At5u3FxAnJDi6M20BtT/8 CjrRun3i4Tdu7lyHKzni1zsWufSY0yUL3Y1oFGy+CGvbxKPQxLPVVyamebzzdcSKpy89 czBBt/4KOGAnA8w7iR82bKIMjm6EZKJ0DMC+K8la1gBQ1phM0H94jpM3q+f5Q+ySc+6e XCjQ== MIME-Version: 1.0 Received: by 10.152.123.133 with SMTP id ma5mr14122805lab.8.1347323560526; Mon, 10 Sep 2012 17:32:40 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 10 Sep 2012 17:32:40 -0700 (PDT) In-Reply-To: <201209110016.q8B0GQ6x025835@mtv-core-2.cisco.com> References: <504DF4F4.9080401@alvestrand.no> <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> <201209110016.q8B0GQ6x025835@mtv-core-2.cisco.com> Date: Mon, 10 Sep 2012 17:32:40 -0700 Message-ID: From: Martin Thomson To: James Polk Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 00:32:42 -0000 On 10 September 2012 17:16, James Polk wrote: > At 04:27 PM 9/10/2012, Martin Thomson wrote: >> It looks like some more definition work is needed. > > perhaps, and I'm not at all opposed to comments to the TCL draft within > MMUSIC to address whatever folks think is important. I don't think that this necessarily translates to TCL draft work. More that it is becoming clear to me that the qos draft is both a) new, and b) not in alignment with the TCL stuff. I'd be happy to be convinced otherwise, and I'm sure that it can be rectified. From ekr@rtfm.com Mon Sep 10 17:45:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9521F871C for ; Mon, 10 Sep 2012 17:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 VjiekElkIgAR for ; Mon, 10 Sep 2012 17:45:28 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8604721F871A for ; Mon, 10 Sep 2012 17:45:28 -0700 (PDT) Received: by eekb45 with SMTP id b45so1626945eek.31 for ; Mon, 10 Sep 2012 17:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=/ERAj7ELPgN06DNIVQvWbCPl/+a4bghCk6Hh4Ov0lJg=; b=MMdvYB9wsh9dQtnukSPq3NS/OymXGX8dyDD89jSlAXCbq1+/cIPf2gI/6eGQXNvUED rjbdtY2fL5AcJyZyRW2oEcSdfw0cUSpIxTV9V2daAlQAVn2x++vgTdwZwShNp8JaV0dD 6Es7cFlniqxg7cn25IJZ1OVcBkjVFUOzljJ9JKXVpmczRYaomDt/T5P+4M9KXJYlwTNq dHPNNLWhPsPNRKPAWUmVkOqoNuOlhb7gLdKozLrwSXmqAwoNtTL7t03i3U4aGi8tmPZ2 GFDiFQ6uM5Skvof95ErtLD9U3D5f8RTb1WA9cfvyO8MoFCbfqc2C7jZj3DwOf+59BtgW WVtg== Received: by 10.14.173.131 with SMTP id v3mr16898688eel.15.1347324327661; Mon, 10 Sep 2012 17:45:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Mon, 10 Sep 2012 17:44:47 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Sep 2012 17:44:47 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnpUDRB1hU1e+olVZ4bDU6y9weWtftcFzL7zcGvJRYnrDCwJg48FR7hhqI3pNKMcfMZQcZi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 00:45:29 -0000 On Mon, Sep 10, 2012 at 5:30 PM, Martin Thomson wrote: > What specific properties of a STUN Binding request does the browser > use to determine that the peer has consented to receive packets? > > From what I can infer, it's simply the existence of a response. That > is insufficient. > > -security says: > [...] ICE provides this verification as > well, by using the STUN credentials as a form of per-session shared > secret. Those credentials are known to the Web application, but > would need to also be known and used by the STUN-receiving element to > be useful. > > But that's not strictly correct. The Binding response necessarily > does not include MESSAGE-INTEGRITY, which is the critical tie to > per-session credentials. You lost me here. RFC 5389 specifically requires that if the client provided MESSAGE-INTEGRITY in the Binding Response in S 10.1.2: If these checks pass, the agent continues to process the request or indication. Any response generated by a server MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. The response MUST NOT contain the USERNAME attribute. And the client is required to check it in 10.1.3: 10.1.3. Receiving a Response The client looks for the MESSAGE-INTEGRITY attribute in the response. If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue. -Ekr From martin.thomson@gmail.com Tue Sep 11 09:09:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D821F86FC for ; Tue, 11 Sep 2012 09:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EWTT50T7rbts for ; Tue, 11 Sep 2012 09:09:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5F21F86F9 for ; Tue, 11 Sep 2012 09:09:01 -0700 (PDT) Received: by lahm15 with SMTP id m15so502419lah.31 for ; Tue, 11 Sep 2012 09:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wNXeMcxLHZR2KF4X/XBw//KfVM3S8Jn927/unyeb7Os=; b=PTjWKB2Nzgbwy5QCPIKvbF3KF20KylnVK9/qnncsNYP8QRb/tUK9I/UWgntECESvI9 hVsQN/y/PD33exAOPzUqYVSoHV6JVt5B+2z4wm+xOTAk723eZcuuTe2/F04PJ44k/ubN sBUA4veZ917GdK1gYZZ+LDfIlJqe4Vv2xP1VMq4g8TQlELcQsiJMxN6e/YXpZVxa25vy E7/F8xavWrPmU48Mb2agYiBQB9EtE35t/3095gq/xXyLfGMSkBZS8z+/eoBK/B4J9a21 AFG1OcADYCzeVMqncilBGLXFXb/Hq3iiH16FGdcO6D/jmyL0CqVB7gaDJWitnOVHHAxl /pzA== MIME-Version: 1.0 Received: by 10.112.27.69 with SMTP id r5mr6057652lbg.91.1347379740676; Tue, 11 Sep 2012 09:09:00 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Tue, 11 Sep 2012 09:09:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Sep 2012 09:09:00 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:09:03 -0000 Clearly, I did miss something. Obviously, this relates to the bit in ICE where it requires that the STUN backward compatibility measures are not used. But it didn't really answer my question. Clearly, an RFC 3489 STUN server will not pass this basic test. That means that we can safely exclude servers like stunserver.org from the set of consenting peers. I suspect that for practical reasons we have to tolerate missing MESSAGE-INTEGRITY and FINGERPRINT. That means we can at least use old servers to collect server reflexive addresses. For those old servers it's trivial to use the absence of either parameter as an indication that they do not provide consent. But the question stands: for STUN servers that are 5389 compliant, what distinguishes the STUN server from a consenting peer? --Martin p.s. I reached my conclusion for the following reasons: 1. Section 7.1.3.2 of RFC 5245, which I presumed to be complete...which it is, sort of. 2. MESSAGE-INTEGRITY is only of questionable utility in the response if you assume that the server is ignoring requests that don't have a valid MESSAGE-INTEGRITY. On 10 September 2012 17:44, Eric Rescorla wrote: > You lost me here. RFC 5389 specifically requires that if the > client provided MESSAGE-INTEGRITY in the Binding Response > in S 10.1.2: > > If these checks pass, the agent continues to process the request or > indication. Any response generated by a server MUST include the > MESSAGE-INTEGRITY attribute, computed using the password utilized to > authenticate the request. The response MUST NOT contain the USERNAME > attribute. > > And the client is required to check it in 10.1.3: > > 10.1.3. Receiving a Response > > The client looks for the MESSAGE-INTEGRITY attribute in the response. > If present, the client computes the message integrity over the > response as defined in Section 15.4, using the same password it > utilized for the request. If the resulting value matches the > contents of the MESSAGE-INTEGRITY attribute, the response is > considered authenticated. If the value does not match, or if > MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if > it was never received. This means that retransmits, if applicable, > will continue. > > > -Ekr From ekr@rtfm.com Tue Sep 11 09:23:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162221F865B for ; Tue, 11 Sep 2012 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 A+2Zw4NeXBLN for ; Tue, 11 Sep 2012 09:23:18 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB36321F8535 for ; Tue, 11 Sep 2012 09:23:17 -0700 (PDT) Received: by eekb45 with SMTP id b45so627835eek.31 for ; Tue, 11 Sep 2012 09:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Lw0qR2VCSbPLrJJfSxNoh3McLiX43ZHadqYlirFo4tE=; b=Xd/n/+XdRG87wiBMoG55HM6THIAzKDT1gibXsxHJbiu6+TBlR0NMumBSQPjjUR6ow9 NGSefZdWyxu4Q2WyApIL0alddxxXBZOK5oNtRZxZgbEd94JUpKRy3Nmw2mikiBF65STU rK/3LXdlLkmaGn9dxoVmcgNhhmLLXJRgO9DXXDaSQ9p5Px1UFTd8n0t+npca/oabVc0k iNq08dYGw1iNwgybPjDYY8o1W0CtwkmhqH0cdFbFAVHLL3caMfY4lnZoJyOw0fUGu8VN saSkiw4jB46zQxvLvnnwf1UogJTs+7k2X2cIiox1uy8vtx6C8tPlHqzPNBTJ9CoVOy7j w/OQ== Received: by 10.14.224.4 with SMTP id w4mr26734241eep.21.1347380596923; Tue, 11 Sep 2012 09:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Tue, 11 Sep 2012 09:22:36 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Tue, 11 Sep 2012 09:22:36 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk/O9bwDRRDy1N9qfRQol82bosxM2C98dGf0jZsK+Hl6bE93XYLGE+ciUTRIv7kjn9Pc3wF Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:23:19 -0000 On Tue, Sep 11, 2012 at 9:09 AM, Martin Thomson wrote: > Clearly, I did miss something. Obviously, this relates to the bit in > ICE where it requires that the STUN backward compatibility measures > are not used. > > But it didn't really answer my question. > > Clearly, an RFC 3489 STUN server will not pass this basic test. That > means that we can safely exclude servers like stunserver.org from the > set of consenting peers. > > I suspect that for practical reasons we have to tolerate missing > MESSAGE-INTEGRITY and FINGERPRINT. That means we can at least use old > servers to collect server reflexive addresses. For those old servers > it's trivial to use the absence of either parameter as an indication > that they do not provide consent. > > But the question stands: for STUN servers that are 5389 compliant, > what distinguishes the STUN server from a consenting peer? > > --Martin > > p.s. I reached my conclusion for the following reasons: > 1. Section 7.1.3.2 of RFC 5245, which I presumed to be > complete...which it is, sort of. > 2. MESSAGE-INTEGRITY is only of questionable utility in the response > if you assume that the server is ignoring requests that don't have a > valid MESSAGE-INTEGRITY. I'm really not following this. Responses from the server need to *contain* the MESSAGE-INTEGRITY field and otherwise are not taken as evidence of consent. This field can only be generated by a server that has the ICE credentials. So, obviously, a legacy STUN server won't generate that. -Ekr From martin.thomson@gmail.com Tue Sep 11 09:34:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8421B21F873C for ; Tue, 11 Sep 2012 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAFdd7dtPIW4 for ; Tue, 11 Sep 2012 09:34:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89D21F8738 for ; Tue, 11 Sep 2012 09:34:48 -0700 (PDT) Received: by lahm15 with SMTP id m15so520994lah.31 for ; Tue, 11 Sep 2012 09:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=StQ5vTGtPAQm4TT4OMHOZMb09MbdaHp2c7agg6W6Bds=; b=OzAmMXByDFSJQRPXwHU1kcsFeMEXpnrSB9ccoCP+Brxopr/FyXFY0XTChvG0qglULP 6fW0l62lbGO0qNnyo7BxV1ekKSUXFhJI7EFCJ+gnLd7nxqgqTcYCFuPDnsnvMogb9URo Wi6wQrgqoZgY7rOhc9Gyq1q7OmRDxTnHvQh6vp/V9/ZKXlJ/+EgWuh7aspHzZ1X2zy6M eaqdx6YQBNkUFMGWTUL3PUM12kDEJtF1ArUf99er/0LoOGCELAzPP5keuk9AVAKZguuY VbbJtLaqpuR1Hd1ruogWX4bRj8S1zm6s/2Hzonz7XisnekCgtB3eRtz/tE/8/xesNC3c mgZg== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr16252692lab.30.1347381287650; Tue, 11 Sep 2012 09:34:47 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Tue, 11 Sep 2012 09:34:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Sep 2012 09:34:47 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:34:49 -0000 On 11 September 2012 09:22, Eric Rescorla wrote: > I'm really not following this. > > Responses from the server need to *contain* the MESSAGE-INTEGRITY > field and otherwise are not taken as evidence of consent. This field can > only be generated by a server that has the ICE credentials. So, obviously, > a legacy STUN server won't generate that. It's clear that I'm just being thick. The STUN server (legacy or otherwise) won't have a password and wont generate MESSAGE-INTEGRITY. I apologise for wasting your (and everyone else's) time. From harald@alvestrand.no Tue Sep 11 09:49:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E530121F8773 for ; Tue, 11 Sep 2012 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f28UYT-9ysH for ; Tue, 11 Sep 2012 09:49:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5023921F871D for ; Tue, 11 Sep 2012 09:49:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E57239E194 for ; Tue, 11 Sep 2012 18:49:45 +0200 (CEST) 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 sbLiCFqFVaGl for ; Tue, 11 Sep 2012 18:49:44 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 10B2839E173 for ; Tue, 11 Sep 2012 18:49:44 +0200 (CEST) Message-ID: <504F6BB6.9050301@alvestrand.no> Date: Tue, 11 Sep 2012 18:49:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:49:47 -0000 On 09/11/2012 06:34 PM, Martin Thomson wrote: > On 11 September 2012 09:22, Eric Rescorla wrote: >> I'm really not following this. >> >> Responses from the server need to *contain* the MESSAGE-INTEGRITY >> field and otherwise are not taken as evidence of consent. This field can >> only be generated by a server that has the ICE credentials. So, obviously, >> a legacy STUN server won't generate that. > It's clear that I'm just being thick. > > The STUN server (legacy or otherwise) won't have a password and wont > generate MESSAGE-INTEGRITY. > > I apologise for wasting your (and everyone else's) time. The terms might have gotten confused, since STUN is used in two modes: - With a STUN server, to identify reflexive addresses - With a peer, to verify ability to communicate, and to verify continued consent. We don't want to mandate credentials for the first one. We do want to mandate credentials for the second. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Tue Sep 11 11:29:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF30521F862A for ; Tue, 11 Sep 2012 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9ehNzXK3m4e for ; Tue, 11 Sep 2012 11:29:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF521F8608 for ; Tue, 11 Sep 2012 11:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1635; q=dns/txt; s=iport; t=1347388169; x=1348597769; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=80FIFgil0NexWyXvoA0RPgGjnx6XHf/Hb/6O82UC1XI=; b=eGvBNfJW1eeg2yA0ClA9SchGLg/5lrLaD4RQT0nDvZfAnGniJfER9SaE G1+x/PjEeBxb+avPgvepklEiCxEVgYEI7w1iJKl6RkAOZ9vem2GSkZV8a SO8A4VSeOkGaBKBbHcXTS9VWTji4XzXi5yhfSyUp55UtaNAgEF+7PVtlD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAEWCT1CrRDoI/2dsb2JhbAA7Cqtcj3mBB4IgAQEBBAgKARcQPwwBAwIJDwIEAQEBGA8HGSMKCQgBAQQBEgsXh22bKqBTixAQgnmDHQOIVYUOljKBZ4MG X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="55362958" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 11 Sep 2012 18:29:28 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8BITSmA004277; Tue, 11 Sep 2012 18:29:28 GMT From: "Dan Wing" To: "'Harald Alvestrand'" , References: <504F6BB6.9050301@alvestrand.no> In-Reply-To: <504F6BB6.9050301@alvestrand.no> Date: Tue, 11 Sep 2012 11:29:28 -0700 Message-ID: <07c101cd904b$60bd2d50$223787f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2QPXaN9yJ05vyTRsGuoTSwXrvMaQADUE7A Content-Language: en-us Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:29:30 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Tuesday, September 11, 2012 9:50 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] What is consent? > > On 09/11/2012 06:34 PM, Martin Thomson wrote: > > On 11 September 2012 09:22, Eric Rescorla wrote: > >> I'm really not following this. > >> > >> Responses from the server need to *contain* the MESSAGE-INTEGRITY > >> field and otherwise are not taken as evidence of consent. This field > can > >> only be generated by a server that has the ICE credentials. So, > obviously, > >> a legacy STUN server won't generate that. > > It's clear that I'm just being thick. > > > > The STUN server (legacy or otherwise) won't have a password and wont > > generate MESSAGE-INTEGRITY. > > > > I apologise for wasting your (and everyone else's) time. > The terms might have gotten confused, since STUN is used in two modes: > > - With a STUN server, to identify reflexive addresses > - With a peer, to verify ability to communicate, and to verify > continued > consent. > > We don't want to mandate credentials for the first one. > We do want to mandate credentials for the second. Right. The confusion is that ICE uses the STUN protocol for two purposes: to collect reflexive addresses, and to perform connectivity checks with peers. In RTCWEB, we plan to additionally use connectivity checks for "consent", so the STUN protocol will be used for three different purposes. (And four if we count TURN, which also uses the STUN packet format.) -d From bernard_aboba@hotmail.com Tue Sep 11 12:29:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BE121F869E for ; Tue, 11 Sep 2012 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ax-GGPj9Ttu4 for ; Tue, 11 Sep 2012 12:29:19 -0700 (PDT) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9521F8672 for ; Tue, 11 Sep 2012 12:29:19 -0700 (PDT) Received: from BLU169-DS48 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Sep 2012 12:29:18 -0700 X-Originating-IP: [198.37.20.75] X-EIP: [NFMwI8Ayea9z/WVjd/xmmWCnnk0thVba] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Eric Rescorla'" References: In-Reply-To: Date: Tue, 11 Sep 2012 14:29:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuiFtacnnBjuI6raWX6lmK+8wORAGUpRMPAmkYFagCGeLX4JcS17FQ Content-Language: en-us X-OriginalArrivalTime: 11 Sep 2012 19:29:18.0965 (UTC) FILETIME=[BCE87A50:01CD9053] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:29:20 -0000 Eric Rescorla said: "Responses from the server need to *contain* the MESSAGE-INTEGRITY field and otherwise are not taken as evidence of consent. This field can only be generated by a server that has the ICE credentials. So, obviously, a legacy STUN server won't generate that." [BA] While the presence of the MESSAGE-INTEGRITY field is a necessary condition, is it sufficient to demonstrate consent? For example, does the nominated flag need to be set to true? RFC 5245 Section 7.1.3.2.4 says: 7.1.3.2.4. Updating the Nominated Flag If the agent was a controlling agent, and it had included a USE- CANDIDATE attribute in the Binding request, the valid pair generated from that check has its nominated flag set to true. This flag indicates that this valid pair should be used for media if it is the highest-priority one amongst those whose nominated flag is set. This may conclude ICE processing for this media stream or all media streams; see Section 8. If the agent is the controlled agent, the response may be the result of a triggered check that was sent in response to a request that itself had the USE-CANDIDATE attribute. This case is described in Section 7.2.1.5, and may now result in setting the nominated flag for the pair learned from the original request. From dwing@cisco.com Tue Sep 11 16:39:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9221E8040 for ; Tue, 11 Sep 2012 16:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEFAjwcpT0Gg for ; Tue, 11 Sep 2012 16:39:07 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5305421E8037 for ; Tue, 11 Sep 2012 16:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2077; q=dns/txt; s=iport; t=1347406747; x=1348616347; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=+m2Bb16L+IVBA/q9Avi1hIbMWmn0zpDXpCIHeyVUNp4=; b=eXuNSuBL9f/dvdwCBeqwQVqsrnSmYs3nRweK0ToqnJOJGnMuZPgaf0eF fAgoawoGi62/We8Q5VKL7jZzudkj4f7bphGj5PnddGr8TP9brfrQQUvg+ z8t4nIX1HxiGmcEQALRZXhNG9dqNwzRMfWlGIWpC4INSvfdCRJzLERexa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAKrKT1CrRDoI/2dsb2JhbABFq12PeoEHgiABAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgCBAESCxeHbZtToF+LEIYmA4hVhQ6WMoFngwY X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="54858856" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 11 Sep 2012 23:39:07 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8BNd6lr017953; Tue, 11 Sep 2012 23:39:06 GMT From: "Dan Wing" To: "'Bernard Aboba'" , "'Eric Rescorla'" References: In-Reply-To: Date: Tue, 11 Sep 2012 16:39:06 -0700 Message-ID: <08c301cd9076$a2405c40$e6c114c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHuiFtacnnBjuI6raWX6lmK+8wORAGUpRMPAmkYFagCGeLX4JcS17FQgABGtXA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:39:08 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Tuesday, September 11, 2012 12:29 PM > To: 'Eric Rescorla' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] What is consent? > > Eric Rescorla said: > > "Responses from the server need to *contain* the MESSAGE-INTEGRITY > field and > otherwise are not taken as evidence of consent. This field can only be > generated by a server that has the ICE credentials. So, obviously, a > legacy > STUN server won't generate that." > > [BA] While the presence of the MESSAGE-INTEGRITY field is a necessary > condition, is it sufficient to demonstrate consent? For example, does > the > nominated flag need to be set to true? RFC 5245 Section 7.1.3.2.4 > says: > > 7.1.3.2.4. Updating the Nominated Flag > > If the agent was a controlling agent, and it had included a USE- > CANDIDATE attribute in the Binding request, the valid pair generated > from that check has its nominated flag set to true. This flag > indicates that this valid pair should be used for media if it is the > highest-priority one amongst those whose nominated flag is set. > This > may conclude ICE processing for this media stream or all media > streams; see Section 8. > > If the agent is the controlled agent, the response may be the result > of a triggered check that was sent in response to a request that > itself had the USE-CANDIDATE attribute. This case is described in > Section 7.2.1.5, and may now result in setting the nominated flag > for > the pair learned from the original request. For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to keep other candidates available, but inactive. Over those other candidates we would not signal USE-CANDIDATE, but we would want to be able to switch to the other candidate as quickly as possible (ideally, switch over immediately). Similar considerations might apply to multipath RTP (draft-singh-avtcore-mprtp), too. -d From bernard_aboba@hotmail.com Tue Sep 11 20:27:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6621F84EF for ; Tue, 11 Sep 2012 20:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 oYlYna6xGWkv for ; Tue, 11 Sep 2012 20:27:48 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4D21F84EE for ; Tue, 11 Sep 2012 20:27:48 -0700 (PDT) Received: from BLU401-EAS382 ([65.55.116.74]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Sep 2012 20:27:47 -0700 X-Originating-IP: [173.167.136.97] X-EIP: [xOSGgiZ6DfgmkM3FqHjN8n1mvdp43Nnp] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <08c301cd9076$a2405c40$e6c114c0$@com> Content-Transfer-Encoding: 7bit From: Bernard Aboba Content-Type: multipart/alternative; boundary="Apple-Mail-AA5F853A-AEA5-47AE-9931-8F43B1FFB1BD" In-Reply-To: <08c301cd9076$a2405c40$e6c114c0$@com> Date: Tue, 11 Sep 2012 22:33:58 -0500 To: Eric Rescorla MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 12 Sep 2012 03:27:47.0700 (UTC) FILETIME=[94A5CB40:01CD9096] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 03:27:48 -0000 --Apple-Mail-AA5F853A-AEA5-47AE-9931-8F43B1FFB1BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" >> Dan Wing said: >=20 > For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to=20 > keep other candidates available, but inactive. Over those other > candidates we would not signal USE-CANDIDATE, but we would want to > be able to switch to the other candidate as quickly as possible > (ideally, switch over immediately). Similar considerations might=20 > apply to multipath RTP (draft-singh-avtcore-mprtp), too. >=20 > -d [BA] My question is whether the browser has a legitimate reason to send medi= a to a destination that is not part of a valid pair for which the nominated f= lag is set to true, as per RFC 5245 Section 7.1.3.2.4. For mobility you can= still signal USE-CANDIDATE but not use the pair if another pair had higher p= riority.=20= --Apple-Mail-AA5F853A-AEA5-47AE-9931-8F43B1FFB1BD Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIGNvbG9yPSIjMDAwMDAwIj5EYW4gV2luZyBzYWlkOjwvZm9udD48L2Jsb2Nr cXVvdGU+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5Gb3IgSUNFIE1vYmlsaXR5IChkcmFmdC13aW5n LW1tdXNpYy1pY2UtbW9iaWxpdHkpLCB3ZSBtaWdodCB3YW50IHRvIDwvc3Bhbj48YnI+PHNwYW4+ a2VlcCBvdGhlciBjYW5kaWRhdGVzIGF2YWlsYWJsZSwgYnV0IGluYWN0aXZlLiAmbmJzcDtPdmVy IHRob3NlIG90aGVyPC9zcGFuPjxicj48c3Bhbj5jYW5kaWRhdGVzIHdlIHdvdWxkIG5vdCBzaWdu YWwgVVNFLUNBTkRJREFURSwgYnV0IHdlIHdvdWxkIHdhbnQgdG88L3NwYW4+PGJyPjxzcGFuPmJl IGFibGUgdG8gc3dpdGNoIHRvIHRoZSBvdGhlciBjYW5kaWRhdGUgYXMgcXVpY2tseSBhcyBwb3Nz aWJsZTwvc3Bhbj48YnI+PHNwYW4+KGlkZWFsbHksIHN3aXRjaCBvdmVyIGltbWVkaWF0ZWx5KS4g Jm5ic3A7U2ltaWxhciBjb25zaWRlcmF0aW9ucyBtaWdodCA8L3NwYW4+PGJyPjxzcGFuPmFwcGx5 IHRvIG11bHRpcGF0aCBSVFAgKGRyYWZ0LXNpbmdoLWF2dGNvcmUtbXBydHApLCB0b28uPC9zcGFu Pjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPi1kPC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVv dGU+PGJyPjxkaXY+W0JBXSBNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBicm93c2VyIGhhcyBh IGxlZ2l0aW1hdGUgcmVhc29uIHRvIHNlbmQgbWVkaWEgdG8gYSBkZXN0aW5hdGlvbiB0aGF0IGlz IG5vdCBwYXJ0IG9mIGEgdmFsaWQgcGFpciBmb3Igd2hpY2ggdGhlIG5vbWluYXRlZCBmbGFnIGlz IHNldCB0byB0cnVlLCBhcyBwZXIgUkZDIDUyNDUgU2VjdGlvbiA3LjEuMy4yLjQuICZuYnNwO0Zv ciBtb2JpbGl0eSB5b3UgY2FuIHN0aWxsIHNpZ25hbCBVU0UtQ0FORElEQVRFIGJ1dCBub3QgdXNl IHRoZSBwYWlyIGlmIGFub3RoZXIgcGFpciBoYWQgaGlnaGVyIHByaW9yaXR5LiZuYnNwOzwvZGl2 PjwvYm9keT48L2h0bWw+ --Apple-Mail-AA5F853A-AEA5-47AE-9931-8F43B1FFB1BD-- From lishitao@huawei.com Tue Sep 11 23:51:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2921F8605 for ; Tue, 11 Sep 2012 23:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8gvB4+0kwwDF for ; Tue, 11 Sep 2012 23:51:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F050821F85C0 for ; Tue, 11 Sep 2012 23:51:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJO89857; Wed, 12 Sep 2012 06:51:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:50:46 +0100 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:50:49 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Wed, 12 Sep 2012 14:50:42 +0800 From: Lishitao To: Bernard Aboba Thread-Topic: [rtcweb] What is consent? Thread-Index: AQHNj7SjHY21K5ss2Ue6YzQkrQ5VYpeDx8OAgAECOQCAAAPNAIAANCUAgABF0ACAAEGfAIAAvARA Date: Wed, 12 Sep 2012 06:50:43 +0000 Message-ID: References: <08c301cd9076$a2405c40$e6c114c0$@com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: multipart/alternative; boundary="_000_DA165A8A2929C6429CAB403A76B573A5146A00B9szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 06:51:38 -0000 --_000_DA165A8A2929C6429CAB403A76B573A5146A00B9szxeml534mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAxMiwgMjAxMiAxMTozNCBBTQ0KVG86IEVyaWMgUmVzY29ybGENCkNjOiBydGN3ZWJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IGlzIGNvbnNlbnQ/DQoNCkRhbiBX aW5nIHNhaWQ6DQoNCkZvciBJQ0UgTW9iaWxpdHkgKGRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2Jp bGl0eSksIHdlIG1pZ2h0IHdhbnQgdG8NCmtlZXAgb3RoZXIgY2FuZGlkYXRlcyBhdmFpbGFibGUs IGJ1dCBpbmFjdGl2ZS4gIE92ZXIgdGhvc2Ugb3RoZXINCmNhbmRpZGF0ZXMgd2Ugd291bGQgbm90 IHNpZ25hbCBVU0UtQ0FORElEQVRFLCBidXQgd2Ugd291bGQgd2FudCB0bw0KYmUgYWJsZSB0byBz d2l0Y2ggdG8gdGhlIG90aGVyIGNhbmRpZGF0ZSBhcyBxdWlja2x5IGFzIHBvc3NpYmxlDQooaWRl YWxseSwgc3dpdGNoIG92ZXIgaW1tZWRpYXRlbHkpLiAgU2ltaWxhciBjb25zaWRlcmF0aW9ucyBt aWdodA0KYXBwbHkgdG8gbXVsdGlwYXRoIFJUUCAoZHJhZnQtc2luZ2gtYXZ0Y29yZS1tcHJ0cCks IHRvby4NCg0KLWQNCg0KW0JBXSBNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBicm93c2VyIGhh cyBhIGxlZ2l0aW1hdGUgcmVhc29uIHRvIHNlbmQgbWVkaWEgdG8gYSBkZXN0aW5hdGlvbiB0aGF0 IGlzIG5vdCBwYXJ0IG9mIGEgdmFsaWQgcGFpciBmb3Igd2hpY2ggdGhlIG5vbWluYXRlZCBmbGFn IGlzIHNldCB0byB0cnVlLCBhcyBwZXIgUkZDIDUyNDUgU2VjdGlvbiA3LjEuMy4yLjQuICBGb3Ig bW9iaWxpdHkgeW91IGNhbiBzdGlsbCBzaWduYWwgVVNFLUNBTkRJREFURSBidXQgbm90IHVzZSB0 aGUgcGFpciBpZiBhbm90aGVyIHBhaXIgaGFkIGhpZ2hlciBwcmlvcml0eS4NCg0KDQpJIGRvbm90 IHRoaW5rIHJmYyA1MjQ1IGFsbG93cyB0aGlzLCBpdCBvbmx5IGFsbG93IG9ubHkgb25lIHBhaXIg d2l0aCB0aGUgVVNFLUNBTkRJREFURSBhdHRyaWJ1dGUgcHJlc2VudC4NCg0K --_000_DA165A8A2929C6429CAB403A76B573A5146A00B9szxeml534mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmFyZCBBYm9iYTxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMTozNCBBTTxicj4NCjxiPlRvOjwvYj4g RXJpYyBSZXNjb3JsYTxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0IGlzIGNvbnNlbnQ/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbiBXaW5n IHNhaWQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KRm9yIElDRSBNb2JpbGl0eSAoZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5KSwgd2Ug bWlnaHQgd2FudCB0byA8YnI+DQprZWVwIG90aGVyIGNhbmRpZGF0ZXMgYXZhaWxhYmxlLCBidXQg aW5hY3RpdmUuICZuYnNwO092ZXIgdGhvc2Ugb3RoZXI8YnI+DQpjYW5kaWRhdGVzIHdlIHdvdWxk IG5vdCBzaWduYWwgVVNFLUNBTkRJREFURSwgYnV0IHdlIHdvdWxkIHdhbnQgdG88YnI+DQpiZSBh YmxlIHRvIHN3aXRjaCB0byB0aGUgb3RoZXIgY2FuZGlkYXRlIGFzIHF1aWNrbHkgYXMgcG9zc2li bGU8YnI+DQooaWRlYWxseSwgc3dpdGNoIG92ZXIgaW1tZWRpYXRlbHkpLiAmbmJzcDtTaW1pbGFy IGNvbnNpZGVyYXRpb25zIG1pZ2h0IDxicj4NCmFwcGx5IHRvIG11bHRpcGF0aCBSVFAgKGRyYWZ0 LXNpbmdoLWF2dGNvcmUtbXBydHApLCB0b28uPGJyPg0KPGJyPg0KLWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltCQV0gTXkgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGUgYnJvd3NlciBoYXMgYSBsZWdpdGltYXRlIHJlYXNvbiB0byBzZW5kIG1lZGlhIHRv IGEgZGVzdGluYXRpb24gdGhhdCBpcyBub3QgcGFydCBvZiBhIHZhbGlkIHBhaXIgZm9yIHdoaWNo IHRoZSBub21pbmF0ZWQgZmxhZyBpcyBzZXQgdG8gdHJ1ZSwgYXMgcGVyIFJGQyA1MjQ1IFNlY3Rp b24gNy4xLjMuMi40LiAmbmJzcDtGb3IgbW9iaWxpdHkNCiB5b3UgY2FuIHN0aWxsIHNpZ25hbCBV U0UtQ0FORElEQVRFIGJ1dCBub3QgdXNlIHRoZSBwYWlyIGlmIGFub3RoZXIgcGFpciBoYWQgaGln aGVyIHByaW9yaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbm90IHRoaW5rIHJmYyA1MjQ1IGFsbG93cyB0aGlzLCBp dCBvbmx5IGFsbG93IG9ubHkgb25lIHBhaXIgd2l0aCB0aGUgVVNFLUNBTkRJREFURSBhdHRyaWJ1 dGUgcHJlc2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DA165A8A2929C6429CAB403A76B573A5146A00B9szxeml534mbxchi_-- From bernard_aboba@hotmail.com Wed Sep 12 05:10:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5121F859C for ; Wed, 12 Sep 2012 05:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 92z7v1H9WffI for ; Wed, 12 Sep 2012 05:10:56 -0700 (PDT) Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C521F8564 for ; Wed, 12 Sep 2012 05:10:56 -0700 (PDT) Received: from BLU401-EAS460 ([65.55.116.72]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Sep 2012 05:10:55 -0700 X-Originating-IP: [173.167.136.97] X-EIP: [/7vMf18UIuJqCc9E+6k6+fasPhjg8Jg2] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <08c301cd9076$a2405c40$e6c114c0$@com> Content-Transfer-Encoding: 7bit From: Bernard Aboba Content-Type: multipart/alternative; boundary="Apple-Mail-82910280-CD0E-4F80-9002-C682946A0AF1" In-Reply-To: Date: Wed, 12 Sep 2012 07:17:07 -0500 To: Lishitao MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 12 Sep 2012 12:10:55.0914 (UTC) FILETIME=[A97B28A0:01CD90DF] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:10:57 -0000 --Apple-Mail-82910280-CD0E-4F80-9002-C682946A0AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sep 12, 2012, at 1:51, "Lishitao" wrote: > Dan Wing said: >=20 > For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to=20 > keep other candidates available, but inactive. Over those other > candidates we would not signal USE-CANDIDATE, but we would want to > be able to switch to the other candidate as quickly as possible > (ideally, switch over immediately). Similar considerations might=20 > apply to multipath RTP=20 > [BA] My question is whether the browser has a legitimate reason to send me= dia to a destination that is not part of a valid pair for which the nominate= d flag is set to true, as per RFC 5245 Section 7.1.3.2.4. For mobility you c= an still signal USE-CANDIDATE but not use the pair if another pair had highe= r priority.=20 > =20 > =20 > I donot think rfc 5245 allows this, it only allow only one pair with the U= SE-CANDIDATE attribute present. [BA] But in that case you would want to use the pair, no?= --Apple-Mail-82910280-CD0E-4F80-9002-C682946A0AF1 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6 IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29s b3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZy YW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPk9uIFNlcCAxMiwgMjAx MiwgYXQgMTo1MSwgIkxpc2hpdGFvIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpc2hpdGFvQGh1YXdl aS5jb20iPmxpc2hpdGFvQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJyPjwvZGl2 PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9 IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSki Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg NCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RGFuIFdpbmcgc2Fp ZDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpG b3IgSUNFIE1vYmlsaXR5IChkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkpLCB3ZSBtaWdo dCB3YW50IHRvIDxicj4NCmtlZXAgb3RoZXIgY2FuZGlkYXRlcyBhdmFpbGFibGUsIGJ1dCBpbmFj dGl2ZS4gJm5ic3A7T3ZlciB0aG9zZSBvdGhlcjxicj4NCmNhbmRpZGF0ZXMgd2Ugd291bGQgbm90 IHNpZ25hbCBVU0UtQ0FORElEQVRFLCBidXQgd2Ugd291bGQgd2FudCB0bzxicj4NCmJlIGFibGUg dG8gc3dpdGNoIHRvIHRoZSBvdGhlciBjYW5kaWRhdGUgYXMgcXVpY2tseSBhcyBwb3NzaWJsZTxi cj4NCihpZGVhbGx5LCBzd2l0Y2ggb3ZlciBpbW1lZGlhdGVseSkuICZuYnNwO1NpbWlsYXIgY29u c2lkZXJhdGlvbnMgbWlnaHQgPGJyPg0KYXBwbHkgdG8gbXVsdGlwYXRoIFJUUDwvc3Bhbj48c3Bh biBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1j b2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmls bC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRp b24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+Jm5ic3A7PC9z cGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPltCQV0gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgYnJvd3Nl ciBoYXMgYSBsZWdpdGltYXRlIHJlYXNvbiB0byBzZW5kIG1lZGlhIHRvIGEgZGVzdGluYXRpb24g dGhhdCBpcyBub3QgcGFydCBvZiBhIHZhbGlkIHBhaXIgZm9yIHdoaWNoIHRoZSBub21pbmF0ZWQg ZmxhZyBpcyBzZXQgdG8gdHJ1ZSwgYXMgcGVyIFJGQyA1MjQ1IFNlY3Rpb24gNy4xLjMuMi40LiAm bmJzcDtGb3IgbW9iaWxpdHkNCiB5b3UgY2FuIHN0aWxsIHNpZ25hbCBVU0UtQ0FORElEQVRFIGJ1 dCBub3QgdXNlIHRoZSBwYWlyIGlmIGFub3RoZXIgcGFpciBoYWQgaGlnaGVyIHByaW9yaXR5LiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGRvbm90IHRoaW5rIHJmYyA1MjQ1IGFsbG93cyB0aGlzLCBpdCBvbmx5IGFsbG93IG9u bHkgb25lIHBhaXIgd2l0aCB0aGUgVVNFLUNBTkRJREFURSBhdHRyaWJ1dGUgcHJlc2VudC48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48 YnI+PGRpdj5bQkFdIEJ1dCBpbiB0aGF0IGNhc2UgeW91IHdvdWxkIHdhbnQgdG8gdXNlIHRoZSBw YWlyLCBubz88L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-82910280-CD0E-4F80-9002-C682946A0AF1-- From magnus.westerlund@ericsson.com Wed Sep 12 06:32:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096D521F851B for ; Wed, 12 Sep 2012 06:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InVohpwigEgV for ; Wed, 12 Sep 2012 06:32:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 224D021F8569 for ; Wed, 12 Sep 2012 06:32:14 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-e7-50508eddef10 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5C.C7.17130.DDE80505; Wed, 12 Sep 2012 15:32:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 15:32:13 +0200 Message-ID: <50508ED7.9080805@ericsson.com> Date: Wed, 12 Sep 2012 15:32:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VvduX0CAQc9rI4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbFzLWvBT46K3/9usTQwzmPvYuTkkBAwkbiydR8rhC0mceHe erYuRi4OIYFTjBK357QzgSSEBJYzSkydWgBi8wpoS2w+cZkZxGYRUJVY07kHrJlNwELi5o9G NhBbVCBYYtL+LSwQ9YISJ2c+AbNFBIQltr7qBZrJwSEsYCkx5WIyxPgAic9zboKN4RQIlPi5 vo0J4h5JiTeTb4K1MgvoSUy52sIIYctLNG+dzQzRqy3R0NTBOoFRcBaSbbOQtMxC0rKAkXkV o3BuYmZOerm5XmpRZnJxcX6eXnHqJkZgUB7c8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYNxwtPDjzdJtV49e/jn5fnDavhW6T9gjN/zWCc65Xb/DoC/w 5Ye2OpFHl5bd+mAidF7q1erjDmyZobuWyirGvl4oUzFL7u0VP9GLrlJXvzS4bOJSjZnyb+UJ hvu60gdf+94tP8Crob0pQeuO7G7/T9NWxtQrCGo+ZpNfxXF71sf7vuYrD+S/NFJXYinOSDTU Yi4qTgQAG9ZMXhgCAAA= Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:32:16 -0000 WG, Based on this discussion the chairs conclusion is that there is required to have a definition of how trickle ICE is to work so that interoperable implementations can be made. This WG is clearly not chartered to develop such a specification. Thus a possible way forward is to do the work in the MMUSIC WG and develop an ICE mode for trickle. Such work would require someone to take the role of being proponent and drive the work in MMUSIC. Thus we chair wonder if there exist people willing to take on this effort? We chairs will meantime discuss with our ADs and the MMUSIC WG chairs how they see on starting work in MMUSIC for this. Cheers Magnus Westerlund (As chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From martin.thomson@gmail.com Wed Sep 12 08:57:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4421F859B for ; Wed, 12 Sep 2012 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9Q5Fw4HMMqR for ; Wed, 12 Sep 2012 08:57:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A68E21F85EF for ; Wed, 12 Sep 2012 08:57:09 -0700 (PDT) Received: by lbky2 with SMTP id y2so1378343lbk.31 for ; Wed, 12 Sep 2012 08:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hqKL99cfvFad8WffcylJdj5sVXHtEXLRB4w+M+klfRs=; b=U1+SCBB7WlFHWYMfRyOiijOebjnmJD9QOcRBl4Jul0eBcwjs9YwZbxdpT/R9/g2vSW kFV4oyVIKpjpbXecGDPYG7zXnUnJCJ46TnsED2xGNnfYBY0O7ZmTAj/CdBQMajlibIla 8QN0AE1VV4Jk8/OSr+k24J/LZvw/mpPHR4aH7wZIt/nJbIhHSeiY/+oKGtEn9Jcd1y+8 n6M7YLy6ON2aOPnGRwP20VOQP6yIgnKtWP7YbHGMZbtKDwouC4By24Kr+x1l595gIUxq LS25u9T7+duDkFP0vgxEoEpL/SXoaOTEqh3G0AqH0ic1uGZY6XUCqI7cvrfueMZ8hWjn 5Ilg== MIME-Version: 1.0 Received: by 10.112.49.202 with SMTP id w10mr7587544lbn.109.1347465428778; Wed, 12 Sep 2012 08:57:08 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 08:57:08 -0700 (PDT) In-Reply-To: References: <08c301cd9076$a2405c40$e6c114c0$@com> Date: Wed, 12 Sep 2012 08:57:08 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:57:11 -0000 There are a number of things that concern me regarding this. Firstly, USE-CANDIDATE can be sent on multiple pairs over time. Particularly if the first pair fails for some reason. Blocking nominations after the first would prevent failover, as well as things like multipath or confusing cases where there are multiple components using the same set of local candidates (c.f., BUNDLE backward compatibility scenarios). I don't think that USE-CANDIDATE is sufficient or necessary for consent. Nomination is asymmetric in nature; only the controlling peer can send it. The controlled peer has no way to know that the nomination check wasn't spoofed. After all, that is the reason both peers send connectivity checks. The controlled peer then can't attach any real significance to the nomination. That isn't inherently a problem - the controlled peer is still making checks and it is those checks that verify that the controlling peer is willing to receive packets at those addresses. However, the underlying concern Bernard alludes to is a real one. Not only does consent indicate that I can send an arbitrary volume of data to the checked host, as a natural consequence of ICE checking, there is a decent chance that I get a large number of options, all of which accept that arbitrary volume of data. --Martin On 12 September 2012 05:17, Bernard Aboba wrote: > On Sep 12, 2012, at 1:51, "Lishitao" wrote: > > Dan Wing said: > > > For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to > keep other candidates available, but inactive. Over those other > candidates we would not signal USE-CANDIDATE, but we would want to > be able to switch to the other candidate as quickly as possible > (ideally, switch over immediately). Similar considerations might > apply to multipath RTP > > [BA] My question is whether the browser has a legitimate reason to send > media to a destination that is not part of a valid pair for which the > nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4. For > mobility you can still signal USE-CANDIDATE but not use the pair if another > pair had higher priority. > > > > > > I donot think rfc 5245 allows this, it only allow only one pair with the > USE-CANDIDATE attribute present. > > > [BA] But in that case you would want to use the pair, no? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Wed Sep 12 09:05:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D3B21F8543 for ; Wed, 12 Sep 2012 09:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Yy5d3ke0-R9k for ; Wed, 12 Sep 2012 09:05:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 934A721F856C for ; Wed, 12 Sep 2012 09:05:08 -0700 (PDT) Received: by lahm15 with SMTP id m15so1327545lah.31 for ; Wed, 12 Sep 2012 09:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xf9/S3yAw3dffa0nMtkNvdgl07hFF3KIO67Q//PSvZE=; b=TT4vXepLqphtOyS6z8RHr6/ENQWbyIBNSOVNgrZXpvIHdMzxkDIrNHrdxPWgM+fZXa cd8UdD7ZjpvujfNXEVQX5XM1VL1ELFki3F0x0rCW14llD7eLshaN4zRWTVTHdAq5nCn0 G7pzTLPpdtNWN/A3TR7Rl29vG+3Ydge7VVqED3x181NIBFpZnYhVtf/o8Zzcu5OTICK/ 4kmNZg1Haws16OShe8e1EYaL53LpKZur4pnWwbjeOE0jxHLhcjmkfNNJQPz4J7siL5yc Z5wb8AFbERl5mgKsv1xX1jUar1odFx+JbC2fYUVFJLzVkbkjcFibJ39wrfMGk7qEgu/f Szqg== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr19232436lab.48.1347465907536; Wed, 12 Sep 2012 09:05:07 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 09:05:07 -0700 (PDT) In-Reply-To: <50508ED7.9080805@ericsson.com> References: <50508ED7.9080805@ericsson.com> Date: Wed, 12 Sep 2012 09:05:07 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:05:24 -0000 +1 I can't currently commit to writing specifications, but I'm certainly willing to provide reviews. On 12 September 2012 06:32, Magnus Westerlund wrote: > WG, > > Based on this discussion the chairs conclusion is that there is required > to have a definition of how trickle ICE is to work so that interoperable > implementations can be made. > > This WG is clearly not chartered to develop such a specification. Thus a > possible way forward is to do the work in the MMUSIC WG and develop an > ICE mode for trickle. Such work would require someone to take the role > of being proponent and drive the work in MMUSIC. > > Thus we chair wonder if there exist people willing to take on this effort= ? > > We chairs will meantime discuss with our ADs and the MMUSIC WG chairs > how they see on starting work in MMUSIC for this. > > Cheers > > Magnus Westerlund > (As chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Wed Sep 12 10:39:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674D21F866C for ; Wed, 12 Sep 2012 10:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BHW9WRAo8hV for ; Wed, 12 Sep 2012 10:39:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 368D221F844B for ; Wed, 12 Sep 2012 10:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3537; q=dns/txt; s=iport; t=1347471544; x=1348681144; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ENwqGZOhQSvC0lGHf9qGQ1u3QTr4wqsjsz5QE934Szs=; b=LFZ3+mK5200jCOYMRfd93wGQJTxRbbdu02G8/GChGol4rKbvftEjgdUk AloqYvhY4cqc2eq+T8Ipn0t9ZWoBTTXZojmWphUSUUyUTVEFse7iQ5Ynf 98xwVb8u1Rt1muKIaldir/9FapkgeDKPKFRRxGv2H3k3Ge7Wbs4wsWkA9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAGLHUFCrRDoI/2dsb2JhbABFqX6BZo9qgQeCIAEBAQQBAQEFCgEXEDQLDAEDAgkPAgQBAQEnBxkOFQoJCAEBBAESCxeHXAMLDJt9oC+KLWOGQgOIVYUOhiiCaIoBgyGBaYMG X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="55467323" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 12 Sep 2012 17:39:03 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8CHd23B009500; Wed, 12 Sep 2012 17:39:02 GMT From: "Dan Wing" To: "'Martin Thomson'" , "'Bernard Aboba'" References: <08c301cd9076$a2405c40$e6c114c0$@com> In-Reply-To: Date: Wed, 12 Sep 2012 10:39:01 -0700 Message-ID: <0c2301cd910d$7f4bd150$7de373f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Q/05mUeLeCYnfTFifgQM4jzsjfwADaWtg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:39:06 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Martin Thomson > Sent: Wednesday, September 12, 2012 8:57 AM > To: Bernard Aboba > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] What is consent? > > There are a number of things that concern me regarding this. > > Firstly, USE-CANDIDATE can be sent on multiple pairs over time. > Particularly if the first pair fails for some reason. Blocking > nominations after the first would prevent failover, as well as things > like multipath or confusing cases where there are multiple components > using the same set of local candidates (c.f., BUNDLE backward > compatibility scenarios). > > I don't think that USE-CANDIDATE is sufficient or necessary for > consent. Nomination is asymmetric in nature; only the controlling > peer can send it. The controlled peer has no way to know that the > nomination check wasn't spoofed. After all, that is the reason both > peers send connectivity checks. The controlled peer then can't attach > any real significance to the nomination. That isn't inherently a > problem - the controlled peer is still making checks and it is those > checks that verify that the controlling peer is willing to receive > packets at those addresses. > > However, the underlying concern Bernard alludes to is a real one. Not > only does consent indicate that I can send an arbitrary volume of data > to the checked host, as a natural consequence of ICE checking, there > is a decent chance that I get a large number of options, all of which > accept that arbitrary volume of data. The volume of data is separate from USE-CANDIDATE, though. ICE does not currently have a way to indicate bandwidth. There was a bandwidth extension for TURN, but it did not achieve working group consensus and is not in the TURN RFC. There is a bandwidth extension to ICE that Microsoft documents and I believe use in their products, http://msdn.microsoft.com/en-us/library/cc339480, MS-ICE2BWM and MS-TURNBWM. -d > --Martin > > On 12 September 2012 05:17, Bernard Aboba > wrote: > > On Sep 12, 2012, at 1:51, "Lishitao" wrote: > > > > Dan Wing said: > > > > > > For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to > > keep other candidates available, but inactive. Over those other > > candidates we would not signal USE-CANDIDATE, but we would want to > > be able to switch to the other candidate as quickly as possible > > (ideally, switch over immediately). Similar considerations might > > apply to multipath RTP > > > > [BA] My question is whether the browser has a legitimate reason to > send > > media to a destination that is not part of a valid pair for which the > > nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4. > For > > mobility you can still signal USE-CANDIDATE but not use the pair if > another > > pair had higher priority. > > > > > > > > > > > > I donot think rfc 5245 allows this, it only allow only one pair with > the > > USE-CANDIDATE attribute present. > > > > > > [BA] But in that case you would want to use the pair, no? > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed Sep 12 10:55:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A421F863F for ; Wed, 12 Sep 2012 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 l5b3WxY2Rfki for ; Wed, 12 Sep 2012 10:55:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 587DC21F85B8 for ; Wed, 12 Sep 2012 10:55:51 -0700 (PDT) Received: by lahm15 with SMTP id m15so1410489lah.31 for ; Wed, 12 Sep 2012 10:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=drH32xjC9qx4jsHv8Jp+cSPRaV85KVyqCmNwFN4q2O0=; b=p7OX1pZkBX4LISVbH9quNU/BY6VxZYMljKWVgH8jiQWidFzpxmI/fUfJxoadoIEEmK WoIulTelb/pu8ECTg9dgKTsNuvJK4MNXYoksJvhbQIk5PR2NpeOaoMpXQeOuyLpK95nM tYmQIMVdHyW65gmyyU1SS/9iQiux5TmTs1HITgE8ONjGK1D4hPlhtEPAGI6zEAl8y2oE XsHSbC3Y6gxmFKeRYZuoUfa502ZHB/4QOmoyVmzkpuUK979X/ampE/c5cjbLk5XWoP1d zxPh2DZXE2LE0963Eq5zL18yg44GVvL/qKCAQefVPsGv/1JfJjdAJrc3EvE3NMZuLrD9 BrkQ== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr19848319lab.11.1347472550332; Wed, 12 Sep 2012 10:55:50 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 10:55:50 -0700 (PDT) In-Reply-To: <0c2301cd910d$7f4bd150$7de373f0$@com> References: <08c301cd9076$a2405c40$e6c114c0$@com> <0c2301cd910d$7f4bd150$7de373f0$@com> Date: Wed, 12 Sep 2012 10:55:50 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:55:52 -0000 On 12 September 2012 10:39, Dan Wing wrote: > The volume of data is separate from USE-CANDIDATE, though. ICE does > not currently have a way to indicate bandwidth. Yes. > There was a bandwidth extension for TURN, but it did not achieve > working group consensus and is not in the TURN RFC. There is > a bandwidth extension to ICE that Microsoft documents and I believe > use in their products, http://msdn.microsoft.com/en-us/library/cc339480, > MS-ICE2BWM and MS-TURNBWM. There are two bandwidth-related things in use. One is related to bandwidth estimation and not really pertinent to this. The other potentially relevant one is the bandwidth parameter (the one that never reached consensus) is used to manage bandwidth for relay allocations. The latter is interesting to me, particularly if that parameter can be applied to ICE. There are some gotchas that need careful consideration, particularly around this area of having consent on multiple valid candidate pairs. --Martin From harald@alvestrand.no Wed Sep 12 16:40:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AAD21F861C for ; Wed, 12 Sep 2012 16:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI0CTQfFSMcs for ; Wed, 12 Sep 2012 16:40:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 078BE21F85B4 for ; Wed, 12 Sep 2012 16:40:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3F8E39E1B9 for ; Thu, 13 Sep 2012 01:40:00 +0200 (CEST) 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 SZMSDjokUhJq for ; Thu, 13 Sep 2012 01:39:59 +0200 (CEST) Received: from [172.22.79.234] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E236A39E1AC for ; Thu, 13 Sep 2012 01:39:58 +0200 (CEST) Message-ID: <50511D4C.9040805@alvestrand.no> Date: Wed, 12 Sep 2012 16:39:56 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <08c301cd9076$a2405c40$e6c114c0$@com> <0c2301cd910d$7f4bd150$7de373f0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 23:40:03 -0000 On 09/12/2012 10:55 AM, Martin Thomson wrote: > On 12 September 2012 10:39, Dan Wing wrote: >> The volume of data is separate from USE-CANDIDATE, though. ICE does >> not currently have a way to indicate bandwidth. > Yes. > >> There was a bandwidth extension for TURN, but it did not achieve >> working group consensus and is not in the TURN RFC. There is >> a bandwidth extension to ICE that Microsoft documents and I believe >> use in their products, http://msdn.microsoft.com/en-us/library/cc339480, >> MS-ICE2BWM and MS-TURNBWM. > There are two bandwidth-related things in use. One is related to > bandwidth estimation and not really pertinent to this. The other > potentially relevant one is the bandwidth parameter (the one that > never reached consensus) is used to manage bandwidth for relay > allocations. > > The latter is interesting to me, particularly if that parameter can be > applied to ICE. There are some gotchas that need careful > consideration, particularly around this area of having consent on > multiple valid candidate pairs. I may be hopelessly naive here, but isn't the b= parameter of the SDP negotiation supposed to give an upper limit on how much data the recipient expects to receive on a connection? RFC 3264 section 5.1 (unicast offer): If the bandwidth attribute is present for a stream, it indicates the desired bandwidth that the offerer would like to receive. Section 6.1 (unicast answer): The answerer MAY include a bandwidth attribute for any media stream; this indicates the bandwidth that the answerer would like the offerer to use when sending media. (note that "media stream" here is != MediaStream) The browser being used to stage an attack will of course not know this value, since its signalling is controlled by the attacker, but the browser being attacked will be able to tell the difference between a within-contract amount of data and an out-of-contract amount of data. Harald From martin.thomson@gmail.com Wed Sep 12 16:49:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537E21F861F for ; Wed, 12 Sep 2012 16:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQJOxew61nPi for ; Wed, 12 Sep 2012 16:49:42 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55021F861C for ; Wed, 12 Sep 2012 16:49:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1215403wgb.13 for ; Wed, 12 Sep 2012 16:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GIaAZfBqIcTB5UsQ/SDTO741/++Hqnd6JvaN0pWuTVg=; b=e3bizbB/F+oDcNm56KyXr/5i9BSZunOzPfDwN/rDr2BjNIYfePTG7V08X4WMJgen/U 4Tf5CEpCdVaIILA3vEFm4qG5Y8omlueV3SOYynvOCjYMqCDzCDYXg+GY0FbtugA1GjJx xPhPyN0dZ6x1gY4dBuU8nYA2EPmWaW6kUmYg0J2EsDWGtGYqNwCbIM6AuGb5rsY2xBDW d0LW0TA6BREsV0Idk4mXy0L1znlIUB20u2laJtKHJReUwDVT4CT3N4U2su7VZkAYkzN9 /Sc253PgiXOL8Lv6WFzZxwHL55aNCv/GRXlpRxz9xmPkopMloriXktCCw1xgAcS9xLrd z63Q== MIME-Version: 1.0 Received: by 10.216.140.104 with SMTP id d82mr84807wej.130.1347493778400; Wed, 12 Sep 2012 16:49:38 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Wed, 12 Sep 2012 16:49:38 -0700 (PDT) In-Reply-To: <50511D4C.9040805@alvestrand.no> References: <08c301cd9076$a2405c40$e6c114c0$@com> <0c2301cd910d$7f4bd150$7de373f0$@com> <50511D4C.9040805@alvestrand.no> Date: Wed, 12 Sep 2012 16:49:38 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 23:49:43 -0000 On 12 September 2012 16:39, Harald Alvestrand wrote: > I may be hopelessly naive here, but isn't the b= parameter of the SDP > negotiation supposed to give an upper limit on how much data the recipient > expects to receive on a connection? SDP is completely unauthenticated. We have to assume that it is provided by a web attacker. That doesn't mean that the SDP bandwidth isn't a limit, or that it shouldn't be respected. On the other hand, if it's set to 10 bazillion, it doesn't give an RTP sender permission to send that much data toward a peer. --Martin From bernard_aboba@hotmail.com Wed Sep 12 17:02:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC36421F8534 for ; Wed, 12 Sep 2012 17:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 p7edbnudrUC5 for ; Wed, 12 Sep 2012 17:02:59 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B621F8533 for ; Wed, 12 Sep 2012 17:02:59 -0700 (PDT) Received: from BLU401-EAS365 ([65.55.116.72]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Sep 2012 17:02:57 -0700 X-Originating-IP: [166.147.103.239] X-EIP: [RCxZ2mFtdsr4xn11F/xzpTRC8snLPyWDwm9O6aQ0jSI=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <08c301cd9076$a2405c40$e6c114c0$@com> <0c2301cd910d$7f4bd150$7de373f0$@com> <50511D4C.9040805@alvestrand.no> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <50511D4C.9040805@alvestrand.no> Date: Wed, 12 Sep 2012 19:02:53 -0500 To: Harald Alvestrand MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 13 Sep 2012 00:02:57.0707 (UTC) FILETIME=[21A76FB0:01CD9143] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:02:59 -0000 On Sep 12, 2012, at 6:40 PM, "Harald Alvestrand" wrot= e: >=20 > The browser being used to stage an attack will of course not know this val= ue, since its signalling is controlled by the attacker, but the browser bein= g attacked will be able to tell the difference between a within-contract amo= unt of data and an out-of-contract amount of data. >=20 > Harald [BA] Correct, but how does the receiver turn off the spigot? Is this handled= via circuit breakers?=20= From ekr@rtfm.com Wed Sep 12 17:14:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E814B21F85C3 for ; Wed, 12 Sep 2012 17:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 q0cca70E0lAh for ; Wed, 12 Sep 2012 17:14:41 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 142FF21F85A3 for ; Wed, 12 Sep 2012 17:14:40 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so4650202wib.13 for ; Wed, 12 Sep 2012 17:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=O05TiqIJp7f6xEUkAx2AmulEyxvl9FgNCffSZKR5YTw=; b=ElDRTSvJZaMLg9FK+kcQGgyfn21AcXRi2qJHNgLdfzWTYy/cXwyrJrxd/eu6O+D+II 3lgLXz4HShn68m7jI0Atj3iB32XNeH4cl0msEVefKimXamYxEASbb4a0rwA73GharAel UwcS4YMw9bsqCeUv0fmzgs/10U6R2BPEnkCN1tR7Yc3TTj208wJj173/GAxYnlFs3SYs QEM2ds+q1XnalG6GnWco8/NbBPMJ1nKjb+VTpBnvJqEShBe9NTxRt38Ptrx7J5uF9JJX YuVb2Vli0a8+P+hnY2NIRRt49aiymFKJ3dcHHyk6uskXyzdn4xJUeDpP8WQ20+v8f6fU tryA== Received: by 10.216.138.200 with SMTP id a50mr100445wej.155.1347495279907; Wed, 12 Sep 2012 17:14:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.1.197 with HTTP; Wed, 12 Sep 2012 17:13:59 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <08c301cd9076$a2405c40$e6c114c0$@com> <0c2301cd910d$7f4bd150$7de373f0$@com> <50511D4C.9040805@alvestrand.no> From: Eric Rescorla Date: Wed, 12 Sep 2012 17:13:59 -0700 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmilfl7Tu4wLdPes0gTb4Z0eNXdO47uch663SK6up+nFwJVSfLGtvmm1J5l2s78CvfBf98t Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is consent? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:14:42 -0000 By not returning consent checks. On Wed, Sep 12, 2012 at 5:02 PM, Bernard Aboba wrote: > On Sep 12, 2012, at 6:40 PM, "Harald Alvestrand" w= rote: >> >> The browser being used to stage an attack will of course not know this v= alue, since its signalling is controlled by the attacker, but the browser b= eing attacked will be able to tell the difference between a within-contract= amount of data and an out-of-contract amount of data. >> >> Harald > > [BA] Correct, but how does the receiver turn off the spigot? Is this hand= led via circuit breakers? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From michael.yan@huawei.com Wed Sep 12 17:55:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3776421F867B for ; Wed, 12 Sep 2012 17:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jEqzrgLUXZCn for ; Wed, 12 Sep 2012 17:55:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4240121F865D for ; Wed, 12 Sep 2012 17:55:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKP59334; Thu, 13 Sep 2012 00:55:55 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 01:55:49 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 01:55:54 +0100 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.156]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 08:55:43 +0800 From: "Yanqiang (Michael)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fw: New Version Notification for draft-yan-rtcweb-desktop-cloud-00.txt Thread-Index: AQHNkUPbAGeirczUOkiERnXgP6PcIpeHbMiQ Date: Thu, 13 Sep 2012 00:55:42 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B305CBD3C@szxeml528-mbx.china.huawei.com> References: <20120913000804.13396.76251.idtracker@ietfa.amsl.com> In-Reply-To: <20120913000804.13396.76251.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] Fw: New Version Notification for draft-yan-rtcweb-desktop-cloud-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:55:57 -0000 SGkgQWxsLA0KDQoJSSBoYWQgbm90aWNlZCB0aGUgc2ltaWxhciB0b3BpYyBoYWQgYmVlbiBkaXNj dXNzZWQgbGFzdCB5ZWFyLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byByZWFsaXplIHRoZSBX ZWJSVEMgYXBwbGljYXRpb24gb24gZGVza3RvcCBjbG91ZCBzb2x1dGlvbiwgd2hpY2ggaXMgZGVm aW5pdGVseSBob3QgYW5kIHdpZGVseSBkZXBsb3llZCBpbiBtYW55IGNvbXBhbmllcy4gVGhlIC0w MCB2ZXJzaW9uIG1pc3NlZCBhIGxvdCBvZiByZWZlcmVuY2VzIGFuZCB3YXMgZmFyIGZyb20gZG9u ZS4gSSBob3BlIGl0IHdvdWxkIGJyaW5nIHNvbWUgZGlmZmVyZW50IGlkZWFzIHRoYXQgZHJhdyB5 b3VyIGF0dGVudGlvbnMuDQoNClJlZ2FyZHMsDQpNaWNoYWVsDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAy MDEyIDg6MDggQU0NCj4gVG86IFlhbnFpYW5nIChNaWNoYWVsKQ0KPiBDYzogQ2hlbnhpbg0KPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlhbi1ydGN3ZWItZGVz a3RvcC1jbG91ZC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt eWFuLXJ0Y3dlYi1kZXNrdG9wLWNsb3VkLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IE1pY2hhZWwgWWFuIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3Np dG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQteWFuLXJ0Y3dlYi1kZXNrdG9wLWNsb3VkDQo+ IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6CQkgV2ViUlRDIFJlYWxpemF0aW9uIGluIERlc2t0b3Ag Q2xvdWQNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTItMDktMTINCj4gV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogNw0KPiBVUkw6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlhbi1ydGN3ZWItZGVza3RvcC1jbG91ZC0w MC50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXlhbi1ydGN3ZWItZGVza3RvcC1jbG91ZA0KPiBIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbi1ydGN3ZWItZGVza3RvcC1jbG91ZC0wMA0K PiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGUgV2ViIFJlYWwtdGltZSBDb21tdW5pY2F0aW9u cyAoV2ViUlRDKSBwcm92aWRlcyB0aGUgY29tbXVuaWNhdGlvbg0KPiAgICBjYXBhYmlsaXRpZXMg Zm9yIHJlYWwtdGltZSBhbmQgcGVlci10by1wZWVyIHdlYi1iYXNlZCBhcHBsaWNhdGlvbnMuDQo+ ICAgIFRoaXMgZHJhZnQgaXMgbWVhbnQgdG8gcHJvdmlkZSB0aGUgc3RydWN0dXJlIGZvciBhbiBp ZGVhIG9mIGhvdw0KPiAgICBXZWJSVEMgd29ya3Mgb24gdGhlIGRlc2t0b3AgY2xvdWQgc29sdXRp b24gYW5kIGdpdmVzIGd1aWRhbmNlIG9uIGhvdw0KPiAgICB0byBvdmVyY29tZSB0aGUgaXNzdWVz IGFuZCBjaGFsbGVuZ2VzIGluIGltcGxlbWVudGluZyBhbmQgZGVwbG95aW5nLg0KPiAgICBBbHNv IGFzIGRpc2N1c3NlZCBpbiB0aGUgbWFpbCBhcmNoaXZlIGJlZm9yZSwgdGhlIHVzZSBjYXNlIGZv cg0KPiAgICBkZXNrdG9wIGNsb3VkIG9yIHJlbW90ZSBkZXNrdG9wIHNoYXJpbmcgaXMgc3VnZ2Vz dGVkIHRvIGJlIGRlbGF5ZWQNCj4gICAgYWZ0ZXIgV2ViUlRDIHZlcnNpb24gMS4gIFNvIHRoaXMg ZHJhZnQgaXMgdmVyeSBlYXJseSBhbmQgZmFyIGZyb20NCj4gICAgZG9uZS4NCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From harald@alvestrand.no Fri Sep 14 11:10:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF48221F84E1; Fri, 14 Sep 2012 11:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GLDy4g5dZt3R; Fri, 14 Sep 2012 11:10:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A009421F84D5; Fri, 14 Sep 2012 11:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18DAC39E241; Fri, 14 Sep 2012 20:10:21 +0200 (CEST) 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 YiHFMaHHSFh0; Fri, 14 Sep 2012 20:10:19 +0200 (CEST) Received: from [172.22.79.234] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 70D8339E235; Fri, 14 Sep 2012 20:10:18 +0200 (CEST) Message-ID: <50537308.4040301@alvestrand.no> Date: Fri, 14 Sep 2012 11:10:16 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: mmusic , "rtcweb@ietf.org" References: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> In-Reply-To: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020000040500060802040703" Subject: [rtcweb] FYI: New Version Notification for draft-alvestrand-mmusic-msid-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 18:10:24 -0000 This is a multi-part message in MIME format. --------------020000040500060802040703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The MMUSIC chairs have asked me to prepare a version of the MSID draft that is named using the draft--mmusic- convention, in preparation for polling the MMUSIC WG about adopting the draft. This is it. Comments welcome! Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-mmusic-msid-00.txt Date: Wed, 12 Sep 2012 16:27:09 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-alvestrand-mmusic-msid-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-mmusic-msid Revision: 00 Title: Cross Session Stream Identification in the Session Description Protocol Creation date: 2012-09-12 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-00.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid Htmlized: http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-00 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations betweeen media streams within different RTP sessions. This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. The IETF Secretariat --------------020000040500060802040703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit The MMUSIC chairs have asked me to prepare a version of the MSID draft that is named using the draft-<authorname>-mmusic-<subject> convention, in preparation for polling the MMUSIC WG about adopting the draft.

This is it. Comments welcome!

               Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-mmusic-msid-00.txt
Date: Wed, 12 Sep 2012 16:27:09 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-mmusic-msid-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-mmusic-msid
Revision:	 00
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2012-09-12
WG ID:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-00.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-00


Abstract:
   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations betweeen media streams within
   different RTP sessions.

   This mechanism is used to signal the association between the RTP
   concept of SSRC and the WebRTC concept of "media stream" / "media
   stream track" using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat



--------------020000040500060802040703-- From fluffy@cisco.com Mon Sep 17 15:16:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8129721E804A for ; Mon, 17 Sep 2012 15:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrG6hnLx+6no for ; Mon, 17 Sep 2012 15:16:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA14821F8716 for ; Mon, 17 Sep 2012 15:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1351; q=dns/txt; s=iport; t=1347920175; x=1349129775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s5koRR6BOIoIUbSxi6dF2k6An8fVplwIcdlriB7Ob/s=; b=VGBvrlGoQcgvsTbMlW+QsXrDD+Q+CDMeF3xLvC9Pk5v8H0ahzWq10XTE Zu8xqUYeWWLoPntd+JL8NhQNdTKLdG7g75YCvt4NZpEXelWwi0YRmbrpK dm6T/iHZTc2p2HACpdd3WJvS/KT6/YD48Rt+7y4mb3+EgQArsYKTeoKM1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALufV1CtJXG8/2dsb2JhbABFvCKBB4IgAQEBAwESAQodPwULAgEIGB4QMiUCBA4FCRmHWAYLmj2gEYshhmgDlWKOOIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="119515053" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 17 Sep 2012 22:16:15 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8HMGFAo003492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 22:16:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 17:16:14 -0500 From: "Cullen Jennings (fluffy)" To: "James Polk (jmpolk)" Thread-Topic: [rtcweb] Call for adoption of QoS draft Thread-Index: AQHNlSIMVep5hW0c9kGqvpC6gcbbUg== Date: Mon, 17 Sep 2012 22:16:14 +0000 Message-ID: <5CEE837F-DEBD-463A-99BA-993141448484@cisco.com> References: <504DF4F4.9080401@alvestrand.no> <201209102113.q8ALD0qQ018125@mtv-core-2.cisco.com> <201209110016.q8B0GQ6x025835@mtv-core-2.cisco.com> In-Reply-To: <201209110016.q8B0GQ6x025835@mtv-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--35.479800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:16:16 -0000 On Sep 10, 2012, at 18:16 , James Polk wrote: > At 04:27 PM 9/10/2012, Martin Thomson wrote: >> On 10 September 2012 14:12, James Polk wrote: >>> MMUSIC has a WG item that should provide this indication/hint, in a >>> trafficclass label attribute. Browsers identifying a small set of label= s >>> from that effort should do the trick. See >>>=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for= -sdp-02.txt >>=20 >> Thanks James, that looks like what is needed. It's not exactly the >> same thing as the priority draft, so I'm not sure how I'd map all the >> way from priority (1-3) to traffic class labels to the DSCP markings >> described in Cullen's draft. >=20 > I'm not sure only 3 priorities are needed, though I believe 3 will get us= ed. The point of the trafficclass labels (TCL) is to add a level of abstrac= tion to what the actual DSCPs need to be by allowing each domain that is aw= are of the type of traffic choose the appropriate DSCP for that type of tra= ffic. The problem with using TCL here is the browser has no idea how to find out = the mapping from TCL to DSCP for the domain it is currently running in so i= t can't use TCL to set the DSCP on the media packets. Subha and I talked ab= out this a bunch and can not see any way to make TCL work.=20 From fluffy@cisco.com Mon Sep 17 15:16:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B315A21F8718 for ; Mon, 17 Sep 2012 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTqYOOG2p-71 for ; Mon, 17 Sep 2012 15:16:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 188E821F8716 for ; Mon, 17 Sep 2012 15:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1347920213; x=1349129813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ng7hAXXJu6zJqAFVtA1jlkgToTNF7i5fxE4XzpzmXm4=; b=g27s9bVUbRyU3obfGnIY9tisIpsNUKoRSPhmHTOx1TudilB5XaDJgIOq ofMZL5sIoH0u4WbR6MS1F1Ld6J3kwDZNaMUJameUgKLe987MPpddVKBS9 mtSKoRumMgvG4HtDApSqT12d6MJNYU5T1Bu14LObyjhzCck+DAyB1be5b I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALKgV1CtJXG8/2dsb2JhbABFvCKBB4IgAQEBAwESAQpSCgULAgEIGC4yJQIEDgUih1gGmkigEoshhghgA5IxgzGOOIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="122518108" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 17 Sep 2012 22:16:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8HMGqYO003848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 22:16:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 17:16:52 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) Thread-Index: AQHNlSIjsrLEzuMwRUC7DF2XqhTaEw== Date: Mon, 17 Sep 2012 22:16:51 +0000 Message-ID: <185CB042-686A-42F4-A85C-934C6489D0BA@cisco.com> References: <504DF5EF.7070602@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--25.702200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D15EC925DAEC44F824DEF60581EEC9C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:16:53 -0000 On Sep 10, 2012, at 10:38 , Martin Thomson wrote: > On 10 September 2012 07:15, Harald Alvestrand wrot= e: >> - Pointers to documentation on how browsers are expected to be able to s= et >> QCI and WiFI markings would be a good addition. Compared to those, DSCP >> codepoint setting is well understood. >=20 > I agree that this would be useful, if the draft really did make > implementation (and use) of those markings a "SHOULD". See below. >=20 >> - I find it good that these 3 mechanisms are the only ones considered in= the >> draft. I'm making the leap of faith that we intend to state that an >> implementation MUST implement DSCP codepoint marking, SHOULD implement Q= CI >> and WiFI markings when attached to appropriate interfaces, and that no o= ther >> mechanism is going to get a MUST or SHOULD recommendation from the WG. I= f >> I'm right, can we make that explicit? >=20 > What do people think about NOT including QCI/WiFi markings? Is it not > possible for a wireless interface to examine DSCP markings in order to > determine the markings for the link? We should endeavour to maintain > the proper abstractions. On some OS is it is possible to see them but ignoring that =85 think for a = second about what these marketing are meant to be used for - they are mor= e meant to be seen by the network not the browser at the far end so not sur= e this matters much if the some OS can't provide this information to the ap= plication=20 From fluffy@cisco.com Mon Sep 17 15:19:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621F721E808F for ; Mon, 17 Sep 2012 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5nQPUGKKwy5 for ; Mon, 17 Sep 2012 15:19:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7740C21E808E for ; Mon, 17 Sep 2012 15:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1561; q=dns/txt; s=iport; t=1347920371; x=1349129971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zmF31JqDmrG507C0hpjVuhetlMQXYPoNx1Lk0eao4Pg=; b=KJc//gQwOnn4GGtygGhyMHTIpN/0vRC5P2hfh042pQpX6uPRgxlLkwkS p/OBzJgUyDZI5TBcm0eH6G+18pNmf+NcvFlYvLmuX656gtI2RZSvty74l QOZ4+mq+f12v0iEmq+WI5m/stmmu+eiBuKmvNSRhfaiFoazcpNmyIUir3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI+hV1CtJXG//2dsb2JhbABFvCKBB4IgAQEBAwEBAQEPAQodNAsFCwIBCDYQJwslAgQOBSKHWAYLmjmgDgSLIYYIYAOVYo44gWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="122546916" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 17 Sep 2012 22:19:31 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HMJUGg029474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 22:19:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 17:19:29 -0500 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) Thread-Index: AQHNlSKAoqIciQQiU0ubxXAsF2TA3Q== Date: Mon, 17 Sep 2012 22:19:28 +0000 Message-ID: <07676155-04ED-4FA2-AEF5-6A6D7DB2FD00@cisco.com> References: <504DF5EF.7070602@alvestrand.no> In-Reply-To: <504DF5EF.7070602@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--33.708300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2A186A8672AC2F4DA7C791F357ADCB7E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:19:32 -0000 On Sep 10, 2012, at 8:15 , Harald Alvestrand wrote: > Since this draft is mercifully short, I did a quick review. >=20 > Notes: >=20 > - Pointers to documentation on how browsers are expected to be able to se= t QCI and WiFI markings would be a good addition. Compared to those, DSCP c= odepoint setting is well understood. I think the draft needs all the correct pointers to the specs for this the = QCI / WIFI stuff as well as pointers to the normative mapping tables define= d by the appropriate SDOs for them. If the device is sending a packet on a = network that supports QCI or Wifi marking, it can use them. I'm not really= sure what else to say. (Note that I don't think this could be a MUST use )= . >=20 > - I find it good that these 3 mechanisms are the only ones considered in = the draft. I'm making the leap of faith that we intend to state that an imp= lementation MUST implement DSCP code point I have not tracked this all down but have been told that it might not be po= ssible for a browser to do this in some versions of the windows operating s= ystem so I suspect the DSCP would end up being SHOULD not a MUST =20 > m unforotanly arking, SHOULD implement QCI and WiFI markings when attache= d to appropriate interfaces, and that no other mechanism is going to get a = MUST or SHOULD recommendation from the WG. If I'm right, can we make that e= xplicit? >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Mon Sep 17 15:24:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DCC21E8090 for ; Mon, 17 Sep 2012 15:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 RUeQxVo8MgM5 for ; Mon, 17 Sep 2012 15:24:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 929FD21E808C for ; Mon, 17 Sep 2012 15:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=914; q=dns/txt; s=iport; t=1347920672; x=1349130272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mMsRdJYH2VxWlDeRAyb9vYzSWEBKkqzhsHMHrNjH/Qs=; b=ke9+Dfm0CsaHszoEaWdM4I//561CcNk5op4Pgmqm9/QxYViPMMgnX3L5 2cmYWhEfdodMxxm9BHwVgmUTULBFNGKsV8+a14jbKyXv6j8zbjty07Mcr IA0bUu7KSDK/6mZ50XCMsYMw8dj027SFC0jo2xy3HngWhFOTp0GyGuvAS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE+iV1CtJXG9/2dsb2JhbABFhUC2YoEHgiABAQEDAQEBAQ8BCh00CwULAgEIGB4QJwslAgQOBSKHWAYLmjugDgSLIYYIYAOVYo44gWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="119516817" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 17 Sep 2012 22:24:32 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8HMOWWl004581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 22:24:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 17:24:31 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] Call for adoption of QoS draft Thread-Index: AQHNlSM1FjT4vPNvTU6D0426/zx67w== Date: Mon, 17 Sep 2012 22:24:31 +0000 Message-ID: <0B143D3C-F831-44DB-A261-E26C1041B840@cisco.com> References: <504DF4F4.9080401@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--32.400400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <393E81ABC2A91D4C8236518BC54FF212@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of QoS draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:24:33 -0000 I'd suggest using hint for this. And I think this is a topic for webrtc not this wg.=20 On Sep 10, 2012, at 11:43 , Martin Thomson wrote: > On 10 September 2012 09:54, Eric Rescorla wrote: >> Why would this require SDP work? >>=20 >> I would assume that this would be a setting on the media stream/track. >> or alternately, a hint. >=20 > You could, but that means that you have a more complicated API to use. > You have to set priority locally, signal the chosen priority, set the > signalled priority, etc... As a session characteristic, I assumed > that you would want to put it in the SDP. Or is this something that > is extra specific to WebRTC such that you don't want to provide this > to other SDP users? >=20 > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Mon Sep 17 15:52:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3121F846E for ; Mon, 17 Sep 2012 15:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.731 X-Spam-Level: X-Spam-Status: No, score=-3.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 LkOjVV+G9HmU for ; Mon, 17 Sep 2012 15:52:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1E8C21F846D for ; Mon, 17 Sep 2012 15:52:50 -0700 (PDT) Received: by lbky2 with SMTP id y2so4920377lbk.31 for ; Mon, 17 Sep 2012 15:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PYvUXyeZ+wSW507BnjkxOhFGY7wuuB91NbUE6+tGaos=; b=ZuZUtLPOSTcM83QCqEiZ+7gbFzksNDLom8n9ORT09H3ZSHfL0rRDa9xfjGntCOUYyP eJGx2EGSundZC8vGX5GLmmN0AA7NbT7sd/TCFNCzWdWVvYo//p/5k6NBVRzf7Zy8o8rg xBV/1pdQQdXh7QgQ9WfCFplxC/AXpy/u2fDAafDefvXv/dIujuoLg0WF5Tyoi7gLe0wj rNxXuNHPPR5/31mEvyi8LUy+ZTUk/SdXy533jzvXNqw1M1Xy6RL6ITDPDU0jdtK9OmoM /2dYdrOsuSYeujYRXjtZxbESa9FFw2ZI8NRyP3A5tcZb3c9P4kbjw8G3teENWRttOjgt G3rw== MIME-Version: 1.0 Received: by 10.112.49.202 with SMTP id w10mr4346241lbn.109.1347922369349; Mon, 17 Sep 2012 15:52:49 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 17 Sep 2012 15:52:49 -0700 (PDT) In-Reply-To: <185CB042-686A-42F4-A85C-934C6489D0BA@cisco.com> References: <504DF5EF.7070602@alvestrand.no> <185CB042-686A-42F4-A85C-934C6489D0BA@cisco.com> Date: Mon, 17 Sep 2012 15:52:49 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:52:52 -0000 On 17 September 2012 15:16, Cullen Jennings (fluffy) wro= te: >> What do people think about NOT including QCI/WiFi markings? Is it not >> possible for a wireless interface to examine DSCP markings in order to >> determine the markings for the link? We should endeavour to maintain >> the proper abstractions. > > On some OS is it is possible to see them but ignoring that =E2=80=A6 thin= k for a second about what these marketing are meant to be used for - they= are more meant to be seen by the network not the browser at the far end so= not sure this matters much if the some OS can't provide this information t= o the application I am not suggesting anything about reading the markings off packets. Reading markings off is - as you say - close to useless. I asked if it were possible to consider *not* specifying what link layer markings are made for packets that are *sent*. The suggestion was that if DSCP markings were made, as suggested, the packets could be marked on the way onto the link by the wireless driver using whatever link-specific markings are appropriate. That might lead to a mapping from DSCP to QCI and WiFi markings, but not necessarily. That would be different to the straight-from-the-top application priority to link-layer, as described in the draft. From martin.thomson@gmail.com Mon Sep 17 15:56:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AEA21F8530 for ; Mon, 17 Sep 2012 15:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.726 X-Spam-Level: X-Spam-Status: No, score=-3.726 tagged_above=-999 required=5 tests=[AWL=-0.127, 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 aYczrpq4wJTL for ; Mon, 17 Sep 2012 15:56:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB9421F846D for ; Mon, 17 Sep 2012 15:56:46 -0700 (PDT) Received: by lbky2 with SMTP id y2so4921871lbk.31 for ; Mon, 17 Sep 2012 15:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xghyJP2Jqs2WU4s4/HUBnaukixu9tRVh10sxalHSfTU=; b=YunpMWBHUZ1ahtJf7Xj69/C0VMpNn7kElH1djSWFCdCzZAMtsC4kT2cRsLhfl57FQl Zhsa8VzUBDd5wlylU3oqHnKXiX5jSVMR6NUW8RMCLC/2BDErpjDlgcWIE3xK54Bp6i5c DC1P3wgJKavWdxw6YzCMy738Os/o5JtYxYNgjuKG5UVXHF4oUkmMt7+SGYGHESQ4INLy EfAinD6/4W4wNR5ZrWab0O8/bSXb/8iECXPUQxw2cIwPxKO7cRD7nN/Ar/5ObX7NF0cX ZyffAvy4x2yhPeaIHWSiqLg8hAeMHIBjWocKKfTHN9zxnngszojDijlndFJJolp+lv58 BqfA== MIME-Version: 1.0 Received: by 10.112.27.69 with SMTP id r5mr4155049lbg.91.1347922605513; Mon, 17 Sep 2012 15:56:45 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 17 Sep 2012 15:56:45 -0700 (PDT) In-Reply-To: <07676155-04ED-4FA2-AEF5-6A6D7DB2FD00@cisco.com> References: <504DF5EF.7070602@alvestrand.no> <07676155-04ED-4FA2-AEF5-6A6D7DB2FD00@cisco.com> Date: Mon, 17 Sep 2012 15:56:45 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:56:50 -0000 On 17 September 2012 15:19, Cullen Jennings (fluffy) wrote: > I have not tracked this all down but have been told that it might not be possible for a browser to do this in some versions of the windows operating system so I suspect the DSCP would end up being SHOULD not a MUST As I understand it, setting DSCP can be disabled by group policy. This is an explicit request from certain network operators, usually enterprises who have the ability to set such policies. As a matter of interest, some of the same networks do still perform traffic prioritization for audio and video traffic. They do it based on port ranges. You could infer some requirements from that. From harald@alvestrand.no Mon Sep 17 16:45:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F83C21E808C for ; Mon, 17 Sep 2012 16:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFAdTyJTO1Qy for ; Mon, 17 Sep 2012 16:45:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8416221E804A for ; Mon, 17 Sep 2012 16:45:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 394E439E062; Tue, 18 Sep 2012 01:45:52 +0200 (CEST) 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 Mxf+4QM0Kqxj; Tue, 18 Sep 2012 01:45:51 +0200 (CEST) Received: from [172.19.28.100] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6C97339E01E; Tue, 18 Sep 2012 01:45:50 +0200 (CEST) Message-ID: <5057B62B.4010006@alvestrand.no> Date: Mon, 17 Sep 2012 16:45:47 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Martin Thomson References: <504DF5EF.7070602@alvestrand.no> <07676155-04ED-4FA2-AEF5-6A6D7DB2FD00@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:45:54 -0000 On 09/17/2012 03:56 PM, Martin Thomson wrote: > On 17 September 2012 15:19, Cullen Jennings (fluffy) wrote: >> I have not tracked this all down but have been told that it might not be possible for a browser to do this in some versions of the windows operating system so I suspect the DSCP would end up being SHOULD not a MUST > As I understand it, setting DSCP can be disabled by group policy. > This is an explicit request from certain network operators, usually > enterprises who have the ability to set such policies. > > As a matter of interest, some of the same networks do still perform > traffic prioritization for audio and video traffic. They do it based > on port ranges. You could infer some requirements from that. The normal case for client-server communication is that the server has fixed port numbers, and the client just uses the port number the OS gives it; the network's priority setting is then done on the server port number range. There are "fun" issues with trying to set port numbers on clients, including how to ACL them (I don't know of an OS that can do that), and the problem of port number collision. For client-client communication, I think DSCP has a better chance of succeeding (not a big chance. Just a better chance). From Markus.Isomaki@nokia.com Tue Sep 18 01:08:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DA21F867C for ; Tue, 18 Sep 2012 01:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 UbNrUAYFYT9i for ; Tue, 18 Sep 2012 01:08:04 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE721F84F3 for ; Tue, 18 Sep 2012 01:08:03 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8I87m9d028533; Tue, 18 Sep 2012 11:07:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 11:07:49 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.5]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Tue, 18 Sep 2012 10:07:48 +0200 From: To: , Thread-Topic: draft-jennings-rtcweb-qos: QCI "marking"? Thread-Index: Ac2VbwTgBW+2KYNOQASP2tZPnOnMPg== Date: Tue, 18 Sep 2012 08:07:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.152.102.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Sep 2012 08:07:49.0307 (UTC) FILETIME=[B1AA10B0:01CD9574] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:08:05 -0000 Hi, Martin Thomson wrote: > >On 10 September 2012 07:15, Harald Alvestrand >wrote: >> - Pointers to documentation on how browsers are expected to be able to >> set QCI and WiFI markings would be a good addition. Compared to those, >> DSCP codepoint setting is well understood. > > >What do people think about NOT including QCI/WiFi markings? Is it not >possible for a wireless interface to examine DSCP markings in order to >determine the markings for the link? We should endeavour to maintain the >proper abstractions. > I'm not even sure if the browser or even the OS can influence much the QCI = or bearer selection in LTE. I think the model is such that the "network" se= ts up these special non-best-effort bearers, and gives the endpoint the cla= ssifier rules related to them. The rules tell the endpoint how to map outgo= ing packets to the bearers. Typically the rules are based on source/destina= tion IP and port, and the transport protocol. Someone may be able to confir= m, but I believe DSCP can be used too. But basically the rules come from th= e network and the endpoint just follows them.=20 So, somehow the browser or the JS app would first have to convince the acce= ss network provider to setup the special bearer so that the right flows get= classified to it. In IMS the SIP proxy reads the SDP and tells some networ= k element what audio or video flows are being setup and what their 5-tuples= are, so the network is being able to setup the bearers correctly for them.= The endpoint merely waits for this setup and acts accordingly. This works = as the SIP proxy is run by the access operator. In RTCWeb the same could wo= rk if the calling site had a relationship with the access operator. I've he= ard that there is some work by some operators to offer Web APIs for 3rd par= ty apps to do the bearer setup requests more ad hoc. Most of this may be ou= tside the scope of RTCWeb but I think the document should have some explana= tion on how it works from the OS, browser, JS client, calling site, and mob= ile operator perspective.=20 On the "transport" or "data path" level I don't think the browser needs to = understand anything about QCIs. DSCP marking should be good enough.=20 Anyone with more LTE/mobile clue that could comment on this?=20 Markus=20 From cb.list6@gmail.com Tue Sep 18 06:27:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64721E80C1 for ; Tue, 18 Sep 2012 06:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PLYzFHnXGqFX for ; Tue, 18 Sep 2012 06:27:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E421F8495 for ; Tue, 18 Sep 2012 06:27:37 -0700 (PDT) Received: by lbky2 with SMTP id y2so5350139lbk.31 for ; Tue, 18 Sep 2012 06:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y/CtOV2LNkTDCsnxouMuLQdNd5Hai4DMLDFw7FjQ5/g=; b=tNuxhFm0SPVhX2dbzTzQrXKq29g7Yf2KRCHdxLBZjXTFGHx+l7xX8txRZiLpmHhxHW yNgsNcz4ItY/+WTh8/lyuaESLGt26LqRyzOrsWFXzjmMQ+VsgkYSo86Ux3QDLEK2a/jv n5UWd98qpqqWQ0e6IMh20/xu6Y6F3skX/EDFNGxg3eiaYRnAHbfG67JVA2i5BhAsmVDZ 6Rz3cfs+xbRijHY1RRFEhr9GVFg3xVgPrDKBiDZ9LLQzu1+xBfiu3d54/h9B5M9IMixI n1zGQbGRz2/Q1Hgebz42WSP6VfrdzPR9yW6qsCxijPxgJ66Z6C40QkPDs1MMT6ug25Uf pJ7w== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr113251lab.30.1347974856992; Tue, 18 Sep 2012 06:27:36 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Tue, 18 Sep 2012 06:27:36 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Tue, 18 Sep 2012 06:27:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 06:27:36 -0700 Message-ID: From: Cameron Byrne To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=f46d040714cf84688c04c9f9dabd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:27:39 -0000 --f46d040714cf84688c04c9f9dabd Content-Type: text/plain; charset=ISO-8859-1 On Sep 18, 2012 1:08 AM, wrote: > > Hi, > > Martin Thomson wrote: > > > >On 10 September 2012 07:15, Harald Alvestrand > >wrote: > >> - Pointers to documentation on how browsers are expected to be able to > >> set QCI and WiFI markings would be a good addition. Compared to those, > >> DSCP codepoint setting is well understood. > > > > > > >What do people think about NOT including QCI/WiFi markings? Is it not > >possible for a wireless interface to examine DSCP markings in order to > >determine the markings for the link? We should endeavour to maintain the > >proper abstractions. > > > > I'm not even sure if the browser or even the OS can influence much the QCI or bearer selection in LTE. I think the model is such that the "network" sets up these special non-best-effort bearers, and gives the endpoint the classifier rules related to them. The rules tell the endpoint how to map outgoing packets to the bearers. Typically the rules are based on source/destination IP and port, and the transport protocol. Someone may be able to confirm, but I believe DSCP can be used too. But basically the rules come from the network and the endpoint just follows them. > > So, somehow the browser or the JS app would first have to convince the access network provider to setup the special bearer so that the right flows get classified to it. In IMS the SIP proxy reads the SDP and tells some network element what audio or video flows are being setup and what their 5-tuples are, so the network is being able to setup the bearers correctly for them. The endpoint merely waits for this setup and acts accordingly. This works as the SIP proxy is run by the access operator. In RTCWeb the same could work if the calling site had a relationship with the access operator. I've heard that there is some work by some operators to offer Web APIs for 3rd party apps to do the bearer setup requests more ad hoc. Most of this may be outside the scope of RTCWeb but I think the document should have some explanation on how it works from the OS, browser, JS client, calling site, and mobile operator perspective. > > On the "transport" or "data path" level I don't think the browser needs to understand anything about QCIs. DSCP marking should be good enough. > > Anyone with more LTE/mobile clue that could comment on this? > > Markus > Your understanding is similar to mine. Generally speaking, qos in 3gpp networks is network initiated and controlled by a PCRF. The UEs are generally not trusted, as they may abuse qos. I am told that qos is an important differentiator for the operator run services and consequently will not be generally available to 3rd party apps such as webrtc. I am generally sceptical about qos on the internets, and we may be getting into a dangerous area if we start to assume networks will give anything more than best effort to webrtc. CB _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --f46d040714cf84688c04c9f9dabd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 18, 2012 1:08 AM, <Ma= rkus.Isomaki@nokia.com> wrote:
>
> Hi,
>
> Martin Thomson wrote:
> >
> >On 10 September 2012 07:15, Harald Alvestrand <harald@alvestrand.no>
> >wrote:
> >> - Pointers to documentation on how browsers are expected to b= e able to
> >> set QCI and WiFI markings would be a good addition. Compared = to those,
> >> DSCP codepoint setting is well understood.
> >
> <snip>
> >
> >What do people think about NOT including QCI/WiFi markings? =A0Is = it not
> >possible for a wireless interface to examine DSCP markings in orde= r to
> >determine the markings for the link? =A0We should endeavour to mai= ntain the
> >proper abstractions.
> >
>
> I'm not even sure if the browser or even the OS can influence much= the QCI or bearer selection in LTE. I think the model is such that the &qu= ot;network" sets up these special non-best-effort bearers, and gives t= he endpoint the classifier rules related to them. The rules tell the endpoi= nt how to map outgoing packets to the bearers. Typically the rules are base= d on source/destination IP and port, and the transport protocol. Someone ma= y be able to confirm, but I believe DSCP can be used too. But basically the= rules come from the network and the endpoint just follows them.
>
> So, somehow the browser or the JS app would first have to convince the= access network provider to setup the special bearer so that the right flow= s get classified to it. In IMS the SIP proxy reads the SDP and tells some n= etwork element what audio or video flows are being setup and what their 5-t= uples are, so the network is being able to setup the bearers correctly for = them. The endpoint merely waits for this setup and acts accordingly. This w= orks as the SIP proxy is run by the access operator. In RTCWeb the same cou= ld work if the calling site had a relationship with the access operator. I&= #39;ve heard that there is some work by some operators to offer Web APIs fo= r 3rd party apps to do the bearer setup requests more ad hoc. Most of this = may be outside the scope of RTCWeb but I think the document should have som= e explanation on how it works from the OS, browser, JS client, calling site= , and mobile operator perspective.
>
> On the "transport" or "data path" level I don'= t think the browser needs to understand anything about QCIs. DSCP marking s= hould be good enough.
>
> Anyone with more LTE/mobile clue that could comment on this?
>
> Markus
>

Your understanding is similar to mine.

Generally speaking, qos in 3gpp networks is network initiated and contro= lled by a PCRF. The UEs are generally not trusted, as they may abuse qos.

I am told that qos is an important differentiator for the operator run s= ervices and consequently will not be generally available to 3rd party apps = such as webrtc.

I am generally sceptical about qos on the internets, and we may be getti= ng into a dangerous area if we start to assume networks will give anything = more than best effort to webrtc.

CB _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--f46d040714cf84688c04c9f9dabd-- From fluffy@cisco.com Tue Sep 18 07:20:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696FC21F871E for ; Tue, 18 Sep 2012 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVlBPTNtDlO5 for ; Tue, 18 Sep 2012 07:20:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93221F871A for ; Tue, 18 Sep 2012 07:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=724; q=dns/txt; s=iport; t=1347978043; x=1349187643; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Tq23HdHH3cd9HO5qO5HQFYVA9jRa9fnTFahJNbCrOMU=; b=ltVg7xJSaO8wJx3Wj5zsVFmns1N53dJlpEpnPSBeuWnXH6zDF27nAd4+ xhEON7tkAMAxVxWu6KoNY8I1YtJvebN+FevS7jhHi6TbVcN2blMZqetUS CSlDMV+tHieDXBRiwKIEfSisUQGB2k1xReDtYJQ7Ub10j28/a0nxjy2t4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAI6CWFCtJV2a/2dsb2JhbABFhUK2eoEIgicSASdRAT5CJwQBNIdeC5oIoDORK2ADlWOBFI0kgWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122804437" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 18 Sep 2012 14:20:43 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8IEKhsW025237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 14:20:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 09:20:42 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: Background info about what is going on WebRTC / RTCWeb Thread-Index: AQHNlajJH6A/I7YTL0WO8AV0qbMwGQ== Date: Tue, 18 Sep 2012 14:20:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--24.951600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9B0B2357E6960146A50EE60FB3505179@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Background info about what is going on WebRTC / RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 14:20:44 -0000 I get lots of questions from folks trying to understand what is going on in= these working groups so I tried to put together a bit of a presentation t= hat is my best guess of what the system we are standardizing looks like and= helps provide the background info that people can better understand and pa= rticipate in some of the debates going on. You can find it at http://vimeo.com/cullenfluffyjennings/rtcwebexplained It is probably wrong in some ways and I know there are parts some folks wou= ld disagree with but it is just by best guess given the current information= on hand. If anyone wants to use the slides or parts of this for some other= presentation, just get drop and email.=20 Cullen From fluffy@cisco.com Tue Sep 18 09:16:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6C21E80F2 for ; Tue, 18 Sep 2012 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsvqXS5AmpSZ for ; Tue, 18 Sep 2012 09:16:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3225F21E80E7 for ; Tue, 18 Sep 2012 09:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1481; q=dns/txt; s=iport; t=1347984970; x=1349194570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BwHtA0NWNLnc99QsU+igV0pz80tJyNO+oVeNS9a6Qk8=; b=lzc0fAZUsNzE91cCBLXDZ64vE6VqhwS9HElv4kVeFz6G7Wtztp+zLqFA DXy2dNITmNme4Ri5Edk6o76TumM75M4rAncNP60VGi21+RbDLJbojqvbY 3H60HBknPx0aF9a3JtH0ugUb5N7ittGFa+8Bvmtsxnncy1KjTs4BDQNE8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANqdWFCtJV2a/2dsb2JhbABFvD+BCIIgAQEBAgEBEgFmEAIBCEYyJQIEDgUih1UDBguaGpFKjnGLG4YQYAOVY4EUjSSBaYJmgWM0 X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122824884" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Sep 2012 16:15:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8IGFnxX026902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 16:15:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 11:15:48 -0500 From: "Cullen Jennings (fluffy)" To: "Cullen Jennings (fluffy)" Thread-Topic: Background info about what is going on WebRTC / RTCWeb Thread-Index: AQHNlajJH6A/I7YTL0WO8AV0qbMwGZeQl+KA Date: Tue, 18 Sep 2012 16:15:48 +0000 Message-ID: <703286B8-BF6E-4D08-A21A-1206FFC9D91F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--27.384800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Background info about what is going on WebRTC / RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:16:11 -0000 On Sep 18, 2012, at 8:20 AM, Cullen Jennings wrote: >=20 > I get lots of questions from folks trying to understand what is going on = in these working groups so I tried to put together a bit of a presentation= that is my best guess of what the system we are standardizing looks like a= nd helps provide the background info that people can better understand and = participate in some of the debates going on. You can find it at >=20 > http://vimeo.com/cullenfluffyjennings/rtcwebexplained >=20 > It is probably wrong in some ways and I know there are parts some folks w= ould disagree with but it is just by best guess given the current informati= on on hand. If anyone wants to use the slides or parts of this for some oth= er presentation, just get drop and email.=20 >=20 > Cullen >=20 Because a few people asked, there is a VP8 version at=20 http://dl.dropbox.com/u/17089001/RtcWeb/RtcWebTake1-360p.webm PDF slides at http://dl.dropbox.com/u/17089001/RtcWeb/WebRTC_v8.pdf but be = warned, they make no sense without a talk track to go with them.=20 Cullen I've got all the video tools from adobe, apple, and avid but to crea= te this I had to grab the right check in of ffmpeg from the SVN for ffmeg, = then apply a patch from some other page, then deal with CLI options that ma= kes cisco router configuration look downright friendly and simple. Ask me h= ow I love living on the bleeding edge =85 = From lars@netapp.com Thu Sep 20 01:17:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D921F845F for ; Thu, 20 Sep 2012 01:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.851 X-Spam-Level: X-Spam-Status: No, score=-10.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1PGTbIxjCAMp for ; Thu, 20 Sep 2012 01:17:40 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F40621F8452 for ; Thu, 20 Sep 2012 01:17:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="p7s'?scan'208";a="691838605" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Sep 2012 01:17:38 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8K8Hcc2012261 for ; Thu, 20 Sep 2012 01:17:38 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0309.002; Thu, 20 Sep 2012 01:17:38 -0700 From: "Eggert, Lars" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) Thread-Index: AQHNj160A+7JjlEmH0OG6UCTgBP8bZeTZ2YA Date: Thu, 20 Sep 2012 08:17:37 +0000 Message-ID: References: <504DF5EF.7070602@alvestrand.no> In-Reply-To: <504DF5EF.7070602@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_BA89BD7C-40E9-47D7-AD80-12E513FCE62C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:17:40 -0000 --Apple-Mail=_BA89BD7C-40E9-47D7-AD80-12E513FCE62C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, agree that the QCI stuff is probably not useful to discuss. The DSCP content is almost fully redundant with what's in RFC4594 (which = is in the references but not cited). And RFC4594 has a much better = discussion on what DiffServ is and isn't. For WLAN, 802.11e is what you want to point to, I guess. So this doc - if it's even needed - could be MUCH shorter, by basically = just saying "read RFC4594 and map RTCweb flows into the classes defined = there like this" and do the equivalent for 802.11e. Lars= --Apple-Mail=_BA89BD7C-40E9-47D7-AD80-12E513FCE62C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkyMDA4MTczOFowIwYJKoZIhvcNAQkEMRYEFCyN QUIMfU5uMu3Vq5pGRSooJEfbMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBACdOP4h4 qWBoleiRprFk2+hh/gEtFN1u42b/Yy9PYUd24n1U5HMvzxJTjVtLGT1nNhKEeoDmx7R5VA5XEL1F +9/yAiJ6UhqZiIXlL9vgvAOjthrEtgItABrEqB7n0YhHHyLJvfYbdrca452iZnYmVXpGOai9jwmf P7rxyqCE53QGoKVHUFqqtyoPRFh1gwm8DiLfZ71nsdRawCpIODsZQqDdeFDQ1Bt/fnml2UDCpKOC kLnnQFLzZQTCJrmIFRrOtSLLBhetL+iuX4eg2IGmN8VcfbReWr8LT7mOzRgOBDQvSuuKvXtSLEVu aI5PJUoi5xKKH6T0DuXWGhyYIOLLrnMAAAAAAAA= --Apple-Mail=_BA89BD7C-40E9-47D7-AD80-12E513FCE62C-- From juberti@google.com Thu Sep 20 12:00:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8221E8094 for ; Thu, 20 Sep 2012 12:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 g6V6nY+mCF-Z for ; Thu, 20 Sep 2012 12:00:25 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD7EA21E8091 for ; Thu, 20 Sep 2012 12:00:23 -0700 (PDT) Received: by qcac10 with SMTP id c10so2295457qca.31 for ; Thu, 20 Sep 2012 12:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pHY/CY11ZbLs2Hsz4JwZptVrR8kxPQBJIO9QZqQFmYY=; b=nmMj8XBsQRry4qRB0lhPJdwp+S7Ao0P6gw+02rC1eRi8VgQgmrSrMEUtI3fLHrb22i IdFrG4kCBvdWmREXRRbyzDJkf03Ixbs+kyWzbsz+Q//Nxg4w2ou5wGoyjcNp31TicGT4 K8AivrL+mwRZ5LB7rnKyJgfZmYP7f1RzyKB9o7D//52jMiOwNZoVTYDbLFGbtYYGul7Z Eo/x8i5OfIM5CbPsadSWFpJcNf6uV0UW274vfCN0XKDUfztkE5CebQa80bI31E0aEpzB 2GkU0NdkRI5QZ7kYSrCpgemH4Dgffe8xli+O+41NM0DvJnb+gkwOEGkKjCQsvw8oW314 mtlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pHY/CY11ZbLs2Hsz4JwZptVrR8kxPQBJIO9QZqQFmYY=; b=mWenILErTfnuO6bQM9ZWqp4Carw6BSTy5lFPYXW+BItglfapsZUg9CCZ8PjfGW7/62 8HIejuuLzezQR9Uk3s5ql2r6WCnvCp8djk7h1fANNi7w0NTAL9GfI05JgY91E6os6/hI sj2D4u239tG/K+pB0ma/PHY5CQq7SoiOBCkWjGTvLjyEZkEC2Yp8cxmeu4BR8XNfcuM3 CzalFPO45MtHUvU9FoJBGb8DZpj2h0BUbdCY5Kw7RPoKFVsrA4x1iukg+l+Z8baV6vMZ 0J4KgOdwHNt3GUtWCgMmwYmno0SFnIlrgM9kD6R478g7UE+qq4XTwfjxUe371nU4I+o/ XEcA== Received: by 10.224.197.10 with SMTP id ei10mr6773187qab.49.1348167622657; Thu, 20 Sep 2012 12:00:22 -0700 (PDT) Received: by 10.224.197.10 with SMTP id ei10mr6773153qab.49.1348167622405; Thu, 20 Sep 2012 12:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.117.209 with HTTP; Thu, 20 Sep 2012 12:00:01 -0700 (PDT) In-Reply-To: References: <50508ED7.9080805@ericsson.com> From: Justin Uberti Date: Thu, 20 Sep 2012 12:00:01 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3005dc983b2d1804ca26bc16 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnEug1gtGhOt0nlIwvtrhoOFqj30OsIy0Fcsm+vXm+yuYBM0+l9F96GceNNyKGfK9X8h2RAyWPIhx7m4nSzwHRreeNB60DMIiRjmJCcJnMG1tHgGMKZum1Sa99gNFipG0d/9ItiwwT4e4Icx/vRXgmOZkct6uClu9lv9Hff2hDfT0jj6LIDRQDKatt/Y2I8EmwIvniO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:00:28 -0000 --20cf3005dc983b2d1804ca26bc16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have a few other things on my plate right now, but I'd be interested in working on this. On Wed, Sep 12, 2012 at 9:05 AM, Martin Thomson w= rote: > +1 > > I can't currently commit to writing specifications, but I'm certainly > willing to provide reviews. > > On 12 September 2012 06:32, Magnus Westerlund > wrote: > > WG, > > > > Based on this discussion the chairs conclusion is that there is require= d > > to have a definition of how trickle ICE is to work so that interoperabl= e > > implementations can be made. > > > > This WG is clearly not chartered to develop such a specification. Thus = a > > possible way forward is to do the work in the MMUSIC WG and develop an > > ICE mode for trickle. Such work would require someone to take the role > > of being proponent and drive the work in MMUSIC. > > > > Thus we chair wonder if there exist people willing to take on this > effort? > > > > We chairs will meantime discuss with our ADs and the MMUSIC WG chairs > > how they see on starting work in MMUSIC for this. > > > > Cheers > > > > Magnus Westerlund > > (As chair) > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf3005dc983b2d1804ca26bc16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have a few other things on my plate right now, but I'd be interested = in working on this.


On Wed, Sep 12, 2012 at 9:05 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
+1

I can't currently commit to writing specifications, but I'm certain= ly
willing to provide reviews.

On 12 September 2012 06:32, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> WG,
>
> Based on this discussion the chairs conclusion is that there is requir= ed
> to have a definition of how trickle ICE is to work so that interoperab= le
> implementations can be made.
>
> This WG is clearly not chartered to develop such a specification. Thus= a
> possible way forward is to do the work in the MMUSIC WG and develop an=
> ICE mode for trickle. Such work would require someone to take the role=
> of being proponent and drive the work in MMUSIC.
>
> Thus we chair wonder if there exist people willing to take on this eff= ort?
>
> We chairs will meantime discuss with our ADs and the MMUSIC WG chairs<= br> > how they see on starting work in MMUSIC for this.
>
> Cheers
>
> Magnus Westerlund
> (As chair)
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| P= hone =C2=A0+46 = 10 7148287
> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3005dc983b2d1804ca26bc16-- From emil@sip-communicator.org Thu Sep 20 12:12:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB521F872A for ; Thu, 20 Sep 2012 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgtsoOw2f1gE for ; Thu, 20 Sep 2012 12:12:04 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 11A9B21F86B9 for ; Thu, 20 Sep 2012 12:12:03 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so889532wib.13 for ; Thu, 20 Sep 2012 12:12:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=qHGBKEdszAHcRBSOoY9d5L9FtGOPZP3rAzNrdIQc3IA=; b=muydkfkOeE9gbxPfCFIaaPx1i95jzwS4XK3ViW1IZsVPkSK2aCs/dqKFiM8sl34+rp nsaf0dxM2EQASNLW/tCFy5YNKaEQk8mlKN6g+OPyZaUODDzKao0BiWT/83Z3rFeFau8J RVRl4mFnMk0lJgeYPQz+WqaR+7Xyi+wCr0q/xK7Z+nQ9N2wMU1hPHc8EbtWZffVsUYO4 h0C5csbysmEnhPqzdt1MbZvKB/V09EZflGGLUtmLpCHNWpKoYEoBj8BDHBmKTaA5L5Uc OChy/JKK9NnJ8BhAIY8bsMYEHj6f/gk76UTn5l8kdVO/TROf57MDkRBzOrGRx4CHOS30 TTOQ== Received: by 10.216.153.139 with SMTP id f11mr1652160wek.16.1348168323155; Thu, 20 Sep 2012 12:12:03 -0700 (PDT) Received: from [192.168.43.3] ([90.84.146.207]) by mx.google.com with ESMTPS id l6sm33927960wiz.4.2012.09.20.12.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 12:12:02 -0700 (PDT) Message-ID: <505B6A7E.6010309@jitsi.org> Date: Thu, 20 Sep 2012 21:11:58 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50508ED7.9080805@ericsson.com> In-Reply-To: <50508ED7.9080805@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmc+Qq5djesXnYCYp1duSbWvo6ujH6m4K9v2XTvlNP+rzM5WGZ0B6I5em0Mq5e3QL0Xp/uJ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:12:05 -0000 I'd be willing to work on this (writing and/or reviewing). Emil On 12.09.12, 15:32, Magnus Westerlund wrote: > WG, >=20 > Based on this discussion the chairs conclusion is that there is require= d > to have a definition of how trickle ICE is to work so that interoperabl= e > implementations can be made. >=20 > This WG is clearly not chartered to develop such a specification. Thus = a > possible way forward is to do the work in the MMUSIC WG and develop an > ICE mode for trickle. Such work would require someone to take the role > of being proponent and drive the work in MMUSIC. >=20 > Thus we chair wonder if there exist people willing to take on this effo= rt? >=20 > We chairs will meantime discuss with our ADs and the MMUSIC WG chairs > how they see on starting work in MMUSIC for this. >=20 > Cheers >=20 > Magnus Westerlund > (As chair) >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From juberti@google.com Thu Sep 20 17:07:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE95821E804D for ; Thu, 20 Sep 2012 17:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8PplMyNW3XGD for ; Thu, 20 Sep 2012 17:07:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0721E8047 for ; Thu, 20 Sep 2012 17:07:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so2514683qca.31 for ; Thu, 20 Sep 2012 17:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=DcvbyGAlyergRQv0sfJ+keaRtrejP0JKXXCvt2seKMc=; b=l52xtjgWWQGynzL5OaT6bWw43WMLI5/xGVIGrmv2ePaAsLKEASOSazPMXNgiuQ2mJQ 8Qr+keU6auKNqbzqBA/gycNkkIgrBEVctKtu9ItmmKMUYJ7S+tIMGuXGKzvFUCXAD/tE Ue4/HBnP143gGd6Z6Y1Zo8AiXU52APKkbST/XjHVitcsgaAmgjHZLafGkE/MsU2SeqPe 1z8SEy5Pm3LAzBnp0L7sD4loTCfhtay8r06EqZIDO22/U507BGp3hBflGUWqOzIl1K+C MlibJU19EAfXGAEACGWHxaLTfTcq1C78KPUbmoXo1lMXIZmf5bHiPYhhHE54rKwivrGe riDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=DcvbyGAlyergRQv0sfJ+keaRtrejP0JKXXCvt2seKMc=; b=gAYt0HJi5xgaLPqxx2XJ1K1vLitjO+FI9hYHQaCwOvDq1sQUBS0R3xjr71JCLcUtJ1 5kNN3fM2f2zh40olHgX79NX71OPQuZNzCLbp3i9E7q/7bM8rN1UCQbFkZHx7FpQQg6vS 9pJyjv/4U81yepDLMFPIJhfSp2NrQYRaR3QkQGMW0EvaXaoBIFd8eyu7id4tafeNZ1m8 lZmdjTFNaqy0/ng4K5vyaZrqiqogXdpjQUdEHZltduJIpuO7sV7YgCdnjmHEP243eUnu WoB8ki8jvTQthUpB6DF0X5oxK94RJEsD+SrdtyEtv/sDcdAwyYFgWkoaaqOvspOeT4Or tuCg== Received: by 10.224.220.138 with SMTP id hy10mr8523377qab.68.1348186038231; Thu, 20 Sep 2012 17:07:18 -0700 (PDT) Received: by 10.224.220.138 with SMTP id hy10mr8523302qab.68.1348186037456; Thu, 20 Sep 2012 17:07:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.117.209 with HTTP; Thu, 20 Sep 2012 17:06:56 -0700 (PDT) In-Reply-To: <505B6A7E.6010309@jitsi.org> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> From: Justin Uberti Date: Thu, 20 Sep 2012 17:06:56 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=20cf3074b9fcda8e3504ca2b054f X-System-Of-Record: true X-Gm-Message-State: ALoCoQltZTL1xdRaRZ7YATJ9i5d6zjc/jySt7eznzaarjZk05D6ZffiuurejXgS7sD5hYG6rZM9T0ZV+3dytwsmhmvRWUtWZLOLL2KxuLv32yd8illx6aOZyk1EPWFO5+B6Yq94wwDmGOHcg94EimpHZCkQ5/n8YubaZKjfDYFixwuqxuSPBC0BcixMLNoIXGW9RmXXCoIKh Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 00:07:20 -0000 --20cf3074b9fcda8e3504ca2b054f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla and I discussed some of the tricky trickle issues and wrote them down in this doc: https://docs.google.com/document/d/1L5SP9YQxXRf-2KObnDI5rgRCRnOv9EbhXsHsVis= Wp1Q/edit#. I think that would be a good starting point for an I-D on this. On Thu, Sep 20, 2012 at 12:11 PM, Emil Ivov wrote: > I'd be willing to work on this (writing and/or reviewing). > > Emil > > On 12.09.12, 15:32, Magnus Westerlund wrote: > > WG, > > > > Based on this discussion the chairs conclusion is that there is require= d > > to have a definition of how trickle ICE is to work so that interoperabl= e > > implementations can be made. > > > > This WG is clearly not chartered to develop such a specification. Thus = a > > possible way forward is to do the work in the MMUSIC WG and develop an > > ICE mode for trickle. Such work would require someone to take the role > > of being proponent and drive the work in MMUSIC. > > > > Thus we chair wonder if there exist people willing to take on this > effort? > > > > We chairs will meantime discuss with our ADs and the MMUSIC WG chairs > > how they see on starting work in MMUSIC for this. > > > > Cheers > > > > Magnus Westerlund > > (As chair) > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf3074b9fcda8e3504ca2b054f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla and I discussed some of the tricky trickle issues and wrote t= hem down in this doc:=C2=A0https://docs.google.com/d= ocument/d/1L5SP9YQxXRf-2KObnDI5rgRCRnOv9EbhXsHsVisWp1Q/edit#. I think t= hat would be a good starting point for an I-D on this.


On Thu, Sep 20, 2012 at 12:11 PM, Emil I= vov <emcho@jitsi.org> wrote:
I'd be willing to work on this (writing and/or reviewing).

Emil

On 12.09.12, 15:32, Magnus Westerlund wrote:
> WG,
>
> Based on this discussion the chairs conclusion is that there is requir= ed
> to have a definition of how trickle ICE is to work so that interoperab= le
> implementations can be made.
>
> This WG is clearly not chartered to develop such a specification. Thus= a
> possible way forward is to do the work in the MMUSIC WG and develop an=
> ICE mode for trickle. Such work would require someone to take the role=
> of being proponent and drive the work in MMUSIC.
>
> Thus we chair wonder if there exist people willing to take on this eff= ort?
>
> We chairs will meantime discuss with our ADs and the MMUSIC WG chairs<= br> > how they see on starting work in MMUSIC for this.
>
> Cheers
>
> Magnus Westerlund
> (As chair)
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| P= hone =C2=A0+46 = 10 7148287
> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--
Emil Ivov, Ph.D. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 67000 Strasbourg,
Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 France
Jitsi
emcho@jitsi.org =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PHONE: +33.1.77.62.43.30=
https://jitsi.org= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0FAX: =C2=A0 += 33.1.77.62.47.31


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3074b9fcda8e3504ca2b054f-- From hannes.tschofenig@gmx.net Fri Sep 21 05:09:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD121F84CD for ; Fri, 21 Sep 2012 05:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 DJP5uzjjAetX for ; Fri, 21 Sep 2012 05:09:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2F61221F8760 for ; Fri, 21 Sep 2012 05:09:20 -0700 (PDT) Received: (qmail invoked by alias); 21 Sep 2012 12:09:18 -0000 Received: from unknown (EHLO [10.255.133.193]) [194.251.119.201] by mail.gmx.net (mp072) with SMTP; 21 Sep 2012 14:09:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/TXecHJdDTtXt/pt/DrJPwrdw+z/EDdmtHcw3Q3d vD6fL6MEsTPBxa Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 21 Sep 2012 15:09:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <32407FD1-5A1F-4055-A1A3-3576835E9E84@gmx.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:09:21 -0000 Hi Cameron, Hi Markus,=20 your responses raise an interesting question: while everyone liked the = idea presented in draft-jennings-rtcweb-qos it may have pretty limited = practical value. There is the annoying layer issues (that we encounter = in other areas in the IETF as well) that crosses our way. For cellular = systems where the QoS mechanisms would provide the most benefits it does = not work. If it would work then the QoS procedure would be available at = the link layer during bearer establishment. For WLANs, where there are = the least problems, you could also use the link layer specific QoS = mechanisms (if at all needed). Same for Wimax.=20 On top of that there is the architectural issue (namely, how this is = supposed to work e2e). Not talking about the architectural story does = not make the problem go away. Ciao Hannes On Sep 18, 2012, at 4:27 PM, Cameron Byrne wrote: >=20 > On Sep 18, 2012 1:08 AM, wrote: > > > > Hi, > > > > Martin Thomson wrote: > > > > > >On 10 September 2012 07:15, Harald Alvestrand = > > >wrote: > > >> - Pointers to documentation on how browsers are expected to be = able to > > >> set QCI and WiFI markings would be a good addition. Compared to = those, > > >> DSCP codepoint setting is well understood. > > > > > > > > > > >What do people think about NOT including QCI/WiFi markings? Is it = not > > >possible for a wireless interface to examine DSCP markings in order = to > > >determine the markings for the link? We should endeavour to = maintain the > > >proper abstractions. > > > > > > > I'm not even sure if the browser or even the OS can influence much = the QCI or bearer selection in LTE. I think the model is such that the = "network" sets up these special non-best-effort bearers, and gives the = endpoint the classifier rules related to them. The rules tell the = endpoint how to map outgoing packets to the bearers. Typically the rules = are based on source/destination IP and port, and the transport protocol. = Someone may be able to confirm, but I believe DSCP can be used too. But = basically the rules come from the network and the endpoint just follows = them. > > > > So, somehow the browser or the JS app would first have to convince = the access network provider to setup the special bearer so that the = right flows get classified to it. In IMS the SIP proxy reads the SDP and = tells some network element what audio or video flows are being setup and = what their 5-tuples are, so the network is being able to setup the = bearers correctly for them. The endpoint merely waits for this setup and = acts accordingly. This works as the SIP proxy is run by the access = operator. In RTCWeb the same could work if the calling site had a = relationship with the access operator. I've heard that there is some = work by some operators to offer Web APIs for 3rd party apps to do the = bearer setup requests more ad hoc. Most of this may be outside the scope = of RTCWeb but I think the document should have some explanation on how = it works from the OS, browser, JS client, calling site, and mobile = operator perspective. > > > > On the "transport" or "data path" level I don't think the browser = needs to understand anything about QCIs. DSCP marking should be good = enough. > > > > Anyone with more LTE/mobile clue that could comment on this? > > > > Markus > > >=20 > Your understanding is similar to mine. >=20 > Generally speaking, qos in 3gpp networks is network initiated and = controlled by a PCRF. The UEs are generally not trusted, as they may = abuse qos. >=20 > I am told that qos is an important differentiator for the operator run = services and consequently will not be generally available to 3rd party = apps such as webrtc. >=20 > I am generally sceptical about qos on the internets, and we may be = getting into a dangerous area if we start to assume networks will give = anything more than best effort to webrtc. >=20 > CB _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tterriberry@mozilla.com Fri Sep 21 09:11:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535FB21F86C5 for ; Fri, 21 Sep 2012 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 o1E+mpklYe2k for ; Fri, 21 Sep 2012 09:11:15 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4954F21F867A for ; Fri, 21 Sep 2012 09:11:15 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 8DE5BF2663 for ; Fri, 21 Sep 2012 09:11:14 -0700 (PDT) Message-ID: <505C91A2.30008@mozilla.com> Date: Fri, 21 Sep 2012 09:11:14 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] video-codec mailing list and charter X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:11:16 -0000 Following the success of Opus, we are hoping to organize a BoF to consider forming a working group to standardize a video codec. While this will obviously not be finished in time to be MTI for initial deployments of WebRTC (or something is drastically wrong), many here may have some interest in the idea. Mailing list: https://www.ietf.org/mailman/listinfo/video-codec Initial charter proposal: http://www.ietf.org/mail-archive/web/video-codec/current/msg00002.html Please give comments and feedback! From richard@shockey.us Sat Sep 22 12:16:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67E21F8690 for ; Sat, 22 Sep 2012 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.508 X-Spam-Level: X-Spam-Status: No, score=-98.508 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 PMsexnl3z+Lg for ; Sat, 22 Sep 2012 12:16:16 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id D780821F8581 for ; Sat, 22 Sep 2012 12:16:15 -0700 (PDT) Received: (qmail 4142 invoked by uid 0); 22 Sep 2012 19:16:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 22 Sep 2012 19:16:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=MMiq6Yrs2OEG4EIocXWXifAggTnK5X/IpzzMGl9Tt0Y=; b=BxRawrdQwkHrFcNhD9dKljew2xquEXbVDOLfrvEuX8F5CFlMeUneKZgtRe58G9CodV/qk/Kjj5K46JJK3Hui/7+5y+CmBEmeMRS/EMxbDKn7POqLwUdN0mySxROzmsoh; Received: from [71.191.243.130] (port=52286 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TFVBV-0003pb-HM; Sat, 22 Sep 2012 13:16:13 -0600 From: "Richard Shockey" To: "'Timothy B. Terriberry'" , References: <505C91A2.30008@mozilla.com> In-Reply-To: <505C91A2.30008@mozilla.com> Date: Sat, 22 Sep 2012 15:16:09 -0400 Message-ID: <004001cd98f6$ba4bd0c0$2ee37240$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2YE78C5R3ZTxmzSFKlr/csKheDqwA4uOqg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] video-codec mailing list and charter X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 19:16:16 -0000 +1 Outstanding idea. Do it! -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Timothy B. Terriberry Sent: Friday, September 21, 2012 12:11 PM To: rtcweb@ietf.org Subject: [rtcweb] video-codec mailing list and charter Following the success of Opus, we are hoping to organize a BoF to consider forming a working group to standardize a video codec. While this will obviously not be finished in time to be MTI for initial deployments of WebRTC (or something is drastically wrong), many here may have some interest in the idea. Mailing list: https://www.ietf.org/mailman/listinfo/video-codec Initial charter proposal: http://www.ietf.org/mail-archive/web/video-codec/current/msg00002.html Please give comments and feedback! _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From richard@shockey.us Sat Sep 22 12:19:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3621F86B1 for ; Sat, 22 Sep 2012 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.343 X-Spam-Level: X-Spam-Status: No, score=-98.343 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 Arlof0JyHkdX for ; Sat, 22 Sep 2012 12:19:45 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 6E76021F859F for ; Sat, 22 Sep 2012 12:19:45 -0700 (PDT) Received: (qmail 20064 invoked by uid 0); 22 Sep 2012 19:19:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 22 Sep 2012 19:19:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=6E32gmtsWXvs7x3oSdCWQmN6FNgO4pfFRwXycsmsnMU=; b=IwpdwuKZtftO2ZQCvTvwjR1oW/M086SiEy6whESH5yWwmqtPJj6rtOy07LUSLIe6E3a5LcHsFocJ7XGrYXqlFiSjdujVZ/aRFKD7WFpz4Ho7dUdGx08u4W1bQH3jL2zX; Received: from [71.191.243.130] (port=52307 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TFVEt-0005XZ-TH for rtcweb@ietf.org; Sat, 22 Sep 2012 13:19:44 -0600 From: "Richard Shockey" To: Date: Sat, 22 Sep 2012 15:19:40 -0400 Message-ID: <004101cd98f7$37afbae0$a70f30a0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CD98D5.B09E1AE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Y9zZzgDBH7SjBQ/eFTQIiU1hVug== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: [rtcweb] BTW where are we at with MTI codecs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 19:19:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01CD98D5.B09E1AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do want to make it clear that SHOULD's should be included. I really really believe 722 AMR WB needs to be included in order to properly interoperate with Public SIP Networks (the former PSTN) and soon to be deployed Voice over LTE. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0042_01CD98D5.B09E1AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do want = to make it clear that SHOULD’s should be = included.

 

I really really believe 722 AMR WB needs to be = included in order to properly interoperate with  Public SIP = Networks (the former PSTN) and soon to be deployed Voice over LTE. =

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0042_01CD98D5.B09E1AE0-- From silviapfeiffer1@gmail.com Sat Sep 22 17:43:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DAE21F8501 for ; Sat, 22 Sep 2012 17:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXKRtUQPoANd for ; Sat, 22 Sep 2012 17:43:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA5E221F84D7 for ; Sat, 22 Sep 2012 17:43:23 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so5479489vbb.31 for ; Sat, 22 Sep 2012 17:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tja6mGzMbfrS2FFwaYBmMRm8DmlS/Tz5B7HCaz1ygkw=; b=W08EPFNpTCNbjF11O78kWzpBo3vlUVqhhS94/qBZglrapCVsTfAudVUqdD6d4TNrh5 hk0FqnsUvo3PEaacV2oxjAFqapZoClcwPaVqF22zOSIcHDNw7KegWm3n78P9aDwfINb/ yDXuJRjtDsfFS0UgWgElFbrxv2IgYq2IQ3UKietVi8wf1q7Idearpo0eHANpKRclm8Xz r7u1FkksIGsOZ5viHgngUoor/vPHKVJKFtfUCtZo/te46e9t6YkRiiMbTNcl9qhds/na 0ejTQ5NFuJ9TvwihUPcXTHtEN/rFwKAiiC6mf78ce5gZP6bVOKjVwvkv7mxOys9rWnBt +v4g== Received: by 10.59.1.162 with SMTP id bh2mr1659160ved.13.1348361003307; Sat, 22 Sep 2012 17:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.192.140 with HTTP; Sat, 22 Sep 2012 17:43:03 -0700 (PDT) In-Reply-To: <004001cd98f6$ba4bd0c0$2ee37240$@us> References: <505C91A2.30008@mozilla.com> <004001cd98f6$ba4bd0c0$2ee37240$@us> From: Silvia Pfeiffer Date: Sun, 23 Sep 2012 10:43:03 +1000 Message-ID: To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] video-codec mailing list and charter X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 00:43:24 -0000 On Sun, Sep 23, 2012 at 5:16 AM, Richard Shockey wrote: > +1 Outstanding idea. Do it! +1 of course! From dromasca@avaya.com Sun Sep 23 02:48:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8441F21F84CE for ; Sun, 23 Sep 2012 02:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xbI3x7MpPzdj for ; Sun, 23 Sep 2012 02:48:58 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C116521F84C9 for ; Sun, 23 Sep 2012 02:48:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPbZXlDGmAcF/2dsb2JhbABCA4JLu2KBCIIgAQEBAQMSChEDWQIBCA0EBAEBCwYMCwEGAUUJCAEBBAESCAEZh2MLm0CcGoscGoJrgkVgA4ghh2yCJ4RGhG6KIIJpgWE X-IronPort-AV: E=Sophos;i="4.80,470,1344225600"; d="scan'208,217";a="28207112" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Sep 2012 05:42:33 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Sep 2012 05:41:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD9970.A4408F51" Date: Sun, 23 Sep 2012 11:48:52 +0200 Message-ID: In-Reply-To: <004101cd98f7$37afbae0$a70f30a0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] BTW where are we at with MTI codecs? Thread-Index: Ac2Y9zZzgDBH7SjBQ/eFTQIiU1hVugAeLhdA References: <004101cd98f7$37afbae0$a70f30a0$@us> From: "Romascanu, Dan (Dan)" To: "Richard Shockey" , Subject: Re: [rtcweb] BTW where are we at with MTI codecs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 09:48:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD9970.A4408F51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe that the answer to the question in the subject line was given = in the message from the chairs at = http://www.ietf.org/mail-archive/web/rtcweb/current/msg05267.html. =20 So the question is rather - 'where we are with the non-MTI codecs?' (the = SHOULD codecs)?=20 =20 The chairs wrote in the same message:=20 =20 =D8 Based on the discussion to date, the chairs will run a consensus = call on =D8 whether the WG should recommend specific codecs which will not be =D8 mandatory to implement (i.e. will the document contain SHOULDs as = well =D8 as MUSTs for codec implementation)". If the response to that = consensus =D8 call indicates consensus for non-mandatory to implement = recommendations, =D8 we will run consensus calls on those codecs to be included at that = level. =D8 =20 =20 I think that that consensus call was not run yet.=20 =20 Regards, =20 Dan =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Richard Shockey Sent: Saturday, September 22, 2012 10:20 PM To: rtcweb@ietf.org Subject: [rtcweb] BTW where are we at with MTI codecs? =20 I do want to make it clear that SHOULD's should be included. =20 I really really believe 722 AMR WB needs to be included in order to = properly interoperate with Public SIP Networks (the former PSTN) and = soon to be deployed Voice over LTE.=20 =20 Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype-linkedin-facebook: rshockey101 http//www.sipforum.org =20 ------_=_NextPart_001_01CD9970.A4408F51 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I believe that the answer to the question in the = subject line was given in the message from the chairs at http://www.ietf.org/mail-archive/web/rtcweb/current/msg05267.html.<= o:p>

 

So the question is = rather – ‘where we are with the non-MTI codecs?’ (the = SHOULD codecs)?

 

The chairs wrote in the = same message:

 

=D8  Based on the discussion to date, the chairs will run a consensus = call on

=D8  whether the WG should recommend specific codecs which will not = be

=D8  mandatory to implement (i.e. will the document contain SHOULDs as = well

=D8  as MUSTs for codec implementation)".=A0 If the response to = that consensus

=D8  call indicates consensus for non-mandatory to implement = recommendations,

=D8  we will run consensus calls on those codecs to be included at that = level.

=D8   

 

I think that that = consensus call was not run yet.

 

Regards,

 

Dan

 

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Richard Shockey
Sent: Saturday, September 22, 2012 10:20 = PM
To: rtcweb@ietf.org
Subject: [rtcweb] BTW where = are we at with MTI codecs?

 

I do want to = make it clear that SHOULD’s should be included.

 

I really = really believe 722 AMR WB needs to be included in order to properly = interoperate with  Public SIP Networks (the former PSTN) and soon = to be deployed Voice over LTE.

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype-linkedin-facebook: = rshockey101
http//www.sipforum.org

 

------_=_NextPart_001_01CD9970.A4408F51-- From richard@shockey.us Sun Sep 23 08:09:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19D21F84AF for ; Sun, 23 Sep 2012 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.579 X-Spam-Level: X-Spam-Status: No, score=-99.579 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 kj1yMWION6hP for ; Sun, 23 Sep 2012 08:09:29 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 7BD3A21F84A6 for ; Sun, 23 Sep 2012 08:09:27 -0700 (PDT) Received: (qmail 29418 invoked by uid 0); 23 Sep 2012 15:09:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 23 Sep 2012 15:09:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=sI1IL3rXImIc/WU9i+8HdrrElhdz1WATFgQ8p97Y9wg=; b=Hbwqwaojrbnmwz/mDSZo+ZEgmXHeTcIUJwbKq+jGqjlatqVJ/7e/0gyqiuEr+pk4IrlYHwCcmeVGkHmXwwckY5SwsbRWMWQJbacii8n5Qrd5KN4+tIMHpeiFxEEclyQC; Received: from [71.191.243.130] (port=50869 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TFnoD-0005Ch-AI for rtcweb@ietf.org; Sun, 23 Sep 2012 09:09:26 -0600 From: "Richard Shockey" To: References: <004101cd98f7$37afbae0$a70f30a0$@us> In-Reply-To: Date: Sun, 23 Sep 2012 11:09:21 -0400 Message-ID: <006001cd999d$6a478680$3ed69380$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CD997B.E335E680" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Y9zZzgDBH7SjBQ/eFTQIiU1hVugAeLhdAAAs6m1A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] BTW where are we at with MTI codecs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 15:09:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01CD997B.E335E680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand that ..=20 =20 It would be helpful to run the consensus call ASAP so we could move on = to something more =94interesting=94 like resolving the offer/answer = model. =20 =20 I was archiving some of my email today to free up disk space.=20 =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Sunday, September 23, 2012 5:49 AM To: Richard Shockey; rtcweb@ietf.org Subject: RE: [rtcweb] BTW where are we at with MTI codecs? =20 I believe that the answer to the question in the subject line was given = in the message from the chairs at http://www.ietf.org/mail-archive/web/rtcweb/current/msg05267.html. =20 So the question is rather =96 =91where we are with the non-MTI = codecs?=92 (the SHOULD codecs)?=20 =20 The chairs wrote in the same message:=20 =20 =D8 Based on the discussion to date, the chairs will run a consensus = call on =D8 whether the WG should recommend specific codecs which will not be =D8 mandatory to implement (i.e. will the document contain SHOULDs as = well =D8 as MUSTs for codec implementation)". If the response to that = consensus =D8 call indicates consensus for non-mandatory to implement = recommendations, =D8 we will run consensus calls on those codecs to be included at that = level. =D8 =20 =20 I think that that consensus call was not run yet.=20 =20 Regards, =20 Dan =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Richard Shockey Sent: Saturday, September 22, 2012 10:20 PM To: rtcweb@ietf.org Subject: [rtcweb] BTW where are we at with MTI codecs? =20 I do want to make it clear that SHOULD=92s should be included. =20 I really really believe 722 AMR WB needs to be included in order to = properly interoperate with Public SIP Networks (the former PSTN) and soon to be deployed Voice over LTE.=20 =20 Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype-linkedin-facebook: rshockey101 http//www.sipforum.org =20 ------=_NextPart_000_0061_01CD997B.E335E680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I understand that ..

 

It would be helpful to = run the consensus call =A0ASAP so we could move on to something more = =A0”interesting” like resolving the offer/answer =A0model. = =A0

 

I was archiving some of = my email today to free up disk space.

 

From:= = Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: = Sunday, September 23, 2012 5:49 AM
To: Richard Shockey; = rtcweb@ietf.org
Subject: RE: [rtcweb] BTW where are we at with = MTI codecs?

 

I believe that the answer to the question in the = subject line was given in the message from the chairs at http://www.ietf.org/mail-archive/web/rtcweb/current/msg05267.html.<= o:p>

 

So the question is = rather – ‘where we are with the non-MTI codecs?’ (the = SHOULD codecs)?

 

The chairs wrote in the = same message:

 

=D8  Based on the = discussion to date, the chairs will run a consensus call = on

=D8  whether the WG = should recommend specific codecs which will not = be

=D8  mandatory to = implement (i.e. will the document contain SHOULDs as = well

=D8  as MUSTs for codec = implementation)".  If the response to that = consensus

=D8  call indicates = consensus for non-mandatory to implement = recommendations,

=D8  we will run = consensus calls on those codecs to be included at that = level.

=D8   

 

I think that that = consensus call was not run yet.

 

Regards,

 

Dan

 

 

 

 

I do want to = make it clear that SHOULD’s should be included.

 

I really = really believe 722 AMR WB needs to be included in order to properly = interoperate with  Public SIP Networks (the former PSTN) and soon = to be deployed Voice over LTE.

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype-linkedin-facebook: = rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0061_01CD997B.E335E680-- From basilgohar@librevideo.org Sun Sep 23 12:09:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AE221F84D5 for ; Sun, 23 Sep 2012 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] 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 YaKe1sm-YCC9 for ; Sun, 23 Sep 2012 12:09:36 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4E21F84A1 for ; Sun, 23 Sep 2012 12:09:36 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id CAFD2657F45 for ; Sun, 23 Sep 2012 15:09:34 -0400 (EDT) Message-ID: <505F5E6B.6090902@librevideo.org> Date: Sun, 23 Sep 2012 15:09:31 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <505C91A2.30008@mozilla.com> In-Reply-To: <505C91A2.30008@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] video-codec mailing list and charter X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 19:09:37 -0000 On 09/21/2012 12:11 PM, Timothy B. Terriberry wrote: > Following the success of Opus, we are hoping to organize a BoF to > consider forming a working group to standardize a video codec. While > this will obviously not be finished in time to be MTI for initial > deployments of WebRTC (or something is drastically wrong), many here > may have some interest in the idea. > > Mailing list: https://www.ietf.org/mailman/listinfo/video-codec > > Initial charter proposal: > http://www.ietf.org/mail-archive/web/video-codec/current/msg00002.html > > Please give comments and feedback! While I did not have time to go through the entire charter proposal, in principle from what I read and what I see described here, this is, to me, the next priority that needs to be address, so a strong +1 from me. -- Libre Video http://librevideo.org From elagerway@gmail.com Sun Sep 23 12:23:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8163921F84A1 for ; Sun, 23 Sep 2012 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 6L6Sr1Qc8GQU for ; Sun, 23 Sep 2012 12:23:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 534E221F845D for ; Sun, 23 Sep 2012 12:23:21 -0700 (PDT) Received: by lboj14 with SMTP id j14so5834453lbo.31 for ; Sun, 23 Sep 2012 12:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=icjnIG4AcJJI5x5FzV0nVMkEv5KfcglHd/+i999FA6M=; b=JZaOz/A3AygBhJBhUyBYin2DEA48QU2GiUgi/PxmTT9MVWoHBJasyeKIV64oiciW0C SSYyJrrg74ySjpt0C7PsR0yczpc4m7TnIxJzlY+qC/IxfUo8+R+0NdGtn87jVNPj7c8v POpaDSx8StWlZNq56biKYtbR4O/42Fbcls81OqHPSJkBnT+xUuJhDutfxm79LT/l111t bZ7X/KAJkhE8BYk53HFiT9iWDLChRARhOhC0K5PoC7qEo5uDcw4gzicIbvc07ii2hrra SZ7kwRt2y/zVLqXeTHm/l+oCr5CI0YBNuV+Ubd6L7XqTkoBsUoLG10LzFh2K233rFyLv Keog== MIME-Version: 1.0 Received: by 10.112.39.41 with SMTP id m9mr3584385lbk.80.1348428200095; Sun, 23 Sep 2012 12:23:20 -0700 (PDT) Sender: elagerway@gmail.com Received: by 10.114.28.103 with HTTP; Sun, 23 Sep 2012 12:23:20 -0700 (PDT) In-Reply-To: <505C91A2.30008@mozilla.com> References: <505C91A2.30008@mozilla.com> Date: Sun, 23 Sep 2012 12:23:20 -0700 X-Google-Sender-Auth: 32ALfjG9oPLYQiTgpQH7olGqkFo Message-ID: From: Erik Lagerway To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=485b390f7a24df2e7604ca63676b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] video-codec mailing list and charter X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 19:23:22 -0000 --485b390f7a24df2e7604ca63676b Content-Type: text/plain; charset=ISO-8859-1 +1 - Thx Timothy. *Erik Lagerway | *Hookflash * | m 1.604.562.8647* **** On Fri, Sep 21, 2012 at 9:11 AM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Following the success of Opus, we are hoping to organize a BoF to consider > forming a working group to standardize a video codec. While this will > obviously not be finished in time to be MTI for initial deployments of > WebRTC (or something is drastically wrong), many here may have some > interest in the idea. > > Mailing list: https://www.ietf.org/mailman/**listinfo/video-codec > > Initial charter proposal: http://www.ietf.org/mail-** > archive/web/video-codec/**current/msg00002.html > > Please give comments and feedback! > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --485b390f7a24df2e7604ca63676b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 - Thx Timothy.

Erik Lagerway | = = Hookflash= | m 1.604.562.8647
<= /span>


On Fri, Sep 21, 2012 at 9:11 AM, Timothy= B. Terriberry <tterriberry@mozilla.com> wrote:
Following the success of Opus, we are hoping to organize a BoF to consider = forming a working group to standardize a video codec. While this will obvio= usly not be finished in time to be MTI for initial deployments of WebRTC (o= r something is drastically wrong), many here may have some interest in the = idea.

Mailing list: https://www.ietf.org/mailman/listinfo/video-codec=

Initial charter proposal: http://www.ietf.org/mai= l-archive/web/video-codec/current/msg00002.html

Please give comments and feedback!
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--485b390f7a24df2e7604ca63676b-- From fluffy@cisco.com Sun Sep 23 16:05:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7421F851C for ; Sun, 23 Sep 2012 16:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJksWNHzLt7E for ; Sun, 23 Sep 2012 16:05:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 673CA21F851B for ; Sun, 23 Sep 2012 16:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5513; q=dns/txt; s=iport; t=1348441503; x=1349651103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1rZsrX7yIJyAKOS0Sn4FV/wVCBHWGEwTzVc0y4QRwxY=; b=lb2uPmN8cCaLCIb4Emh2ysNzs3aZ3O3fPpNDPkA7y0d9YT/wwIyXtQJG u1m6DVPdhhY6Xi0lUv1OM7VaBClefBsFUqHZMxnD6fIPxXFo1o6Fj6ra0 CZKL8crWRIcgY9gPzmu0jR73NWrXhwl2010Q/umKcuAuj2HipoBpdLJnU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8GAEqUX1CtJV2b/2dsb2JhbABFugmEKIEIgiABAQEDAQEBAQ8BJy0EAwQHBQsCAQgYHhAnCyUCBA4FIodRAwkGC5hInxUEijpiFIU2YAOSNIMxjjqBaYJngVo9 X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="121472537" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 23 Sep 2012 23:05:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8NN51xF019675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Sep 2012 23:05:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Sun, 23 Sep 2012 18:05:00 -0500 From: "Cullen Jennings (fluffy)" To: Hannes Tschofenig Thread-Topic: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? Thread-Index: AQHNmd/briaRKeB8VEy9VQkk/45NiQ== Date: Sun, 23 Sep 2012 23:04:59 +0000 Message-ID: <485290AF-2E33-4E69-BCDE-A4862A096F24@cisco.com> References: <32407FD1-5A1F-4055-A1A3-3576835E9E84@gmx.net> In-Reply-To: <32407FD1-5A1F-4055-A1A3-3576835E9E84@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--47.115600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3C0FB34FAF317A4C955C3149B76F3DC2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 23:05:04 -0000 I don't think the DSCP stuff in the draft is trying to solve any end to end= problems or even make any guarantees about QoS anywhere. But the draft doe= s clearly state where this does sometimes help (like the local DSL uplink f= rom my house) and points out it won't help for something like end to end.=20 On the topic of the QCI on smart phones. I agree that untrusted 3rd party a= pplications are probably not going to be able to request QoS on most carrie= r networks. However, some carriers are clearly looking at the idea that the= re could be carrier provided RTCWeb applications that have a trust relation= ship that allows them to get different treatment. I don't claim to be a LTE= expert but luckily Dan is an architect at a major carrier with strong inte= rest in LTE so I'm pretty sure he can get this straightened out.=20 On Sep 21, 2012, at 6:09 AM, Hannes Tschofenig = wrote: > Hi Cameron, Hi Markus,=20 >=20 > your responses raise an interesting question: while everyone liked the id= ea presented in draft-jennings-rtcweb-qos it may have pretty limited practi= cal value. There is the annoying layer issues (that we encounter in other a= reas in the IETF as well) that crosses our way. For cellular systems where = the QoS mechanisms would provide the most benefits it does not work. If it = would work then the QoS procedure would be available at the link layer duri= ng bearer establishment. For WLANs, where there are the least problems, you= could also use the link layer specific QoS mechanisms (if at all needed). = Same for Wimax.=20 >=20 > On top of that there is the architectural issue (namely, how this is supp= osed to work e2e). Not talking about the architectural story does not make = the problem go away. >=20 > Ciao > Hannes >=20 > On Sep 18, 2012, at 4:27 PM, Cameron Byrne wrote: >=20 >>=20 >> On Sep 18, 2012 1:08 AM, wrote: >>>=20 >>> Hi, >>>=20 >>> Martin Thomson wrote: >>>>=20 >>>> On 10 September 2012 07:15, Harald Alvestrand >>>> wrote: >>>>> - Pointers to documentation on how browsers are expected to be able t= o >>>>> set QCI and WiFI markings would be a good addition. Compared to those= , >>>>> DSCP codepoint setting is well understood. >>>>=20 >>> >>>>=20 >>>> What do people think about NOT including QCI/WiFi markings? Is it not >>>> possible for a wireless interface to examine DSCP markings in order to >>>> determine the markings for the link? We should endeavour to maintain = the >>>> proper abstractions. >>>>=20 >>>=20 >>> I'm not even sure if the browser or even the OS can influence much the = QCI or bearer selection in LTE. I think the model is such that the "network= " sets up these special non-best-effort bearers, and gives the endpoint the= classifier rules related to them. The rules tell the endpoint how to map o= utgoing packets to the bearers. Typically the rules are based on source/des= tination IP and port, and the transport protocol. Someone may be able to co= nfirm, but I believe DSCP can be used too. But basically the rules come fro= m the network and the endpoint just follows them. >>>=20 >>> So, somehow the browser or the JS app would first have to convince the = access network provider to setup the special bearer so that the right flows= get classified to it. In IMS the SIP proxy reads the SDP and tells some ne= twork element what audio or video flows are being setup and what their 5-tu= ples are, so the network is being able to setup the bearers correctly for t= hem. The endpoint merely waits for this setup and acts accordingly. This wo= rks as the SIP proxy is run by the access operator. In RTCWeb the same coul= d work if the calling site had a relationship with the access operator. I'v= e heard that there is some work by some operators to offer Web APIs for 3rd= party apps to do the bearer setup requests more ad hoc. Most of this may b= e outside the scope of RTCWeb but I think the document should have some exp= lanation on how it works from the OS, browser, JS client, calling site, and= mobile operator perspective. >>>=20 >>> On the "transport" or "data path" level I don't think the browser needs= to understand anything about QCIs. DSCP marking should be good enough. >>>=20 >>> Anyone with more LTE/mobile clue that could comment on this? >>>=20 >>> Markus >>>=20 >>=20 >> Your understanding is similar to mine. >>=20 >> Generally speaking, qos in 3gpp networks is network initiated and contro= lled by a PCRF. The UEs are generally not trusted, as they may abuse qos. >>=20 >> I am told that qos is an important differentiator for the operator run s= ervices and consequently will not be generally available to 3rd party apps = such as webrtc. >>=20 >> I am generally sceptical about qos on the internets, and we may be getti= ng into a dangerous area if we start to assume networks will give anything = more than best effort to webrtc. >>=20 >> CB _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Sun Sep 23 16:06:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E721F851C for ; Sun, 23 Sep 2012 16:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su8gtkvT9NvX for ; Sun, 23 Sep 2012 16:06:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB821F8525 for ; Sun, 23 Sep 2012 16:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2573; q=dns/txt; s=iport; t=1348441606; x=1349651206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fibalyt6lFl1WdowkdS9WEg3mrD0Oey+mjSLp7wvghU=; b=OHmsuJIWv7XzCYu105JEnvcMFss95PDOximtvmQiEycBnI4EBEkHGLUA WMh0/bhMOY1v5gx2vbeIBlqXtDZ/1wJGyuyteRa/3ip5MS+DwozQH7QsU DWnAZq80ak0cUUEZHN6HDUKdCCdT7UcHc5A+1g9NVOoBza0z3AotIRrO4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALiVX1CtJV2c/2dsb2JhbABFvjGBCIIgAQEBAwEBAQEJBgFbCwUJAgIBCA4KJwcbDAsUEQIEDgUih10GC5hInxYEBIsYhUpgA4ghjUSOOoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="124513648" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 23 Sep 2012 23:06:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8NN6jri006525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Sep 2012 23:06:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Sun, 23 Sep 2012 18:06:45 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNmeAZG9HIi6Jp2Eqo3+7YsAvZGw== Date: Sun, 23 Sep 2012 23:06:44 +0000 Message-ID: <04A7E4B4-D19F-46B5-B7B1-12046E97391B@cisco.com> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--52.392700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 23:06:54 -0000 Just read that and I like it.=20 On Sep 20, 2012, at 6:06 PM, Justin Uberti wrote: > Eric Rescorla and I discussed some of the tricky trickle issues and wrote= them down in this doc: https://docs.google.com/document/d/1L5SP9YQxXRf-2KO= bnDI5rgRCRnOv9EbhXsHsVisWp1Q/edit#. I think that would be a good starting p= oint for an I-D on this. >=20 >=20 > On Thu, Sep 20, 2012 at 12:11 PM, Emil Ivov wrote: > I'd be willing to work on this (writing and/or reviewing). >=20 > Emil >=20 > On 12.09.12, 15:32, Magnus Westerlund wrote: > > WG, > > > > Based on this discussion the chairs conclusion is that there is require= d > > to have a definition of how trickle ICE is to work so that interoperabl= e > > implementations can be made. > > > > This WG is clearly not chartered to develop such a specification. Thus = a > > possible way forward is to do the work in the MMUSIC WG and develop an > > ICE mode for trickle. Such work would require someone to take the role > > of being proponent and drive the work in MMUSIC. > > > > Thus we chair wonder if there exist people willing to take on this effo= rt? > > > > We chairs will meantime discuss with our ADs and the MMUSIC WG chairs > > how they see on starting work in MMUSIC for this. > > > > Cheers > > > > Magnus Westerlund > > (As chair) > > > > ---------------------------------------------------------------------- > > 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 > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Sun Sep 23 16:24:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357B421F8549 for ; Sun, 23 Sep 2012 16:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PRviAQzNIWFO for ; Sun, 23 Sep 2012 16:24:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09921F851E for ; Sun, 23 Sep 2012 16:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1348442641; x=1349652241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uPuvrw19VcmyA+mKm3rOCxJN0/f4WEwF4sMNsM3cDQE=; b=Jwm9y7VQB3jJMUs+yuhk3pxX5jptzulUtcWkm0pUwcOOhiJymUer5t98 qCGiSTkVt6OvPkn79dcH20JNS3PnvnE9Cqw9Jn/bT4dAP73p+Aj6yrs5q KmX8HXyTu6PqDesP2WKukmIWjsWaXWw7RHRa6LZuBUje4eLoiSlz1KbfD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFyZX1CtJV2a/2dsb2JhbABFvjGBCIIgAQEBAwEBAQEPAQpRCwULAgEIRicLJQIEDgUih10GC5hRnxQEixyFSmADlWWOOoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="121474260" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 23 Sep 2012 23:24:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8NNO14m014534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Sep 2012 23:24:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sun, 23 Sep 2012 18:24:00 -0500 From: "Cullen Jennings (fluffy)" To: "Eggert, Lars" Thread-Topic: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) Thread-Index: AQHNmeKCSOO+xJEo+0C5OscrfiPriw== Date: Sun, 23 Sep 2012 23:23:59 +0000 Message-ID: <15FDEAA7-E6F7-47FE-B9E5-9144B3B44DC8@cisco.com> References: <504DF5EF.7070602@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--48.124000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2BCCD7ACE091374DA975EB26F44D66CD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-qos (Re: Call for adoption of QoS draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 23:24:02 -0000 On Sep 20, 2012, at 2:17 AM, "Eggert, Lars" wrote: > Hi, >=20 > agree that the QCI stuff is probably not useful to discuss. >=20 > The DSCP content is almost fully redundant with what's in RFC4594 (which = is in the references but not cited). And RFC4594 has a much better discussi= on on what DiffServ is and isn't. So this is trying to work within the bounds of 4594 (and clearly needs to r= eference that) but I think this narrows things down a bit more that 4594 mi= ght or at least tries to clarify things a bit .=20 For example 4594 says use "Multimedia Conferencing service class is best su= ited =85 video conferencing service" It also says "Real-Time Interactive is intended for =85 and video conferenc= ing applications" It also suggest there are times the right thing for video might be "Multime= dia Streaming service class" As a result we see some major vendors shipping video phone like devices usi= ng CSx class while others are using AFx set.=20 So this may be 100% redundant with 4594 depending on your point of view - o= r it might not be redundant - but we need one clear unambiguous thing abou= t what needs to happen. If it can be reduced to two sentences, I'm all for = that.=20 >=20 > For WLAN, 802.11e is what you want to point to, I guess. >=20 > So this doc - if it's even needed - could be MUCH shorter, by basically j= ust saying "read RFC4594 and map RTCweb flows into the classes defined ther= e like this" and do the equivalent for 802.11e. It also forms the requirement for the three priority levels at a JS layer a= nd pointed out we don't want the JS setting if a stream is says audio or vi= deo. >=20 > Lars_______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tireddy@cisco.com Sun Sep 23 21:29:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB8B21F8555 for ; Sun, 23 Sep 2012 21:29:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU6SmmxfpoqU for ; Sun, 23 Sep 2012 21:29:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 043A721F853F for ; Sun, 23 Sep 2012 21:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6605; q=dns/txt; s=iport; t=1348460958; x=1349670558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=77f7oaMZqXBJk4TBiRpeTpV24VYm04nyIVvodIeTh24=; b=ARTbAwOkKAaHC9E3eZHKxjrss6GY6gPJ/cjWwvDqFmi1zbChHyOkcr3R L0NJ8rv3ortzO4prTrTArxBk3GNgXAZJx6rTKP4qz1yrvDf9pVszOXiB4 I3hWOy8NWnZBZnMFV7v923zLf3tQaR7F8YP5gljpC5dUYp1xHx+oMy0PI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGAMfgX1CtJXHB/2dsb2JhbABEugWEKoEIgiABAQEDAQEBAQ8BJy0EAwQHBQcEAgEIEQQBAQEKFAkHJwsUCQgBAQQBDQUIGodRAwkGC5hwnxYEijpiFIU2YAOSNJFrgWmCZ4FaPQ X-IronPort-AV: E=Sophos;i="4.80,473,1344211200"; d="scan'208";a="124532117" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 24 Sep 2012 04:29:17 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8O4TH3u004473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 04:29:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Sun, 23 Sep 2012 23:29:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Cullen Jennings (fluffy)" , Hannes Tschofenig Thread-Topic: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? Thread-Index: Ac2VbwTgBW+2KYNOQASP2tZPnOnMPgAXEHIAAJQi3AAAe3xegAAArBRA Date: Mon, 24 Sep 2012 04:29:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147B1D4B@xmb-rcd-x10.cisco.com> References: <32407FD1-5A1F-4055-A1A3-3576835E9E84@gmx.net> <485290AF-2E33-4E69-BCDE-A4862A096F24@cisco.com> In-Reply-To: <485290AF-2E33-4E69-BCDE-A4862A096F24@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--56.179100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 04:29:19 -0000 Hi Cullen - You may want to look into (3GPP TS 23.401 V11.3.0) which permits UE to requ= est bearer resource modification. Section 5.4.5 "The UE requested bearer resource modification procedure for an E-UTRAN is = depicted in figure 5.4.5-1. The procedure allows the UE to request for a mo= dification of bearer resources (e.g. allocation or release of resources) fo= r one traffic flow aggregate with a specific QoS demand." --Tiru. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Cullen Jennings (fluffy) > Sent: Monday, September 24, 2012 4:35 AM > To: Hannes Tschofenig > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"? >=20 >=20 > I don't think the DSCP stuff in the draft is trying to solve any end to e= nd > problems or even make any guarantees about QoS anywhere. But the draft do= es > clearly state where this does sometimes help (like the local DSL uplink f= rom > my house) and points out it won't help for something like end to end. >=20 > On the topic of the QCI on smart phones. I agree that untrusted 3rd party > applications are probably not going to be able to request QoS on most car= rier > networks. However, some carriers are clearly looking at the idea that the= re > could be carrier provided RTCWeb applications that have a trust relations= hip > that allows them to get different treatment. I don't claim to be a LTE ex= pert > but luckily Dan is an architect at a major carrier with strong interest i= n LTE > so I'm pretty sure he can get this straightened out. >=20 >=20 >=20 >=20 > On Sep 21, 2012, at 6:09 AM, Hannes Tschofenig > wrote: >=20 > > Hi Cameron, Hi Markus, > > > > your responses raise an interesting question: while everyone liked the = idea > presented in draft-jennings-rtcweb-qos it may have pretty limited practic= al > value. There is the annoying layer issues (that we encounter in other are= as in > the IETF as well) that crosses our way. For cellular systems where the Qo= S > mechanisms would provide the most benefits it does not work. If it would = work > then the QoS procedure would be available at the link layer during bearer > establishment. For WLANs, where there are the least problems, you could a= lso > use the link layer specific QoS mechanisms (if at all needed). Same for W= imax. > > > > On top of that there is the architectural issue (namely, how this is > supposed to work e2e). Not talking about the architectural story does not= make > the problem go away. > > > > Ciao > > Hannes > > > > On Sep 18, 2012, at 4:27 PM, Cameron Byrne wrote: > > > >> > >> On Sep 18, 2012 1:08 AM, wrote: > >>> > >>> Hi, > >>> > >>> Martin Thomson wrote: > >>>> > >>>> On 10 September 2012 07:15, Harald Alvestrand > >>>> wrote: > >>>>> - Pointers to documentation on how browsers are expected to be able= to > >>>>> set QCI and WiFI markings would be a good addition. Compared to tho= se, > >>>>> DSCP codepoint setting is well understood. > >>>> > >>> > >>>> > >>>> What do people think about NOT including QCI/WiFi markings? Is it n= ot > >>>> possible for a wireless interface to examine DSCP markings in order = to > >>>> determine the markings for the link? We should endeavour to maintai= n the > >>>> proper abstractions. > >>>> > >>> > >>> I'm not even sure if the browser or even the OS can influence much th= e QCI > or bearer selection in LTE. I think the model is such that the "network" = sets > up these special non-best-effort bearers, and gives the endpoint the > classifier rules related to them. The rules tell the endpoint how to map > outgoing packets to the bearers. Typically the rules are based on > source/destination IP and port, and the transport protocol. Someone may b= e > able to confirm, but I believe DSCP can be used too. But basically the ru= les > come from the network and the endpoint just follows them. > >>> > >>> So, somehow the browser or the JS app would first have to convince th= e > access network provider to setup the special bearer so that the right flo= ws > get classified to it. In IMS the SIP proxy reads the SDP and tells some > network element what audio or video flows are being setup and what their = 5- > tuples are, so the network is being able to setup the bearers correctly f= or > them. The endpoint merely waits for this setup and acts accordingly. This > works as the SIP proxy is run by the access operator. In RTCWeb the same = could > work if the calling site had a relationship with the access operator. I'v= e > heard that there is some work by some operators to offer Web APIs for 3rd > party apps to do the bearer setup requests more ad hoc. Most of this may = be > outside the scope of RTCWeb but I think the document should have some > explanation on how it works from the OS, browser, JS client, calling site= , and > mobile operator perspective. > >>> > >>> On the "transport" or "data path" level I don't think the browser nee= ds to > understand anything about QCIs. DSCP marking should be good enough. > >>> > >>> Anyone with more LTE/mobile clue that could comment on this? > >>> > >>> Markus > >>> > >> > >> Your understanding is similar to mine. > >> > >> Generally speaking, qos in 3gpp networks is network initiated and > controlled by a PCRF. The UEs are generally not trusted, as they may abus= e > qos. > >> > >> I am told that qos is an important differentiator for the operator run > services and consequently will not be generally available to 3rd party ap= ps > such as webrtc. > >> > >> I am generally sceptical about qos on the internets, and we may be get= ting > into a dangerous area if we start to assume networks will give anything m= ore > than best effort to webrtc. > >> > >> CB _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon Sep 24 01:19:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEE421F849A for ; Mon, 24 Sep 2012 01:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Q0kYVbMO+X for ; Mon, 24 Sep 2012 01:19:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3524521F8498 for ; Mon, 24 Sep 2012 01:19:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-de-506017865e99 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 90.F4.11467.68710605; Mon, 24 Sep 2012 10:19:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Mon, 24 Sep 2012 10:19:18 +0200 Message-ID: <50601786.7030903@ericsson.com> Date: Mon, 24 Sep 2012 10:19:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Richard Shockey References: <004101cd98f7$37afbae0$a70f30a0$@us> <006001cd999d$6a478680$3ed69380$@us> In-Reply-To: <006001cd999d$6a478680$3ed69380$@us> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrW67eEKAwfczHBYzfhhYrP3Xzu7A 5LFkyU8mj4kfzzAHMEVx2aSk5mSWpRbp2yVwZZz8eIW14K94xd+brYwNjOuFuhg5OSQETCRu L1nBDmGLSVy4t56ti5GLQ0jgFKPE/qsboZzljBLf9yxhAqniFdCWODJpPxuIzSKgKnH59zVW EJtNwELi5o9GsLioQLDEpP1bWCDqBSVOznwCZosIaEi07OsCs5kF1CXuLD4HtllYwEpi8dqD rBDL5jJKvJpwmhkkwSlgKPH1SiPUeZISbybfhGo2kDiyaA4rhC0v0bx1Nli9ENBxDU0drBMY hWYh2T0LScssJC0LGJlXMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIEBvHBLb91dzCeOidyiFGa g0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaAfz7PbkVuFF9prPj2B9OaWlbX pZIF28OCfu9cc0DU5WbrAu+MBWu+le3p0dyqvyJgd8AFWT2FNbEdM154JzdYTnzC3sDLxbDk fU6932m2TRXfNrWlCifvK0p5wl0iZ5rQoTrVsINN6FL48jZ+9RPendcFGTs9ek/fKLqc6fFt i5VArsn2G0osxRmJhlrMRcWJAHjj0mswAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BTW where are we at with MTI codecs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 08:19:24 -0000 WG, We are sorry that we haven't started the consensus call. It was intended to be started already, but some issues have made us hold the call. We hope to be able to start it soon. Cheers Magnus Westerlund WG chair. On 2012-09-23 17:09, Richard Shockey wrote: > I understand that .. > > > > It would be helpful to run the consensus call ASAP so we could move on > to something more ”interesting” like resolving the offer/answer model. > > > > I was archiving some of my email today to free up disk space. > > > > *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > *Sent:* Sunday, September 23, 2012 5:49 AM > *To:* Richard Shockey; rtcweb@ietf.org > *Subject:* RE: [rtcweb] BTW where are we at with MTI codecs? > > > > I believe that the answer to the question in the subject line was given > in the message from the chairs at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05267.html. > > > > So the question is rather – ‘where we are with the non-MTI codecs?’ (the > SHOULD codecs)? > > > > The chairs wrote in the same message: > > > > Ø Based on the discussion to date, the chairs will run a consensus call on > > Ø whether the WG should recommend specific codecs which will not be > > Ø mandatory to implement (i.e. will the document contain SHOULDs as well > > Ø as MUSTs for codec implementation)". If the response to that consensus > > Ø call indicates consensus for non-mandatory to implement recommendations, > > Ø we will run consensus calls on those codecs to be included at that level. > > Ø > > > > I think that that consensus call was not run yet. > > > > Regards, > > > > Dan > > > > > > > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Richard Shockey > *Sent:* Saturday, September 22, 2012 10:20 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] BTW where are we at with MTI codecs? > > > > I do want to make it clear that SHOULD’s should be included. > > > > I really really believe 722 AMR WB needs to be included in order to > properly interoperate with Public SIP Networks (the former PSTN) and > soon to be deployed Voice over LTE. > > > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org > > > -- 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 christer.holmberg@ericsson.com Wed Sep 26 01:24:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA76B21F8813 for ; Wed, 26 Sep 2012 01:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 MqWNjAw2PqQ3 for ; Wed, 26 Sep 2012 01:24:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A41B21F87BC for ; Wed, 26 Sep 2012 01:24:37 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-bd-5062bbc4bb3b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C2.40.25676.4CBB2605; Wed, 26 Sep 2012 10:24:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 26 Sep 2012 10:24:35 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 26 Sep 2012 10:24:34 +0200 Thread-Topic: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 Thread-Index: Ac2bwFvdYsFR5hrrSJW13FYrQXSS9Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvre6R3UkBBk+vG1us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE/z5jMW9BlW/PswgamBcbFOFyMnh4SAicT2vTOYIWwxiQv3 1rN1MXJxCAmcYpT4vrWXCcJZwCix8/I81i5GDg42AQuJ7n/aIA0iAuoSlx9eYAexWQRUJd6e XsIGYgsLBEv0bT3IAlETIrH6wEpGCFtP4kbvJLB6XoFwia+btoEtZgRa/P3UGiYQm1lAXOLW k/lMEAeJSDy8eJoNwhaVePn4HytEvajEnfb1jBD1mRIX+j+yQswUlDg58wnLBEahWUhGzUJS NgtJGUQ8X6Lt+VkoW0diwe5PbBC2tsSyha+ZYewzBx4zYYrrShw5f4wdwlaUaNveDNTLBWSv YJQ4934FI0xiSvdD9gWMPKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQIj8eCW36o7GO+cEznE KM3BoiTOa711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtiZF4/GnnluOe99bMep61eZ OF1XzM0OuXbcSHMps5KtI0fs1cfhl940Ry+s38V162Pr7gval+/fiZTftN3xysOt33tDHB8y hcYynw+0Oa3Qed2/4NC3Wa8NzndbKbje/dsR9jTwddCv9/f+/P6R1yL/WzRANqI1OSXp3Tcx dYUNp67PUfc5u1iJpTgj0VCLuag4EQDiyFh/kgIAAA== Subject: [rtcweb] FW: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:24:39 -0000 --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_ Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_" --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I've submitted the max-ssrc draft to MMUSIC. The mechanism may be of intere= st for RTCWEB. Regards, Christer (Associated IPR: https://datatracker.ietf.org/ipr/1639/) From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 26. syyskuuta 2012 10:23 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version/working group: draft-westerlund-mmusic-= max-ssrc-00 Hi, We have submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc. The draft SDP entities to, within an m- line, indicate sending and receivin= g capabilities for multiple streams, based on used payload types. Earlier versions of the draft were submitted to AVTCORE. However, we think = MMUSIC is more appropriate, due to the new SDP attributes etc. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,

 

I’ve submitted the max-ssrc draft to MMUSIC. The = mechanism may be of interest for RTCWEB.

 

Regards,

 

Christer

 

(Associated = IPR: https://datatracker.ietf.org/ipr/1639/)

 

 

=

From: mmusic-bounces@ietf.org [mailto:mmus= ic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: = 26. syyskuuta 2012 10:23
To: mmusic@ietf.org
Subject: [= MMUSIC] Draft new version/working group: draft-westerlund-mmusic-max-ssrc-0= 0

 

Hi,

 

= We have submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc.=

 

The draft SDP entities to, within an m- line, indicate sending and recei= ving capabilities for multiple streams, based on used payload types.

 

Earl= ier versions of the draft were submitted to AVTCORE. However, we think MMUS= IC is more appropriate, due to the new SDP attributes etc.

 

Regards,<= /o:p>

 

Chr= ister

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_-- --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Wed, 26 Sep 2012 07:24:47 GMT"; modification-date="Wed, 26 Sep 2012 07:24:47 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D21ESESSCMS0356e_-- From albrecht.schwarz@alcatel-lucent.com Wed Sep 26 16:20:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006E421F84FC; Wed, 26 Sep 2012 16:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=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 Tsm-4E8t7uro; Wed, 26 Sep 2012 16:20:41 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3DECB21F84DC; Wed, 26 Sep 2012 16:20:39 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8QNKVnp027493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Sep 2012 01:20:32 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 27 Sep 2012 01:20:31 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Romascanu, Dan (Dan)" , Qin Wu , "xrblock@ietf.org" Date: Thu, 27 Sep 2012 01:20:30 +0200 Thread-Topic: [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt Thread-Index: Ac2biKI5HDMROYUJSuqglnnTvj87swARIVsAABvc8BA= Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com> <20E112E82D30472AA48E653041BC0A78@china.huawei.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, 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.80 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 23:20:51 -0000 > I am happy to see my comments being forwarded to rtcweb@ietf.org if they > are interested and want to more input from XRBLOCK WG. However I am not > sure how much of their work is related to XRBLOCK work? Do they only > look for some basic metrics obtained from SR/RR. But I agree with you > consistency between the metrics used by RTCP XR and RTCWEB is a good > thing. The work on "rtcweb-stats" is related to XRBLOCK in my opinon. At least the "basic metrics from SR/RR" with respect to packet loss are con= troversial and could be misleading, and should be replaced by correspondent= XR performance metric types. The deficiency of some of these basic metrics was one reason to start work = on extension reports (XR, and former HR). Albrecht ________________________________________ Von: xrblock-bounces@ietf.org [xrblock-bounces@ietf.org] im Auftrag von Rom= ascanu, Dan (Dan) [dromasca@avaya.com] Gesendet: Mittwoch, 26. September 2012 11:57 An: Qin Wu; xrblock@ietf.org Betreff: Re: [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-reg= istry-00.txt Hi Qin, If you subscribed to the rtcweb list it would be best that you forward directly your comments there - does this seem OK? Dan > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Wednesday, September 26, 2012 3:45 AM > To: Romascanu, Dan (Dan); xrblock@ietf.org > Subject: Re: [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats- > registry-00.txt > > Hi, Dan: > I am happy to see my comments being forwarded to rtcweb@ietf.org if they > are interested and want to more input from XRBLOCK WG. However I am not > sure how much of their work is related to XRBLOCK work? Do they only > look for some basic metrics obtained from SR/RR. But I agree with you > consistency between the metrics used by RTCP XR and RTCWEB is a good > thing. > It will be great to see metrics used by RTCP XR can be used in RTCWEB as > well. > > BTW: I have subscribed to rtcweb list and am interest to join the > discussion as I said and expected. > > Regards! > -Qin > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "Qin Wu" ; > Sent: Tuesday, September 25, 2012 5:45 PM > Subject: Re: [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats- > registry-00.txt > > > > Hi Qin, > > > > Would you like me to forward your comments to rtcweb@ietf.org? You can > > also subscribe to the list to follow the responses and participate in > > the discussions, but I should warn you that performance statistics are > a > > fraction of the many problems this very active WG have on their hands. > > > > Dan > > > > > > > >> -----Original Message----- > >> From: Qin Wu [mailto:bill.wu@huawei.com] > >> Sent: Tuesday, September 25, 2012 4:17 AM > >> To: Romascanu, Dan (Dan); xrblock@ietf.org > >> Subject: Re: [xrblock] FW: I-D Action:draft-alvestrand-rtcweb-stats- > >> registry-00.txt > >> > >> Interesting -00 draft. > >> Have a quick look at this draft, I have the folowing comments: > >> 1. Jitter should also refers to PDV draft since PDV draft provide > >> another two measurement methods with different measurement precision > >> which are different from "inter-arrival jitter" described in RFC3550. > >> In the early version of PDV draft, we also accomodate "inter-arrival > >> jitter" and support reporting inter-arrival jitter. However we remove > >> inter-arrival jitter from this draft based on WG review since inter- > >> arrival jitter use different measurement unit and has wider range. > >> 2.ReceivedPacketCount > >> Loss RLE report block can be used to report the packet received. It > is > >> more staightfoward to calculate ReceivedPacket Count based on Loss > > RLE > >> report block defined in RFC3611 rather than based on MIB information > >> defined in RFC2959. Also in some case, WebClient may not support > SNMP. > >> So I suggest to refer to section 4.1, RFC3611. > >> 3. RecevedOctetCount > >> Same as RecevedPacketCount. I think Loss RLE report block also can be > >> used to calculate RecevedOctetCount. > >> It is better to refer to section 4.1, RFC3611. > >> 4. Section 4.2 Transport variable > >> It is not clear how Transport variable is relate to Variables from > > basic > >> RTCP SR/RR defined in section 4.1, how transport vaiable is > > calculated, > >> e.g., what's the relationship between ReceivedPackets and > >> ReceivedPacketcount? Are they the same variable? > >> Is 4 transport variable defined in section 4.2 sufficient to measure > > the > >> performance of media stream? Why not refer to some variable defined > in > >> XRBLOCK WG? > >> > >> Regards! > >> -Qin > >> > >> ----- Original Message ----- > >> From: "Romascanu, Dan (Dan)" > >> To: > >> Sent: Monday, September 24, 2012 7:48 PM > >> Subject: [xrblock] FW: I-D Action:draft-alvestrand-rtcweb-stats- > >> registry-00.txt > >> > >> > >> >I believe that this I-D (individual submission targeting the RTCWEB > > WG) > >> > is of interest for some of the folks who participate in XRBLOCK. > >> > Reaching consistency between the metrics used by RTCP XR and RTCWEB > >> > (when relevant) seems to be desirable. > >> > > >> > Regards, > >> > > >> > Dan > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: i-d-announce-bounces@ietf.org > >> > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >> > internet-drafts@ietf.org > >> > Sent: Monday, September 24, 2012 12:17 PM > >> > To: i-d-announce@ietf.org > >> > Subject: I-D Action: draft-alvestrand-rtcweb-stats-registry-00.txt > >> > > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > >> > directories. > >> > > >> > > >> > Title : A Registry for WebRTC statistics identifiers > >> > Author(s) : Harald T. Alvestrand > >> > Filename : draft-alvestrand-rtcweb-stats-registry-00.txt > >> > Pages : 8 > >> > Date : 2012-09-24 > >> > > >> > Abstract: > >> > This memo describes a registration procedure for statistics > >> > identifiers used in the WebRTC Javascript API to access > > statistical > >> > information about a PeerConnection. > >> > > >> > It also gives some identifiers that will, when approved, form the > >> > initial content of this registry. > >> > > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-stats- > >> registry > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-alvestrand-rtcweb-stats-registry- > 00 > >> > > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > _______________________________________________ > >> > I-D-Announce mailing list > >> > I-D-Announce@ietf.org > >> > https://www.ietf.org/mailman/listinfo/i-d-announce > >> > Internet-Draft directories: http://www.ietf.org/shadow.html or > >> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > _______________________________________________ > >> > xrblock mailing list > >> > xrblock@ietf.org > >> > https://www.ietf.org/mailman/listinfo/xrblock > > _______________________________________________ > > xrblock mailing list > > xrblock@ietf.org > > https://www.ietf.org/mailman/listinfo/xrblock _______________________________________________ xrblock mailing list xrblock@ietf.org https://www.ietf.org/mailman/listinfo/xrblock From bill.wu@huawei.com Wed Sep 26 18:35:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0322321F8505; Wed, 26 Sep 2012 18:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 E+yb+6oqtRIQ; Wed, 26 Sep 2012 18:35:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 282CA21F84D4; Wed, 26 Sep 2012 18:35:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALB85487; Thu, 27 Sep 2012 01:35:01 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 02:34:08 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 09:34:59 +0800 Received: from w53375 (10.138.41.149) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 09:34:56 +0800 Message-ID: <18F180006DFC4D0DB407E0187BA53FED@china.huawei.com> From: Qin Wu To: "Schwarz, Albrecht (Albrecht)" , "Romascanu, Dan (Dan)" , References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com><20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Date: Thu, 27 Sep 2012 09:34:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 27 Sep 2012 01:22:57 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [xrblock] FW:I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 01:35:04 -0000 QWxicmVjaHQsIHlvdSBoYXZlIGEgZ29vZCBwb2ludC4gU28gdGhlIHF1ZXN0aW9uIHRvIHJ0Y3dl YiBpcyANCmZvciBydGN3ZWIgYXBwbGljYXRpb25zLCBhcmUgdGhlIGJhc2ljIG1ldHJpY3MgZm9y IHRyYW5zcG9ydCBpbXBhaXJtZW50cyBwcm92aWRlZCBpbiBSVENQIFNSIGFuZCBSUiBwYWNrZXRz IHN1ZmZpY2llbnQ/DQpXaGF0IGtpbmQgb2YgbWV0cmljcyBhcmUgYmFzaWNhbGx5IG5lZWRlZCBm b3IgUlRDV2ViIGFwcGxpY2F0aW9uPyBlLmcuLCBhcmUgdGhlIG1ldHJpY3MgbGlrZSBwYWNrZXQg bG9zcywgZGVsYXksIGppdHRlciBiYXNpYyBtZXRyaWNzIA0KZm9yIHJ0Y3dlYiBhcHBsaWNhdGlv bnM/IA0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIiA8YWxicmVjaHQuc2Nod2FyekBhbGNh dGVsLWx1Y2VudC5jb20+DQpUbzogIlJvbWFzY2FudSwgRGFuIChEYW4pIiA8ZHJvbWFzY2FAYXZh eWEuY29tPjsgIlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT47IDx4cmJsb2NrQGlldGYub3Jn Pg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI3LCAy MDEyIDc6MjAgQU0NClN1YmplY3Q6IEFXOiBbeHJibG9ja10gRlc6SS1EQWN0aW9uOmRyYWZ0LWFs dmVzdHJhbmQtcnRjd2ViLXN0YXRzLXJlZ2lzdHJ5LTAwLnR4dA0KDQoNCj4gSSBhbSBoYXBweSB0 byBzZWUgbXkgY29tbWVudHMgYmVpbmcgZm9yd2FyZGVkIHRvIHJ0Y3dlYkBpZXRmLm9yZyBpZg0K dGhleQ0KPiBhcmUgaW50ZXJlc3RlZCBhbmQgd2FudCB0byBtb3JlIGlucHV0IGZyb20gWFJCTE9D SyBXRy4gSG93ZXZlciBJIGFtDQpub3QNCj4gc3VyZSBob3cgbXVjaCBvZiB0aGVpciB3b3JrIGlz IHJlbGF0ZWQgdG8gWFJCTE9DSyB3b3JrPyBEbyB0aGV5IG9ubHkNCj4gbG9vayBmb3Igc29tZSBi YXNpYyBtZXRyaWNzIG9idGFpbmVkIGZyb20gU1IvUlIuIEJ1dCBJIGFncmVlIHdpdGggeW91DQo+ IGNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIG1ldHJpY3MgdXNlZCBieSBSVENQIFhSIGFuZCBSVENX RUIgaXMgYSBnb29kDQo+IHRoaW5nLg0KDQpUaGUgd29yayBvbiAicnRjd2ViLXN0YXRzIiBpcyBy ZWxhdGVkIHRvIFhSQkxPQ0sgaW4gbXkgb3Bpbm9uLg0KQXQgbGVhc3QgdGhlICJiYXNpYyBtZXRy aWNzIGZyb20gU1IvUlIiIHdpdGggcmVzcGVjdCB0byBwYWNrZXQgbG9zcyBhcmUgY29udHJvdmVy c2lhbCBhbmQgY291bGQgYmUgbWlzbGVhZGluZywgYW5kIHNob3VsZCBiZSByZXBsYWNlZCBieSBj b3JyZXNwb25kZW50IFhSIHBlcmZvcm1hbmNlIG1ldHJpYyB0eXBlcy4NClRoZSBkZWZpY2llbmN5 IG9mIHNvbWUgb2YgdGhlc2UgYmFzaWMgbWV0cmljcyB3YXMgb25lIHJlYXNvbiB0byBzdGFydCB3 b3JrIG9uIGV4dGVuc2lvbiByZXBvcnRzIChYUiwgYW5kIGZvcm1lciBIUikuDQoNCkFsYnJlY2h0 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClZvbjogeHJibG9j ay1ib3VuY2VzQGlldGYub3JnIFt4cmJsb2NrLWJvdW5jZXNAaWV0Zi5vcmddIGltIEF1ZnRyYWcg dm9uIFJvbWFzY2FudSwgRGFuIChEYW4pIFtkcm9tYXNjYUBhdmF5YS5jb21dDQpHZXNlbmRldDog TWl0dHdvY2gsIDI2LiBTZXB0ZW1iZXIgMjAxMiAxMTo1Nw0KQW46IFFpbiBXdTsgeHJibG9ja0Bp ZXRmLm9yZw0KQmV0cmVmZjogUmU6IFt4cmJsb2NrXSBGVzogICAgICBJLURBY3Rpb246ZHJhZnQt YWx2ZXN0cmFuZC1ydGN3ZWItc3RhdHMtcmVnaXN0cnktMDAudHh0DQoNCkhpIFFpbiwNCg0KSWYg eW91IHN1YnNjcmliZWQgdG8gdGhlIHJ0Y3dlYiBsaXN0IGl0IHdvdWxkIGJlIGJlc3QgdGhhdCB5 b3UgZm9yd2FyZA0KZGlyZWN0bHkgeW91ciBjb21tZW50cyB0aGVyZSAtIGRvZXMgdGhpcyBzZWVt IE9LPw0KDQpEYW4NCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDI2LCAyMDEyIDM6NDUgQU0NCj4gVG86IFJvbWFzY2FudSwgRGFuIChEYW4pOyB4 cmJsb2NrQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbeHJibG9ja10gRlc6IEktREFjdGlvbjpk cmFmdC1hbHZlc3RyYW5kLXJ0Y3dlYi1zdGF0cy0NCj4gcmVnaXN0cnktMDAudHh0DQo+DQo+IEhp LCBEYW46DQo+IEkgYW0gaGFwcHkgdG8gc2VlIG15IGNvbW1lbnRzIGJlaW5nIGZvcndhcmRlZCB0 byBydGN3ZWJAaWV0Zi5vcmcgaWYNCnRoZXkNCj4gYXJlIGludGVyZXN0ZWQgYW5kIHdhbnQgdG8g bW9yZSBpbnB1dCBmcm9tIFhSQkxPQ0sgV0cuIEhvd2V2ZXIgSSBhbQ0Kbm90DQo+IHN1cmUgaG93 IG11Y2ggb2YgdGhlaXIgd29yayBpcyByZWxhdGVkIHRvIFhSQkxPQ0sgd29yaz8gRG8gdGhleSBv bmx5DQo+IGxvb2sgZm9yIHNvbWUgYmFzaWMgbWV0cmljcyBvYnRhaW5lZCBmcm9tIFNSL1JSLiBC dXQgSSBhZ3JlZSB3aXRoIHlvdQ0KPiBjb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZSBtZXRyaWNzIHVz ZWQgYnkgUlRDUCBYUiBhbmQgUlRDV0VCIGlzIGEgZ29vZA0KPiB0aGluZy4NCj4gSXQgd2lsbCBi ZSBncmVhdCB0byBzZWUgbWV0cmljcyB1c2VkIGJ5IFJUQ1AgWFIgY2FuIGJlIHVzZWQgaW4gUlRD V0VCDQphcw0KPiB3ZWxsLg0KPg0KPiBCVFc6IEkgaGF2ZSBzdWJzY3JpYmVkIHRvIHJ0Y3dlYiBs aXN0IGFuZCBhbSBpbnRlcmVzdCB0byBqb2luIHRoZQ0KPiBkaXNjdXNzaW9uIGFzIEkgc2FpZCBh bmQgZXhwZWN0ZWQuDQo+DQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KPiBGcm9tOiAiUm9tYXNjYW51LCBEYW4gKERhbikiIDxkcm9tYXNjYUBhdmF5 YS5jb20+DQo+IFRvOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPjsgPHhyYmxvY2tAaWV0 Zi5vcmc+DQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxMiA1OjQ1IFBNDQo+IFN1 YmplY3Q6IFJlOiBbeHJibG9ja10gRlc6IEktREFjdGlvbjpkcmFmdC1hbHZlc3RyYW5kLXJ0Y3dl Yi1zdGF0cy0NCj4gcmVnaXN0cnktMDAudHh0DQo+DQo+DQo+ID4gSGkgUWluLA0KPiA+DQo+ID4g V291bGQgeW91IGxpa2UgbWUgdG8gZm9yd2FyZCB5b3VyIGNvbW1lbnRzIHRvIHJ0Y3dlYkBpZXRm Lm9yZz8gWW91DQpjYW4NCj4gPiBhbHNvIHN1YnNjcmliZSB0byB0aGUgbGlzdCB0byBmb2xsb3cg dGhlIHJlc3BvbnNlcyBhbmQgcGFydGljaXBhdGUNCmluDQo+ID4gdGhlIGRpc2N1c3Npb25zLCBi dXQgSSBzaG91bGQgd2FybiB5b3UgdGhhdCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzDQphcmUNCj4g YQ0KPiA+IGZyYWN0aW9uIG9mIHRoZSBtYW55IHByb2JsZW1zIHRoaXMgdmVyeSBhY3RpdmUgV0cg aGF2ZSBvbiB0aGVpcg0KaGFuZHMuDQo+ID4NCj4gPiBEYW4NCj4gPg0KPiA+DQo+ID4NCj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogUWluIFd1IFttYWlsdG86Ymls bC53dUBodWF3ZWkuY29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTIg NDoxNyBBTQ0KPiA+PiBUbzogUm9tYXNjYW51LCBEYW4gKERhbik7IHhyYmxvY2tAaWV0Zi5vcmcN Cj4gPj4gU3ViamVjdDogUmU6IFt4cmJsb2NrXSBGVzogSS1EDQpBY3Rpb246ZHJhZnQtYWx2ZXN0 cmFuZC1ydGN3ZWItc3RhdHMtDQo+ID4+IHJlZ2lzdHJ5LTAwLnR4dA0KPiA+Pg0KPiA+PiBJbnRl cmVzdGluZyAtMDAgZHJhZnQuDQo+ID4+IEhhdmUgYSBxdWljayBsb29rIGF0IHRoaXMgZHJhZnQs IEkgaGF2ZSB0aGUgZm9sb3dpbmcgY29tbWVudHM6DQo+ID4+IDEuIEppdHRlciBzaG91bGQgYWxz byByZWZlcnMgdG8gUERWIGRyYWZ0IHNpbmNlIFBEViBkcmFmdCBwcm92aWRlDQo+ID4+IGFub3Ro ZXIgdHdvIG1lYXN1cmVtZW50IG1ldGhvZHMgd2l0aCBkaWZmZXJlbnQgbWVhc3VyZW1lbnQNCnBy ZWNpc2lvbg0KPiA+PiB3aGljaCBhcmUgZGlmZmVyZW50IGZyb20gImludGVyLWFycml2YWwgaml0 dGVyIiBkZXNjcmliZWQgaW4NClJGQzM1NTAuDQo+ID4+IEluIHRoZSBlYXJseSB2ZXJzaW9uIG9m IFBEViBkcmFmdCwgd2UgYWxzbyBhY2NvbW9kYXRlDQoiaW50ZXItYXJyaXZhbA0KPiA+PiBqaXR0 ZXIiIGFuZCBzdXBwb3J0IHJlcG9ydGluZyBpbnRlci1hcnJpdmFsIGppdHRlci4gSG93ZXZlciB3 ZQ0KcmVtb3ZlDQo+ID4+IGludGVyLWFycml2YWwgaml0dGVyIGZyb20gdGhpcyBkcmFmdCBiYXNl ZCBvbiBXRyByZXZpZXcgc2luY2UNCmludGVyLQ0KPiA+PiBhcnJpdmFsIGppdHRlciB1c2UgZGlm ZmVyZW50IG1lYXN1cmVtZW50IHVuaXQgYW5kIGhhcyB3aWRlciByYW5nZS4NCj4gPj4gMi5SZWNl aXZlZFBhY2tldENvdW50DQo+ID4+IExvc3MgUkxFIHJlcG9ydCBibG9jayBjYW4gYmUgdXNlZCB0 byByZXBvcnQgdGhlIHBhY2tldCByZWNlaXZlZC4gSXQNCj4gaXMNCj4gPj4gbW9yZSBzdGFpZ2h0 Zm93YXJkIHRvIGNhbGN1bGF0ZSBSZWNlaXZlZFBhY2tldCBDb3VudCBiYXNlZCBvbiAgTG9zcw0K PiA+IFJMRQ0KPiA+PiByZXBvcnQgYmxvY2sgZGVmaW5lZCBpbiBSRkMzNjExIHJhdGhlciB0aGFu IGJhc2VkIG9uIE1JQg0KaW5mb3JtYXRpb24NCj4gPj4gZGVmaW5lZCBpbiBSRkMyOTU5LiBBbHNv IGluIHNvbWUgY2FzZSwgV2ViQ2xpZW50IG1heSBub3Qgc3VwcG9ydA0KPiBTTk1QLg0KPiA+PiBT byBJIHN1Z2dlc3QgdG8gcmVmZXIgdG8gc2VjdGlvbiA0LjEsIFJGQzM2MTEuDQo+ID4+IDMuIFJl Y2V2ZWRPY3RldENvdW50DQo+ID4+IFNhbWUgYXMgUmVjZXZlZFBhY2tldENvdW50LiBJIHRoaW5r IExvc3MgUkxFIHJlcG9ydCBibG9jayBhbHNvIGNhbg0KYmUNCj4gPj4gdXNlZCB0byBjYWxjdWxh dGUgUmVjZXZlZE9jdGV0Q291bnQuDQo+ID4+IEl0IGlzIGJldHRlciB0byByZWZlciB0byBzZWN0 aW9uIDQuMSwgUkZDMzYxMS4NCj4gPj4gNC4gU2VjdGlvbiA0LjIgVHJhbnNwb3J0IHZhcmlhYmxl DQo+ID4+IEl0IGlzIG5vdCBjbGVhciBob3cgVHJhbnNwb3J0IHZhcmlhYmxlIGlzIHJlbGF0ZSB0 byBWYXJpYWJsZXMgZnJvbQ0KPiA+IGJhc2ljDQo+ID4+IFJUQ1AgU1IvUlIgZGVmaW5lZCBpbiBz ZWN0aW9uIDQuMSwgaG93IHRyYW5zcG9ydCB2YWlhYmxlIGlzDQo+ID4gY2FsY3VsYXRlZCwNCj4g Pj4gZS5nLiwgd2hhdCdzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBSZWNlaXZlZFBhY2tldHMg YW5kDQo+ID4+IFJlY2VpdmVkUGFja2V0Y291bnQ/IEFyZSB0aGV5IHRoZSBzYW1lIHZhcmlhYmxl Pw0KPiA+PiBJcyA0IHRyYW5zcG9ydCB2YXJpYWJsZSBkZWZpbmVkIGluIHNlY3Rpb24gNC4yIHN1 ZmZpY2llbnQgdG8NCm1lYXN1cmUNCj4gPiB0aGUNCj4gPj4gcGVyZm9ybWFuY2Ugb2YgbWVkaWEg c3RyZWFtPyBXaHkgbm90IHJlZmVyIHRvIHNvbWUgdmFyaWFibGUgZGVmaW5lZA0KPiBpbg0KPiA+ PiBYUkJMT0NLIFdHPw0KPiA+Pg0KPiA+PiBSZWdhcmRzIQ0KPiA+PiAtUWluDQo+ID4+DQo+ID4+ ICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4+IEZyb206ICJSb21hc2NhbnUsIERh biAoRGFuKSIgPGRyb21hc2NhQGF2YXlhLmNvbT4NCj4gPj4gVG86IDx4cmJsb2NrQGlldGYub3Jn Pg0KPiA+PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNCwgMjAxMiA3OjQ4IFBNDQo+ID4+IFN1 YmplY3Q6IFt4cmJsb2NrXSBGVzogSS1EIEFjdGlvbjpkcmFmdC1hbHZlc3RyYW5kLXJ0Y3dlYi1z dGF0cy0NCj4gPj4gcmVnaXN0cnktMDAudHh0DQo+ID4+DQo+ID4+DQo+ID4+ID5JIGJlbGlldmUg dGhhdCB0aGlzIEktRCAoaW5kaXZpZHVhbCBzdWJtaXNzaW9uIHRhcmdldGluZyB0aGUNClJUQ1dF Qg0KPiA+IFdHKQ0KPiA+PiA+IGlzIG9mIGludGVyZXN0IGZvciBzb21lIG9mIHRoZSBmb2xrcyB3 aG8gcGFydGljaXBhdGUgaW4gWFJCTE9DSy4NCj4gPj4gPiBSZWFjaGluZyBjb25zaXN0ZW5jeSBi ZXR3ZWVuIHRoZSBtZXRyaWNzIHVzZWQgYnkgUlRDUCBYUiBhbmQNClJUQ1dFQg0KPiA+PiA+ICh3 aGVuIHJlbGV2YW50KSBzZWVtcyB0byBiZSBkZXNpcmFibGUuDQo+ID4+ID4NCj4gPj4gPiBSZWdh cmRzLA0KPiA+PiA+DQo+ID4+ID4gRGFuDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+IEZyb206IGktZC1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnDQo+ID4+ID4gW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+ID4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQo+ID4+ID4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTIgMTI6MTcgUE0NCj4gPj4g PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4+ID4gU3ViamVjdDogSS1EIEFjdGlvbjoN CmRyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLXN0YXRzLXJlZ2lzdHJ5LTAwLnR4dA0KPiA+PiA+DQo+ ID4+ID4NCj4gPj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZQ0KSW50ZXJuZXQtRHJhZnRzDQo+ID4+ID4gZGlyZWN0b3JpZXMuDQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+IFRpdGxlICAgICAgICAgICA6IEEgUmVnaXN0cnkgZm9yIFdlYlJUQyBzdGF0 aXN0aWNzIGlkZW50aWZpZXJzDQo+ID4+ID4gQXV0aG9yKHMpICAgICAgIDogSGFyYWxkIFQuIEFs dmVzdHJhbmQNCj4gPj4gPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1hbHZlc3RyYW5kLXJ0Y3dl Yi1zdGF0cy1yZWdpc3RyeS0wMC50eHQNCj4gPj4gPiBQYWdlcyAgICAgICAgICAgOiA4DQo+ID4+ ID4gRGF0ZSAgICAgICAgICAgIDogMjAxMi0wOS0yNA0KPiA+PiA+DQo+ID4+ID4gQWJzdHJhY3Q6 DQo+ID4+ID4gICBUaGlzIG1lbW8gZGVzY3JpYmVzIGEgcmVnaXN0cmF0aW9uIHByb2NlZHVyZSBm b3Igc3RhdGlzdGljcw0KPiA+PiA+ICAgaWRlbnRpZmllcnMgdXNlZCBpbiB0aGUgV2ViUlRDIEph dmFzY3JpcHQgQVBJIHRvIGFjY2Vzcw0KPiA+IHN0YXRpc3RpY2FsDQo+ID4+ID4gICBpbmZvcm1h dGlvbiBhYm91dCBhIFBlZXJDb25uZWN0aW9uLg0KPiA+PiA+DQo+ID4+ID4gICBJdCBhbHNvIGdp dmVzIHNvbWUgaWRlbnRpZmllcnMgdGhhdCB3aWxsLCB3aGVuIGFwcHJvdmVkLCBmb3JtDQp0aGUN Cj4gPj4gPiAgIGluaXRpYWwgY29udGVudCBvZiB0aGlzIHJlZ2lzdHJ5Lg0KPiA+PiA+DQo+ID4+ ID4NCj4gPj4gPg0KPiA+PiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KPiA+PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWFsdmVzdHJhbmQtcnRjd2ViLXN0YXRzLQ0KPiA+PiByZWdpc3RyeQ0KPiA+PiA+DQo+ID4+ ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4+ID4N Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLXN0YXRz LXJlZ2lzdHJ5LQ0KPiAwMA0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4+ID4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPiA+PiA+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+ID4+ID4gSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IN Cj4gPj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+PiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4g eHJibG9jayBtYWlsaW5nIGxpc3QNCj4gPj4gPiB4cmJsb2NrQGlldGYub3JnDQo+ID4+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby94cmJsb2NrDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB4cmJsb2NrIG1haWxp bmcgbGlzdA0KPiA+IHhyYmxvY2tAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3hyYmxvY2sNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp4cmJsb2NrIG1haWxpbmcgbGlzdA0KeHJibG9ja0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby94cmJsb2Nr From harald@alvestrand.no Fri Sep 28 04:31:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47E21F8622 for ; Fri, 28 Sep 2012 04:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 pR6m2rmcOR1T for ; Fri, 28 Sep 2012 04:31:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A67221F8617 for ; Fri, 28 Sep 2012 04:31:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00A4439E090 for ; Fri, 28 Sep 2012 13:31:53 +0200 (CEST) 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 b11UYPWxJ+We for ; Fri, 28 Sep 2012 13:31:51 +0200 (CEST) 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 33CC639E020 for ; Fri, 28 Sep 2012 13:31:51 +0200 (CEST) Message-ID: <50658AA6.5090200@alvestrand.no> Date: Fri, 28 Sep 2012 13:31:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com> <20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:31:55 -0000 On 09/27/2012 01:20 AM, Schwarz, Albrecht (Albrecht) wrote: >> I am happy to see my comments being forwarded to rtcweb@ietf.org if > they >> are interested and want to more input from XRBLOCK WG. However I am > not >> sure how much of their work is related to XRBLOCK work? Do they only >> look for some basic metrics obtained from SR/RR. But I agree with you >> consistency between the metrics used by RTCP XR and RTCWEB is a good >> thing. > The work on "rtcweb-stats" is related to XRBLOCK in my opinon. > At least the "basic metrics from SR/RR" with respect to packet loss are controversial and could be misleading, and should be replaced by correspondent XR performance metric types. > The deficiency of some of these basic metrics was one reason to start work on extension reports (XR, and former HR). Indeed. The reason I started the document with packet counts and packet loss from SR/RR was that I thought these would be uncontroversial and unambiguous; I'm seeking guidance from XR people on what other metrics are well known enough - and implemented widely enough - that it makes sense to include them. (For reference, the WebRTC codebase seems to decode block type 7 and no other block type....) From albrecht.schwarz@alcatel-lucent.com Fri Sep 28 16:51:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0921F859B for ; Fri, 28 Sep 2012 16:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.582 X-Spam-Level: X-Spam-Status: No, score=-9.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 W-mib18-TZnt for ; Fri, 28 Sep 2012 16:51:12 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id A64B221F8528 for ; Fri, 28 Sep 2012 16:51:12 -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 q8SNp8cE003916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 29 Sep 2012 01:51:08 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 29 Sep 2012 01:51:07 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Sat, 29 Sep 2012 01:51:05 +0200 Thread-Topic: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt Thread-Index: Ac2dbOmrUTaleRBfTnqIdAsRmTFuKQAZrUTA Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96218CF78F67@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com> <20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <50658AA6.5090200@alvestrand.no> In-Reply-To: <50658AA6.5090200@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, 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.13 Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 23:51:14 -0000 Harald, just to double check: > (For reference, the WebRTC codebase seems to decode block type 7 and no=20 other block type....) BT=3D7 would be the "VoIP Metrics Report Block" (RFC 3611). Whereas BT=3D6 would be the "Statistics Summary Report Block", related also= to some improved SR/BR metric. Regards, Albrecht -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Freitag, 28. September 2012 13:32 To: rtcweb@ietf.org Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats= -registry-00.txt On 09/27/2012 01:20 AM, Schwarz, Albrecht (Albrecht) wrote: >> I am happy to see my comments being forwarded to rtcweb@ietf.org if > they >> are interested and want to more input from XRBLOCK WG. However I am > not >> sure how much of their work is related to XRBLOCK work? Do they only >> look for some basic metrics obtained from SR/RR. But I agree with you >> consistency between the metrics used by RTCP XR and RTCWEB is a good >> thing. > The work on "rtcweb-stats" is related to XRBLOCK in my opinon. > At least the "basic metrics from SR/RR" with respect to packet loss are c= ontroversial and could be misleading, and should be replaced by corresponde= nt XR performance metric types. > The deficiency of some of these basic metrics was one reason to start wor= k on extension reports (XR, and former HR). Indeed. The reason I started the document with packet counts and packet=20 loss from SR/RR was that I thought these would be uncontroversial and=20 unambiguous; I'm seeking guidance from XR people on what other metrics=20 are well known enough - and implemented widely enough - that it makes=20 sense to include them. (For reference, the WebRTC codebase seems to decode block type 7 and no=20 other block type....) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bill.wu@huawei.com Fri Sep 28 20:40:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ADE21F8496; Fri, 28 Sep 2012 20:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.81 X-Spam-Level: X-Spam-Status: No, score=-4.81 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 nD7ZXO2atBAR; Fri, 28 Sep 2012 20:40:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4156B21F85C4; Fri, 28 Sep 2012 20:40:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKD04659; Sat, 29 Sep 2012 03:40:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 04:39:46 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 04:40:33 +0100 Received: from w53375 (10.138.41.149) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 11:40:28 +0800 Message-ID: From: Qin Wu To: Harald Alvestrand , References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com><20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <50658AA6.5090200@alvestrand.no> Date: Sat, 29 Sep 2012 11:40:26 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: xrblock@ietf.org Subject: Re: [rtcweb] [xrblock]FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 03:40:57 -0000 SGksSGFyYWxkOg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJIYXJhbGQg QWx2ZXN0cmFuZCIgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPg0KVG86IDxydGN3ZWJAaWV0Zi5vcmc+ DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyOCwgMjAxMiA3OjMxIFBNDQpTdWJqZWN0OiBSZTog W3J0Y3dlYl0gW3hyYmxvY2tdRlc6IEktREFjdGlvbjpkcmFmdC1hbHZlc3RyYW5kLXJ0Y3dlYi1z dGF0cy1yZWdpc3RyeS0wMC50eHQNCg0KDQo+IE9uIDA5LzI3LzIwMTIgMDE6MjAgQU0sIFNjaHdh cnosIEFsYnJlY2h0IChBbGJyZWNodCkgd3JvdGU6DQo+Pj4gSSBhbSBoYXBweSB0byBzZWUgbXkg Y29tbWVudHMgYmVpbmcgZm9yd2FyZGVkIHRvIHJ0Y3dlYkBpZXRmLm9yZyBpZg0KPj4gdGhleQ0K Pj4+IGFyZSBpbnRlcmVzdGVkIGFuZCB3YW50IHRvIG1vcmUgaW5wdXQgZnJvbSBYUkJMT0NLIFdH LiBIb3dldmVyIEkgYW0NCj4+IG5vdA0KPj4+IHN1cmUgaG93IG11Y2ggb2YgdGhlaXIgd29yayBp cyByZWxhdGVkIHRvIFhSQkxPQ0sgd29yaz8gRG8gdGhleSBvbmx5DQo+Pj4gbG9vayBmb3Igc29t ZSBiYXNpYyBtZXRyaWNzIG9idGFpbmVkIGZyb20gU1IvUlIuIEJ1dCBJIGFncmVlIHdpdGggeW91 DQo+Pj4gY29uc2lzdGVuY3kgYmV0d2VlbiB0aGUgbWV0cmljcyB1c2VkIGJ5IFJUQ1AgWFIgYW5k IFJUQ1dFQiBpcyBhIGdvb2QNCj4+PiB0aGluZy4NCj4+IFRoZSB3b3JrIG9uICJydGN3ZWItc3Rh dHMiIGlzIHJlbGF0ZWQgdG8gWFJCTE9DSyBpbiBteSBvcGlub24uDQo+PiBBdCBsZWFzdCB0aGUg ImJhc2ljIG1ldHJpY3MgZnJvbSBTUi9SUiIgd2l0aCByZXNwZWN0IHRvIHBhY2tldCBsb3NzIGFy ZSBjb250cm92ZXJzaWFsIGFuZCBjb3VsZCBiZSBtaXNsZWFkaW5nLCBhbmQgc2hvdWxkIGJlIHJl cGxhY2VkIGJ5IGNvcnJlc3BvbmRlbnQgWFIgcGVyZm9ybWFuY2UgbWV0cmljIHR5cGVzLg0KPj4g VGhlIGRlZmljaWVuY3kgb2Ygc29tZSBvZiB0aGVzZSBiYXNpYyBtZXRyaWNzIHdhcyBvbmUgcmVh c29uIHRvIHN0YXJ0IHdvcmsgb24gZXh0ZW5zaW9uIHJlcG9ydHMgKFhSLCBhbmQgZm9ybWVyIEhS KS4NCj4gSW5kZWVkLiBUaGUgcmVhc29uIEkgc3RhcnRlZCB0aGUgZG9jdW1lbnQgd2l0aCBwYWNr ZXQgY291bnRzIGFuZCBwYWNrZXQgDQo+IGxvc3MgZnJvbSBTUi9SUiB3YXMgdGhhdCBJIHRob3Vn aHQgdGhlc2Ugd291bGQgYmUgdW5jb250cm92ZXJzaWFsIGFuZCANCj4gdW5hbWJpZ3VvdXM7IEkn bSBzZWVraW5nIGd1aWRhbmNlIGZyb20gWFIgcGVvcGxlIG9uIHdoYXQgb3RoZXIgbWV0cmljcyAN Cj4gYXJlIHdlbGwga25vd24gZW5vdWdoIC0gYW5kIGltcGxlbWVudGVkIHdpZGVseSBlbm91Z2gg LSB0aGF0IGl0IG1ha2VzIA0KPiBzZW5zZSB0byBpbmNsdWRlIHRoZW0uDQo+IA0KPiAoRm9yIHJl ZmVyZW5jZSwgdGhlIFdlYlJUQyBjb2RlYmFzZSBzZWVtcyB0byBkZWNvZGUgYmxvY2sgdHlwZSA3 IGFuZCBubyANCj4gb3RoZXIgYmxvY2sgdHlwZS4uLi4pDQoNCltRaW5dOiBGb3Igaml0dGVyLCB5 b3UgbWF5IHJlZmVyIHRvIGJvdGggUkZDMzU1MCBzZWN0aW9uIDYuNC4xIGZvciBpbnRlci1hcnJp dmFsIGppdHRlciBhbmQNCmRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBkdiBmb3IgIjItcG9p bnQgUERWIiBhbmQgIkFic29sdXRlIFBhY2tldCBEZWxheSBWYXJpYXRpb24gMiAoTUFQRFYyKSAi Lg0KU2luY2Ugaml0dGVyIGlzIGFsc28ga25vd24gYXMgUGFja2V0IERlbGF5IFZhcmlhdGlvbi4N Cg0KRm9yIG90aGVyIG1ldHJpY3MsIEkgdGhpbmsgeW91IG1heSBhbHNvIGluY2x1ZGUgcm91bmQg dHJpcCBkZWxheSBtZXRyaWMgYnkgcmVmZXJyaW5nIHRvIGRyYWZ0LWlldGYtcnRjcC14ci1kZWxh eQ0KaW5jbHVkZSBkaXNjYXJkIG1ldHJpYyBieSByZWZlcnJpbmcgdG8gZHJhZnQtaWV0Zi1ydGNw LXhyLWRpc2NhcmQuDQoNCkZvciBtZWFzdXJlbWVudCB0aW1pbmcgZm9yIHRoZXNlIFhSIGJsb2Nr cywgeW91IHNob3VsZCByZWZlciB0byBkcmFmdC1pZXRmLXhyYmxvY2stbWVhcy1pZGVudGl0eS4N Cg0KSWYgeW91IGxvb2sgaW50byBlbmQgZGV2aWNlIHJlbGF0ZWQgbWV0cmljcywgeW91IG1heSBs b29rIGF0IGppdHRlciBidWZmZXIgbWV0cmljLA0KY29uY2VhbG1lbnQgc2Vjb25kcyBtZXRyaWNz LCBsb3NzIGNvbmNlYWxtZW50IG1ldHJpY3MgZGV2ZWxvcGVkIGluIFhSQkxPQ0sgV0csIA0KdGhl c2UgbWV0cmljcyBhbHNvIGFmZmVjdCByZWFsIHRpbWUgYXBwbGlhdGlvbiBxdWFsaXR5Lg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIg bWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg== From bill.wu@huawei.com Fri Sep 28 20:49:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F15521F8639 for ; Fri, 28 Sep 2012 20:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.811 X-Spam-Level: X-Spam-Status: No, score=-4.811 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 iHtYFEtqdvJl for ; Fri, 28 Sep 2012 20:49:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD91421F861D for ; Fri, 28 Sep 2012 20:49:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKD05001; Sat, 29 Sep 2012 03:49:41 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 04:46:01 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 04:46:59 +0100 Received: from w53375 (10.138.41.149) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 11:46:56 +0800 Message-ID: <5C3B831BB96542CB8C9488663D7CE373@china.huawei.com> From: Qin Wu To: "Schwarz, Albrecht (Albrecht)" , Harald Alvestrand , References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com><20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com><50658AA6.5090200@alvestrand.no> <5F7BCCF5541B7444830A2288ABBEBC96218CF78F67@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Date: Sat, 29 Sep 2012 11:46:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 03:49:44 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCkiIDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbT4NClRv OiAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz47IDxydGN3ZWJAaWV0 Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDI5LCAyMDEyIDc6NTEgQU0NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBbeHJibG9ja10gRlc6IEktREFjdGlvbjpkcmFmdC1hbHZlc3RyYW5k LXJ0Y3dlYi1zdGF0cy1yZWdpc3RyeS0wMC50eHQNCg0KDQo+IEhhcmFsZCwNCj4gDQo+IGp1c3Qg dG8gZG91YmxlIGNoZWNrOg0KPiANCj4+IChGb3IgcmVmZXJlbmNlLCB0aGUgV2ViUlRDIGNvZGVi YXNlIHNlZW1zIHRvIGRlY29kZSBibG9jayB0eXBlIDcgYW5kIG5vIA0KPiBvdGhlciBibG9jayB0 eXBlLi4uLikNCj4gDQo+IEJUPTcgd291bGQgYmUgdGhlICJWb0lQIE1ldHJpY3MgUmVwb3J0IEJs b2NrIiAoUkZDIDM2MTEpLg0KDQpbUWluXTogSWYgeW91IGxvb2sgZm9yIG1ldHJpY3Mgb25seSBm b3IgYXVkaW8gc3RyZWFtLCB5b3UgbWF5IGxvb2sgYXQgQlQgPTcsDQpIb3dldmVyIGlmIHlvdSBs b29rIGZvciBtZXRyaWNzIG5vdCBvbmx5IGZvciBhdWRpbyBzdHJlYW0gYnV0IGFsc28gZm9yIHZp ZGVvIHN0cmVhbSwNCnlvdSBtYXkgbG9vayBhdCBidXJzdCBnYXAgbG9zcyBtZXRyaWNzLCBidXJz dCBnYXAgZGlzY2FyZCBtZXRyaWNzLCBEZWxheSBtZXRyaWNzLA0KUW9TIG1ldHJpY3MsIEppdHRl ciBCdWZmZXIgbWV0cmljcyBkZXZlbG9wZWQgaW4gWFJCTE9DSyBXRyB3aGljaCBhcmUgDQpkZWNv bXBvc2VkIGZyb20gVk9JUCBtZXRyaWNzIFJlcG9ydCBibG9jayBidXQgbW9yZSBnZW5lcmljIG1l dHJpY3MgdGhhdCBjYW4gYmUgDQphcHBsaWVkIHRvIGJvdGggYXVkaW8gYW5kIHZpZGVvIHN0cmVh bS4NCg0KPiBXaGVyZWFzIEJUPTYgd291bGQgYmUgdGhlICJTdGF0aXN0aWNzIFN1bW1hcnkgUmVw b3J0IEJsb2NrIiwgcmVsYXRlZCBhbHNvIHRvIHNvbWUgaW1wcm92ZWQgU1IvQlIgbWV0cmljLg0K PiANCj4gUmVnYXJkcywNCj4gQWxicmVjaHQNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYXJhbGQgQWx2ZXN0cmFuZA0KPiBTZW50OiBGcmVp dGFnLCAyOC4gU2VwdGVtYmVyIDIwMTIgMTM6MzINCj4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3J0Y3dlYl0gW3hyYmxvY2tdIEZXOiBJLURBY3Rpb246ZHJhZnQtYWx2ZXN0 cmFuZC1ydGN3ZWItc3RhdHMtcmVnaXN0cnktMDAudHh0DQo+IA0KPiBPbiAwOS8yNy8yMDEyIDAx OjIwIEFNLCBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIHdyb3RlOg0KPj4+IEkgYW0gaGFw cHkgdG8gc2VlIG15IGNvbW1lbnRzIGJlaW5nIGZvcndhcmRlZCB0byBydGN3ZWJAaWV0Zi5vcmcg aWYNCj4+IHRoZXkNCj4+PiBhcmUgaW50ZXJlc3RlZCBhbmQgd2FudCB0byBtb3JlIGlucHV0IGZy b20gWFJCTE9DSyBXRy4gSG93ZXZlciBJIGFtDQo+PiBub3QNCj4+PiBzdXJlIGhvdyBtdWNoIG9m IHRoZWlyIHdvcmsgaXMgcmVsYXRlZCB0byBYUkJMT0NLIHdvcms/IERvIHRoZXkgb25seQ0KPj4+ IGxvb2sgZm9yIHNvbWUgYmFzaWMgbWV0cmljcyBvYnRhaW5lZCBmcm9tIFNSL1JSLiBCdXQgSSBh Z3JlZSB3aXRoIHlvdQ0KPj4+IGNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIG1ldHJpY3MgdXNlZCBi eSBSVENQIFhSIGFuZCBSVENXRUIgaXMgYSBnb29kDQo+Pj4gdGhpbmcuDQo+PiBUaGUgd29yayBv biAicnRjd2ViLXN0YXRzIiBpcyByZWxhdGVkIHRvIFhSQkxPQ0sgaW4gbXkgb3Bpbm9uLg0KPj4g QXQgbGVhc3QgdGhlICJiYXNpYyBtZXRyaWNzIGZyb20gU1IvUlIiIHdpdGggcmVzcGVjdCB0byBw YWNrZXQgbG9zcyBhcmUgY29udHJvdmVyc2lhbCBhbmQgY291bGQgYmUgbWlzbGVhZGluZywgYW5k IHNob3VsZCBiZSByZXBsYWNlZCBieSBjb3JyZXNwb25kZW50IFhSIHBlcmZvcm1hbmNlIG1ldHJp YyB0eXBlcy4NCj4+IFRoZSBkZWZpY2llbmN5IG9mIHNvbWUgb2YgdGhlc2UgYmFzaWMgbWV0cmlj cyB3YXMgb25lIHJlYXNvbiB0byBzdGFydCB3b3JrIG9uIGV4dGVuc2lvbiByZXBvcnRzIChYUiwg YW5kIGZvcm1lciBIUikuDQo+IEluZGVlZC4gVGhlIHJlYXNvbiBJIHN0YXJ0ZWQgdGhlIGRvY3Vt ZW50IHdpdGggcGFja2V0IGNvdW50cyBhbmQgcGFja2V0IA0KPiBsb3NzIGZyb20gU1IvUlIgd2Fz IHRoYXQgSSB0aG91Z2h0IHRoZXNlIHdvdWxkIGJlIHVuY29udHJvdmVyc2lhbCBhbmQgDQo+IHVu YW1iaWd1b3VzOyBJJ20gc2Vla2luZyBndWlkYW5jZSBmcm9tIFhSIHBlb3BsZSBvbiB3aGF0IG90 aGVyIG1ldHJpY3MgDQo+IGFyZSB3ZWxsIGtub3duIGVub3VnaCAtIGFuZCBpbXBsZW1lbnRlZCB3 aWRlbHkgZW5vdWdoIC0gdGhhdCBpdCBtYWtlcyANCj4gc2Vuc2UgdG8gaW5jbHVkZSB0aGVtLg0K PiANCj4gKEZvciByZWZlcmVuY2UsIHRoZSBXZWJSVEMgY29kZWJhc2Ugc2VlbXMgdG8gZGVjb2Rl IGJsb2NrIHR5cGUgNyBhbmQgbm8gDQo+IG90aGVyIGJsb2NrIHR5cGUuLi4uKQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1h aWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI= From harald@alvestrand.no Sat Sep 29 02:34:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476EC21F8666 for ; Sat, 29 Sep 2012 02:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6ERiIzdbjV9 for ; Sat, 29 Sep 2012 02:34:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 882E621F866A for ; Sat, 29 Sep 2012 02:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8C9239E0F3; Sat, 29 Sep 2012 11:34:10 +0200 (CEST) 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 SIw068R04nAr; Sat, 29 Sep 2012 11:34:10 +0200 (CEST) Received: from [192.168.11.107] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5342539E058; Sat, 29 Sep 2012 11:34:10 +0200 (CEST) Message-ID: <5066C091.8030202@alvestrand.no> Date: Sat, 29 Sep 2012 11:34:09 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <3C8D9E30D9654AD0A3E1F21668D1CBFB@china.huawei.com> <20E112E82D30472AA48E653041BC0A78@china.huawei.com>, <5F7BCCF5541B7444830A2288ABBEBC96218CFC7599@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <50658AA6.5090200@alvestrand.no> <5F7BCCF5541B7444830A2288ABBEBC96218CF78F67@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96218CF78F67@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [xrblock] FW: I-DAction:draft-alvestrand-rtcweb-stats-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 09:34:14 -0000 On 09/29/2012 01:51 AM, Schwarz, Albrecht (Albrecht) wrote: > Harald, > > just to double check: > >> (For reference, the WebRTC codebase seems to decode block type 7 and no > other block type....) > > BT=7 would be the "VoIP Metrics Report Block" (RFC 3611). > > Whereas BT=6 would be the "Statistics Summary Report Block", related also to some improved SR/BR metric. Yep. I looked in the source code and found code that special cased the number 7. (This is part of the open source WebRTC release). I guess this means there has been customer demand for the VoIP Metrics, but no customer demand for the Statistics Summary - which led to my query about which XR metrics are widely supported in others' equipment. Harald