From internet-drafts@ietf.org Sun Sep 1 10:02:10 2013 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 9858D21E8122; Sun, 1 Sep 2013 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceR5gi3pj0Np; Sun, 1 Sep 2013 10:02:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ABA21E8083; Sun, 1 Sep 2013 10:02:09 -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.70.p1 Message-ID: <20130901170208.13521.89759.idtracker@ietfa.amsl.com> Date: Sun, 01 Sep 2013 10:02:08 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-08.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: Sun, 01 Sep 2013 17:02:11 -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 : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-08.txt Pages : 40 Date : 2013-09-01 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Sun Sep 1 10:15:41 2013 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 0000921E80CD for ; Sun, 1 Sep 2013 10:15:39 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmthw8La53FY for ; Sun, 1 Sep 2013 10:15:32 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DD23311E8152 for ; Sun, 1 Sep 2013 10:15:31 -0700 (PDT) Received: from [81.187.2.149] (port=38126 helo=[192.168.0.14]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VGBFD-0002PQ-EV for rtcweb@ietf.org; Sun, 01 Sep 2013 18:15:30 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130901170208.13521.89759.idtracker@ietfa.amsl.com> Date: Sun, 1 Sep 2013 18:15:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A35B4AB-678E-4501-A353-D7AD6340C24F@csperkins.org> References: <20130901170208.13521.89759.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-08.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: Sun, 01 Sep 2013 17:15:42 -0000 The main changes in this version are to reorganise and rewrite Section = 12, and remove most of the Appendix, with the exception of sections A.5 = and A.6, which have been merged into Section 12. We've also tried to = address the comments made on the list recently.=20 Colin On 1 Sep 2013, at 18:02, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-08.txt > Pages : 40 > Date : 2013-09-01 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-08 ... --=20 Colin Perkins http://csperkins.org/ From cowwoc@bbs.darktech.org Sun Sep 1 12:44:39 2013 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 CEDB811E810F for ; Sun, 1 Sep 2013 12:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rvc7tV3JYZp for ; Sun, 1 Sep 2013 12:44:35 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 55CD111E80D9 for ; Sun, 1 Sep 2013 12:44:35 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so6706928iet.20 for ; Sun, 01 Sep 2013 12:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ymbqBmud5h3QDJvEfGDszXzDeE0UUAWnrPt0rvG3gcw=; b=MTi4QnBEvgHXRljZ4TV8Rik2cWZ0wRndE1WRV2Cs2o0MA1fa3oo98uWgbADo8HdSln xLJa2RFaQa0k4skCbsZPEluhIUZofWMlwKv3G6suMGKpeLmOqtAD18E6GSQ18I8qWaJT Nj6yVY6Nh1N6I+kkODX1kHGuclgDNmbkq7MXBFYfKXoBB6vGlxUO8M1D/mfV6lKYZIMT B0tZXXj+Hwzvk02YrnBwfJ3M6jXLhwlfNqNzKzdeGuZiUSBwHY3bcjRoZkLbNjI3KMPn PWOkpXuKdNvJjLXVLYbPX7joqHg0KDRgwe/eHeLz9Ghw8CxsakRMZbwFX8MY2ReZhuJM oT/Q== X-Gm-Message-State: ALoCoQnMHro/s1Uq1TJLMZmM4ooxFkDQ4SSNQcDjrLxybp4ucOQLNIeze6aezfxLfpY6swO6DBsP X-Received: by 10.43.143.133 with SMTP id jm5mr9417632icc.25.1378064673778; Sun, 01 Sep 2013 12:44:33 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id b16sm12590780igd.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 12:44:33 -0700 (PDT) Message-ID: <5223991F.1040508@bbs.darktech.org> Date: Sun, 01 Sep 2013 15:44:31 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Virnetx IPR 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, 01 Sep 2013 19:44:39 -0000 Hi, Is WebRTC affected by this? http://apple.slashdot.org/story/13/09/01/1233230/apple-now-relaying-all-facetime-calls-due-to-lost-patent-dispute and http://arstechnica.com/tech-policy/2010/08/virnetx-files-vpn-patent-suit-against-apple-cisco-nec/ Thanks, Gili From silviapfeiffer1@gmail.com Sun Sep 1 15:39:22 2013 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 0A98C11E82AC for ; Sun, 1 Sep 2013 15:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdA51ra2b2D2 for ; Sun, 1 Sep 2013 15:39:21 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4111E82A9 for ; Sun, 1 Sep 2013 15:39:21 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so4514413oag.36 for ; Sun, 01 Sep 2013 15:39:21 -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=5mtUfmuwjTt1mTHGhdjcvuZwlTR7B+Iv3g5TlyddnuA=; b=nisKwoWiem2KxNDZ2WEmN44sT2CVnCIwPCgNuPdctEcvVEr64DOI0O9awP45o9ROWV P70pC+aFSMy1VIi/NK1bHbkKLHSdEu0JwUbHUGF4VQSPbi3jNShBHCWkFybgqZPb4WP6 Vey9zACjQJ8GaoeIl4iYWQI0BYHTFer4q4lSLe8X1hGVAgMUvEcsApSKMGU2yfpKmK5c J3/gXe+5O7JW4skHnZMAOXDKhb0c3VQhQCzH1PxdUECGtWjWasyMGwOAnvP9mOhF2g0H YwrVUdPGTmby/oowrpwd2Tp4orDfW05FuTiF9FvJbmTnQCZ1M/5hP1yJUSTp7Lg3ONpz 8szA== X-Received: by 10.182.134.229 with SMTP id pn5mr14160517obb.88.1378075159979; Sun, 01 Sep 2013 15:39:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.144.194 with HTTP; Sun, 1 Sep 2013 15:38:59 -0700 (PDT) In-Reply-To: <5223991F.1040508@bbs.darktech.org> References: <5223991F.1040508@bbs.darktech.org> From: Silvia Pfeiffer Date: Mon, 2 Sep 2013 08:38:59 +1000 Message-ID: To: cowwoc Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Virnetx IPR 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, 01 Sep 2013 22:39:22 -0000 FAIK it's unrelated: WebRTC is not using a vpn to establish connections. But IANAL. :-) Silvia. On Mon, Sep 2, 2013 at 5:44 AM, cowwoc wrote: > Hi, > > Is WebRTC affected by this? > > http://apple.slashdot.org/story/13/09/01/1233230/apple-now-relaying-all-facetime-calls-due-to-lost-patent-dispute > and > http://arstechnica.com/tech-policy/2010/08/virnetx-files-vpn-patent-suit-against-apple-cisco-nec/ > > Thanks, > Gili > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Mon Sep 2 16:44:52 2013 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 51C1B21F9DF3 for ; Mon, 2 Sep 2013 16:44:52 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y28XnDXiO33l for ; Mon, 2 Sep 2013 16:44:48 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3577621F9DBA for ; Mon, 2 Sep 2013 16:44:39 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so9033358iej.36 for ; Mon, 02 Sep 2013 16:44:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Dd1weTDtSCQT4BxktF85bJQclPZptnf4Ryfazc7DWgI=; b=KpbPtqHI2bpCqk1EKMXFHbuRLJC/kBM2+DFt9WPNi3CrAdyWcPQ9rAbFuLJheRgWnv dab728TY1QhepKE2G4RIXwBBa4eOzhr+nWbA1dpW4MUaU1mPo7AmOJRI2TKVHo6yxsq3 rzzb76Q6eXkGxvteeHQJkRRnuDTiUZjDUydQGSgURSLqDR0mJ54FRpJ8nHbzg6+tR2Ye qwvuewVj1zfQ8u4znGnoZuqGEnfFjmzXL24vsX+Ai/WW7/1LZjVFhxqYkwO2nbZJr4+V DKRbjPavHl4Q2FZHz4RwoMuJ4by7bkQ+uwsYfGhmhJV89stxmFslzkZa+aHhgMXjzZJ8 +YWA== X-Gm-Message-State: ALoCoQnOl03DVPX/Ju/cnFa0yGUE+HUN1T5q9FYgWl8edaII/94hBkTi7KgxRlpm5qQm6aaFLulx X-Received: by 10.50.20.232 with SMTP id q8mr13969920ige.0.1378165478736; Mon, 02 Sep 2013 16:44:38 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm20756756igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 16:44:38 -0700 (PDT) Message-ID: <522522E2.70604@bbs.darktech.org> Date: Mon, 02 Sep 2013 19:44:34 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Silvia Pfeiffer References: <5223991F.1040508@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090102090504040902040108" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Virnetx IPR 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, 02 Sep 2013 23:44:52 -0000 This is a multi-part message in MIME format. --------------090102090504040902040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Silvia, Something doesn't make sense. It's my understanding that Facetime involves direct video chat connections (no VPN) and yet Apple was found to be infringing Virnetx patents. Quoting http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/: Both sides in the litigation admit that if Apple routes its FaceTime calls through relay servers, it will avoid infringing the VirnetX patents. Once Apple was found to be infringing---and realized it could end up paying an ongoing royalty for using FaceTime---*the company redesigned the system so that all FaceTime calls would rely on relay servers. Lease believes the switch happened in April*. This makes me believe the patent affect direct p2p connections. Gili On 01/09/2013 6:38 PM, Silvia Pfeiffer wrote: > FAIK it's unrelated: WebRTC is not using a vpn to establish > connections. But IANAL. :-) > Silvia. > > On Mon, Sep 2, 2013 at 5:44 AM, cowwoc wrote: >> Hi, >> >> Is WebRTC affected by this? >> >> http://apple.slashdot.org/story/13/09/01/1233230/apple-now-relaying-all-facetime-calls-due-to-lost-patent-dispute >> and >> http://arstechnica.com/tech-policy/2010/08/virnetx-files-vpn-patent-suit-against-apple-cisco-nec/ >> >> Thanks, >> Gili >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb --------------090102090504040902040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Silvia,

    Something doesn't make sense. It's my understanding that Facetime involves direct video chat connections (no VPN) and yet Apple was found to be infringing Virnetx patents.

    Quoting http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/:

Both sides in the litigation admit that if Apple routes its FaceTime calls through relay servers, it will avoid infringing the VirnetX patents. Once Apple was found to be infringing—and realized it could end up paying an ongoing royalty for using FaceTime—the company redesigned the system so that all FaceTime calls would rely on relay servers. Lease believes the switch happened in April.

    This makes me believe the patent affect direct p2p connections.

Gili

On 01/09/2013 6:38 PM, Silvia Pfeiffer wrote:
FAIK it's unrelated: WebRTC is not using a vpn to establish
connections. But IANAL. :-)
Silvia.

On Mon, Sep 2, 2013 at 5:44 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Hi,

    Is WebRTC affected by this?

http://apple.slashdot.org/story/13/09/01/1233230/apple-now-relaying-all-facetime-calls-due-to-lost-patent-dispute
and
http://arstechnica.com/tech-policy/2010/08/virnetx-files-vpn-patent-suit-against-apple-cisco-nec/

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

--------------090102090504040902040108-- From internet-drafts@ietf.org Tue Sep 3 02:40:45 2013 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 9CB6121E80E3; Tue, 3 Sep 2013 02:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VurKnE9OUrpi; Tue, 3 Sep 2013 02:40:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B816F21E80D3; Tue, 3 Sep 2013 02:40:44 -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.70.p1 Message-ID: <20130903094043.23789.32700.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2013 02:40:44 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-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: Tue, 03 Sep 2013 09:40:45 -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 : Transports for RTCWEB Author(s) : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-01.txt Pages : 8 Date : 2013-09-03 Abstract: This document describes the data transport protocols used by RTCWEB, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-transports-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Tue Sep 3 02:54:03 2013 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 4E2A921E80ED for ; Tue, 3 Sep 2013 02:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+HHLzCQEaOq for ; Tue, 3 Sep 2013 02:53:56 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C83EE21E80E7 for ; Tue, 3 Sep 2013 02:53:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87C1239E303 for ; Tue, 3 Sep 2013 11:53: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 tFd+fOEE50DJ for ; Tue, 3 Sep 2013 11:53:52 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 86C3239E078 for ; Tue, 3 Sep 2013 11:53:52 +0200 (CEST) Message-ID: <5225B1AF.7050906@alvestrand.no> Date: Tue, 03 Sep 2013 11:53:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> In-Reply-To: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000300030700070001090101" Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-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: Tue, 03 Sep 2013 09:54:03 -0000 This is a multi-part message in MIME format. --------------000300030700070001090101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Since I had so much good feedback on the previous version, I've created an update. There's still a couple of open questions, in particular around support of TURN/TLS (TLS for connecting from the client to the TURN server). I have also said nothing about HTTP proxies - after reading through that text in -firewall-, I concluded that we need a protocol specification to refer to before we can require clients to connect through HTTP proxies. The protocol specification MIGHT fit on one page - but then again, it might not. -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-transports-01.txt Date: Tue, 03 Sep 2013 02:40:45 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-ietf-rtcweb-transports-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-ietf-rtcweb-transports Revision: 01 Title: Transports for RTCWEB Creation date: 2013-09-03 Group: rtcweb Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports Htmlized: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-01 Abstract: This document describes the data transport protocols used by RTCWEB, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------000300030700070001090101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Since I had so much good feedback on the previous version, I've created an update.

There's still a couple of open questions, in particular around support of TURN/TLS (TLS for connecting from the client to the TURN server).

I have also said nothing about HTTP proxies - after reading through that text in -firewall-, I concluded that we need a protocol specification to refer to before we can require clients to connect through HTTP proxies.

The protocol specification MIGHT fit on one page - but then again, it might not.


-------- Original Message --------
Subject: New Version Notification for draft-ietf-rtcweb-transports-01.txt
Date: Tue, 03 Sep 2013 02:40:45 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-ietf-rtcweb-transports-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-ietf-rtcweb-transports
Revision:	 01
Title:		 Transports for RTCWEB
Creation date:	 2013-09-03
Group:		 rtcweb
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports
Htmlized:        http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-01

Abstract:
   This document describes the data transport protocols used by RTCWEB,
   including the protocols used for interaction with intermediate boxes
   such as firewalls, relays and NAT boxes.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------000300030700070001090101-- From harald@alvestrand.no Tue Sep 3 05:21:12 2013 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 A53AE21E811C for ; Tue, 3 Sep 2013 05:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tHu8XZFWr-R for ; Tue, 3 Sep 2013 05:21:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 03CF921E811A for ; Tue, 3 Sep 2013 05:21:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E15F39E360 for ; Tue, 3 Sep 2013 14:21:07 +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 3Zi0U8QC-707 for ; Tue, 3 Sep 2013 14:21:06 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 57F1939E078 for ; Tue, 3 Sep 2013 14:21:06 +0200 (CEST) Message-ID: <5225D431.6010503@alvestrand.no> Date: Tue, 03 Sep 2013 14:21:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 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] References to ICE in -overview 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, 03 Sep 2013 12:21:13 -0000 Sorry for not replying to this earlier; I'm preparing the new version of -overview now. On 08/15/2013 07:04 PM, Martin Thomson wrote: > I just noticed that the only concrete RFC 5245 reference in -overview > is in the appendicies. The term "ICE agent" is defined by not used in > the main body of the text. ICE is never expanded on first use. I expanded the reference in the terminology section. The main purpose of that definition was to get people conscious that when they use the term "Agent", they need to qualify what kind of agent it is. I also deleted the ICE reference in section 4 (Data transport), since the -transports- draft goes into much more detail about ICE than the -overview- draft should. > > Should there be a more explicit reference to ICE in Section 7? I don't think section 7 is the right place for it; section 7 is where we say "we don't want to do SIP, but we require the need to do what SIP is able to do". (Unless my numbering's gone haywire). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Tue Sep 3 05:50:39 2013 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 5593B21E8133; Tue, 3 Sep 2013 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v4hzprXzBF8; Tue, 3 Sep 2013 05:50:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C851C21E8128; Tue, 3 Sep 2013 05:50:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130903125038.27454.83599.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2013 05:50:38 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-08.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: Tue, 03 Sep 2013 12:50:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Overview: Real Time Protocols for Brower-based Applicati= ons Author(s) : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-08.txt Pages : 20 Date : 2013-09-03 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.thomson@gmail.com Tue Sep 3 10:26:33 2013 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 BA10921F9A2E for ; Tue, 3 Sep 2013 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHeSs-b7njUz for ; Tue, 3 Sep 2013 10:26:33 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D53F321E8168 for ; Tue, 3 Sep 2013 10:26:01 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so2004807wes.28 for ; Tue, 03 Sep 2013 10:26: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=JsVbizXGTUYkEJHDlRBKPxKo/fxlDWZ9slrWXBkOB4s=; b=kIrc6tA1RPJFiJ9Tl7J/2VcUCZZVLxbMOmOTQ1LwhmJJGTmiou7M9dH2TjQttMMiPa hxw4LkS17kxuX+KYmap6JUncGOCD2YK2d8RBgs4bSBv/lXdjfVhHRoqr6pZdSjQU+mF+ EmOmD4gTTqg5+Af9kMH6l/3K0MwPEGABxDeq2sZWKNvUmb2ynomc14IqIv9gRFukVuLZ QDE63E2sPZ6yt7qGN57V1NvMoNXwWYVCVjB31PBcFllBQ6FXHK5Ne0pUQGRfvkKgg6lN 1xtWHQ3hzUhiM9KGojE2QGulM+yizUk0UlowcakV0sVbwdvqKtaIyF21eo4FomNTR/8b dQug== MIME-Version: 1.0 X-Received: by 10.180.188.132 with SMTP id ga4mr18079729wic.10.1378229160813; Tue, 03 Sep 2013 10:26:00 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Tue, 3 Sep 2013 10:26:00 -0700 (PDT) In-Reply-To: <5225D431.6010503@alvestrand.no> References: <5225D431.6010503@alvestrand.no> Date: Tue, 3 Sep 2013 10:26:00 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] References to ICE in -overview 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, 03 Sep 2013 17:26:34 -0000 On 3 September 2013 05:21, Harald Alvestrand wrote: > I also deleted the ICE reference in section 4 (Data transport), since the > -transports- draft goes into much more detail about ICE than the -overview- > draft should. Makes sense. I made the comment before -transports- draft was published. From fluffy@cisco.com Wed Sep 4 09:23:48 2013 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 BAA9F21F9FD0 for ; Wed, 4 Sep 2013 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZFF28-jmbVc for ; Wed, 4 Sep 2013 09:23: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 1A48621E80F1 for ; Wed, 4 Sep 2013 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=209; q=dns/txt; s=iport; t=1378311823; x=1379521423; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=clf9BcBihVXvr29gLMKjqmbe0qV2Kt/L2sl5gzRUlUk=; b=dVRPIJWr9sjF5n3bLXTLVmsy8oGJq0ytcoFy44TsnGAboyUgoWnaWbqt UEZU9H+Zw2Wa/F0MeDg03u1UmAia0ZUfJwlfL2sDI3GEAEFM17iNfQCOm cuBmhGWEnATBpGTdJ7vVp8oYtHrAY1x4O/4AoJd8iHxspZyvag8rPpOZh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAEdeJ1KtJV2Y/2dsb2JhbABagweBBsE8gScWdIImAQR5EgEqVicEDg2Herl9jy8xgySBAAOpW4Mggio X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255570100" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2013 16:23:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r84GNgiU024002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 16:23:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 11:23:42 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: AQHOqYsejEiO9JuZoEu3yxpSVyhr2A== Date: Wed, 4 Sep 2013 16:23:41 +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.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 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, 04 Sep 2013 16:23:48 -0000 We would like to start a working group last call of draft-ietf-rtcweb-use-c= ases-and-requirements-11. Please send comments by the end of the day on September 21.=20 Thank you,=20 The chairs =85. From mzanaty@cisco.com Wed Sep 4 13:03:13 2013 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 7128521E80F5 for ; Wed, 4 Sep 2013 13:03:13 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLOTSXk-v01P for ; Wed, 4 Sep 2013 13:03:08 -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 6B85E21E80EE for ; Wed, 4 Sep 2013 13:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3584; q=dns/txt; s=iport; t=1378324988; x=1379534588; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aoyN33N1Ma1AaVwwICoFWJKpIvcoHyPL0+Ly9H/GS8s=; b=Slp1Gy16Ld7MdiUWUjwSjl4XiFyZG4tMQnSrLCvx2/+aY0EWOcizr43b 65y0GncQNigEZgRE7cRcJrRz61UYZWI00O8E4G9KWoyBvSwZFMVYn2CEz nl90bo3aI6H4cpos6j7FOL3UExPVyl5nllzNm7arEsnmEjW617uKptX94 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFANeQJ1KtJV2d/2dsb2JhbABagwc1SwbBRIEoFnSCJAEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIAYd5BwW6No4ngQgzBQaDF4EAA5QbhQmLC4UsgyCBcTk X-IronPort-AV: E=Sophos;i="4.89,1023,1367971200"; d="scan'208";a="252640875" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2013 20:03:08 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r84K373v006945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 20:03:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 15:03:07 -0500 From: "Mo Zanaty (mzanaty)" To: Bo Burman , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgA6MUZA= Date: Wed, 4 Sep 2013 20:03:06 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 04 Sep 2013 20:03:13 -0000 I support the proposed text addition. But rather than adding at the end of = section 3, replace the beginning of section 3 as below. OLD: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. While this section specifies the codecs that will be mandated for all WebRTC client implementations, it leaves the question of supporting additional codecs to the will of the implementer. NEW: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. If other suitable audio codecs are available to the browser to use,=20 it is RECOMMENDED that they are also included in the offer in order=20 to maximize the possibility to establish the session without the need=20 for audio transcoding. Mo -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bo Burman Sent: Tuesday, August 27, 2013 10:53 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Based on the previous discussion thread http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg08501.html, I believe there is support to add some text= into this document. I thus propose to add the following text at the end of section 3: If other suitable audio codecs are available to the browser to use,=20 it is RECOMMENDED that they are also included in the offer in order=20 to maximize the possibility to establish the session without the need=20 for audio transcoding Cheers, Bo > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: den 2 augusti 2013 18:30 > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browsers= Working Group of the IETF. >=20 > Title : WebRTC Audio Codec and Processing Requirements > Author(s) : Jean-Marc Valin > Cary Bran > Filename : draft-ietf-rtcweb-audio-02.txt > Pages : 6 > Date : 2013-08-02 >=20 > Abstract: > This document outlines the audio codec and processing requirements > for WebRTC client application and endpoint devices. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Thu Sep 5 01:45:51 2013 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 F06C911E8120 for ; Thu, 5 Sep 2013 01:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK0TzUnHk-87 for ; Thu, 5 Sep 2013 01:45:41 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9754D11E80E2 for ; Thu, 5 Sep 2013 01:45:38 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-12-522844b1a33f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E3.14.25272.1B448225; Thu, 5 Sep 2013 10:45:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Thu, 5 Sep 2013 10:45:37 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "Cullen Jennings (fluffy)" Thread-Topic: WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: AQHOqYsejEiO9JuZoEu3yxpSVyhr2A== Date: Thu, 5 Sep 2013 08:45:36 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3848D2@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje5GF40ggxtr9C06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZbR8ms5UMJ21YsLTlewNjPNYuhg5OSQETCTW z1jNCmGLSVy4t56ti5GLQ0jgKKPE2f5nTBDOYkaJc00nmbsYOTjYBIIlmv66gTSICBhKNO2Z B1bDLLCCUWLehclgk4QFXCQm3H7HDFHkKrGhazYbhK0nsfDAa7A4i4CKxI63r8HqeQV8Jebu 6AKzhQR8JA79ngtWzwh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf1AfKEq0P21g hKg3kHh/bj4zhK0tsWwhxF5eAUGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSNHcWpxUm66 kcEmRmA0HNzy22IH4+W/NocYpTlYlMR5t+idCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA GDaHd3nB2ogtKu8yG5Y8flKhMfnqdsfJCtvZLy99WT+x3zMrzqGtKOFWe9bBx2YSSUrrks4+ +XVzkZKRkO2mXPGQfwf3p/w88+L05g+qFpzRljP/7Lzekhc8OTjYe/3cLj8lprn5znm3HX+d FNizoYlZlO+n6cKIxVPenvRpVN4uuP33xmeuFkosxRmJhlrMRcWJADt1dVdUAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 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, 05 Sep 2013 08:45:51 -0000 On 2013-09-04 18:23, Cullen Jennings (fluffy) wrote:=0A= >=0A= > We would like to start a working group last call of draft-ietf-rtcweb-use= -cases-and-requirements-11.=0A= >=0A= > Please send comments by the end of the day on September 21.=0A= =0A= In the current version (-11) we've not addressed Andrew Hutton's input =0A= on handling the case with a FW that only allows traffic via a HTTP Proxy = =0A= [1].=0A= =0A= This should be fixed for the next version.=0A= =0A= [11] http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html=0A= =0A= >=0A= > Thank you,=0A= >=0A= > The chairs =85.=0A= >=0A= >=0A= >=0A= >=0A= >=0A= =0A= From uwe.rauschenbach@nsn.com Thu Sep 5 03:14:16 2013 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 62C2B21F9BF3 for ; Thu, 5 Sep 2013 03:14:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97q-uWNXX4xv for ; Thu, 5 Sep 2013 03:14:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E011E8184 for ; Thu, 5 Sep 2013 03:14:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r85AE1Wp013211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Sep 2013 12:14:01 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r85AE1BP015291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 12:14:01 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.18]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Thu, 5 Sep 2013 12:14:00 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Mo Zanaty (mzanaty)" , Bo Burman , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgA6MUZCAAPL7QA== Date: Thu, 5 Sep 2013 10:14:00 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4215 X-purgate-ID: 151667::1378376041-00003561-922EC8FC/0-0/0-0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 05 Sep 2013 10:14:16 -0000 I support this proposal. Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of ext Mo Zanaty (mzanaty) > Sent: Wednesday, September 04, 2013 10:03 PM > To: Bo Burman; rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > I support the proposed text addition. But rather than adding at the end > of section 3, replace the beginning of section 3 as below. >=20 > OLD: > To ensure a baseline level of interoperability between WebRTC > clients, a minimum set of required codecs are specified below. > While this section specifies the codecs that will be mandated for > all > WebRTC client implementations, it leaves the question of supporting > additional codecs to the will of the implementer. >=20 > NEW: > To ensure a baseline level of interoperability between WebRTC > clients, a minimum set of required codecs are specified below. > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the > need > for audio transcoding. >=20 > Mo >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bo Burman > Sent: Tuesday, August 27, 2013 10:53 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > Based on the previous discussion thread http://www.ietf.org/mail- > archive/web/rtcweb/current/msg08501.html, I believe there is support to > add some text into this document. >=20 > I thus propose to add the following text at the end of section 3: >=20 > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the need > for audio transcoding >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: den 2 augusti 2013 18:30 > > To: i-d-announce@ietf.org > > Cc: rtcweb@ietf.org > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Real-Time Communication in WEB- > browsers Working Group of the IETF. > > > > Title : WebRTC Audio Codec and Processing Requirements > > Author(s) : Jean-Marc Valin > > Cary Bran > > Filename : draft-ietf-rtcweb-audio-02.txt > > Pages : 6 > > Date : 2013-08-02 > > > > 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-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are > > available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 internet-drafts@ietf.org Thu Sep 5 03:16:45 2013 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 9E2AE11E8192; Thu, 5 Sep 2013 03:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPAfzAWmY9UT; Thu, 5 Sep 2013 03:16:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BB711E8183; Thu, 5 Sep 2013 03:16:10 -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.70.p1 Message-ID: <20130905101609.549.22302.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 03:16:09 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-09.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, 05 Sep 2013 10:16:48 -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 : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-09.txt Pages : 40 Date : 2013-09-05 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Thu Sep 5 03:18:19 2013 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 4A7D421F93B9 for ; Thu, 5 Sep 2013 03:18:19 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVYSaidcsvBS for ; Thu, 5 Sep 2013 03:18:14 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id A474D21F9C06 for ; Thu, 5 Sep 2013 03:18:14 -0700 (PDT) Received: from [130.209.247.112] (port=64566 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VHWdb-0001XI-4Z for rtcweb@ietf.org; Thu, 05 Sep 2013 11:18:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130905101609.549.22302.idtracker@ietfa.amsl.com> Date: Thu, 5 Sep 2013 11:18:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8764F238-189E-4073-AA25-158633EE33BB@csperkins.org> References: <20130905101609.549.22302.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-09.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, 05 Sep 2013 10:18:19 -0000 This just updates the references, since a few drafts have been published = as RFCs recently. No other content changes. Colin On 5 Sep 2013, at 11:16, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-09.txt > Pages : 40 > Date : 2013-09-05 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From bo.burman@ericsson.com Thu Sep 5 06:06:22 2013 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 7A45521E80BD for ; Thu, 5 Sep 2013 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1Uz96GjLXWW for ; Thu, 5 Sep 2013 06:06:14 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADE21F0CE0 for ; Thu, 5 Sep 2013 06:05:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-82-522881abad3a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.84.22048.BA188225; Thu, 5 Sep 2013 15:05:47 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.148]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 5 Sep 2013 15:05:47 +0200 From: Bo Burman To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "ext Mo Zanaty (mzanaty)" , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgA6MUZCAAPL7QIAAL59Q Date: Thu, 5 Sep 2013 13:05:46 +0000 Message-ID: References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje7qRo0gg4frTC1ePJjDZLH2Xzu7 xd3Dc5gdmD2m/N7I6rFkyU8mj5/rr7IHMEdx2aSk5mSWpRbp2yVwZVz+zlPwUqVi+ub7jA2M PbJdjJwcEgImEkevnGWCsMUkLtxbz9bFyMUhJHCYUWLtw2fsIAkhgcWMEmt+JIDYbAIaEvN3 3GUEKRIRmMUo0XrpMytIQljAXOJM00ogmwMoYSGxeWoySFhEwE3i2bxHjCA2i4CKxPcHS8CW 8Qr4Srw/vpoRYlkPk8SUG7PAEpwCfhLfTkwBa2AUkJW4//0eC4jNLCAucevJfKhLBSSW7DnP DGGLSrx8/I8VwlaUuDp9ORNEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJ yywkLQsYWVYxsucmZuakl5tvYgTGx8Etvw12MG66L3aIUZqDRUmcd7PemUAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjAfOf/kQbSN+unp/wGtjseVdZm9OnOxeWb702526k00r1hbNC/Vo eLE9p8jHfHHr9qX7Zpa5nNjgbWdbmiK5ZF53sfOVffO36TtWSQZt3MUjdeyGgvQml69uYQFM fdm9runLQtpVal7/e+94sTjv44JbPvc315X41toVzDkrmihy9CCP4tbCPCWW4oxEQy3mouJE AMJ5IZpdAgAA Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 05 Sep 2013 13:06:23 -0000 I also support it. /Bo > -----Original Message----- > From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.co= m] > Sent: den 5 september 2013 12:14 > To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > I support this proposal. >=20 > Kind regards, > Uwe >=20 >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of ext Mo Zanaty (mzanaty) > > Sent: Wednesday, September 04, 2013 10:03 PM > > To: Bo Burman; rtcweb@ietf.org > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > I support the proposed text addition. But rather than adding at the > > end of section 3, replace the beginning of section 3 as below. > > > > OLD: > > To ensure a baseline level of interoperability between WebRTC > > clients, a minimum set of required codecs are specified below. > > While this section specifies the codecs that will be mandated for > > all > > WebRTC client implementations, it leaves the question of supporting > > additional codecs to the will of the implementer. > > > > NEW: > > To ensure a baseline level of interoperability between WebRTC > > clients, a minimum set of required codecs are specified below. > > If other suitable audio codecs are available to the browser to use, > > it is RECOMMENDED that they are also included in the offer in order > > to maximize the possibility to establish the session without the > > need > > for audio transcoding. > > > > Mo > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Bo Burman > > Sent: Tuesday, August 27, 2013 10:53 AM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > Based on the previous discussion thread http://www.ietf.org/mail- > > archive/web/rtcweb/current/msg08501.html, I believe there is support > > to add some text into this document. > > > > I thus propose to add the following text at the end of section 3: > > > > If other suitable audio codecs are available to the browser to use, it > > is RECOMMENDED that they are also included in the offer in order to > > maximize the possibility to establish the session without the need for > > audio transcoding > > > > Cheers, > > Bo > > > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > > Sent: den 2 augusti 2013 18:30 > > > To: i-d-announce@ietf.org > > > Cc: rtcweb@ietf.org > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Real-Time Communication in WEB- > > browsers Working Group of the IETF. > > > > > > Title : WebRTC Audio Codec and Processing Requirements > > > Author(s) : Jean-Marc Valin > > > Cary Bran > > > Filename : draft-ietf-rtcweb-audio-02.txt > > > Pages : 6 > > > Date : 2013-08-02 > > > > > > 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-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are > > > available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 lgeyser@gmail.com Thu Sep 5 07:06:07 2013 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 684E111E81A1 for ; Thu, 5 Sep 2013 07:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypgz03QlY4Wn for ; Thu, 5 Sep 2013 07:06:06 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D4F4921F93F3 for ; Thu, 5 Sep 2013 07:06:05 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so1610463lab.11 for ; Thu, 05 Sep 2013 07:06:04 -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=7BKZJYo0YpvxdSj0OXkFffipr6BMjNmvj/c2CG0iSUo=; b=wll5t1DCUqNlP4rVGTeOvv2F1ya3QzEOGMAVxGdgM2DWvH3rHmUISSgYCJ6KXx3WSu RssjCm/wENRw4jahfXqhrLeoDd73eHMEGX9OFd72nAZWkXTQBQ4n7Y2xAUAuScTbCzk5 ejuW6yd7qeid1Xp6YjayZuF5Yh7M0gHeWgrtdnljumRrVYH5Fs87P6+X2VqY+5WzSwLB dlv8udz7PgownaN1ELJamukbErU+dcGXkydCbIIfgAHxtVwGKLJeBps91dEhbBhdqGeU TPBZ2oIz5i1PmqSn/e/S9baEyzzTsXCBvm/GgZ8vsErL7s7W9MPMIEgdcT7FQHlhhAmE eOcQ== MIME-Version: 1.0 X-Received: by 10.112.157.164 with SMTP id wn4mr110301lbb.51.1378389964653; Thu, 05 Sep 2013 07:06:04 -0700 (PDT) Received: by 10.114.0.239 with HTTP; Thu, 5 Sep 2013 07:06:04 -0700 (PDT) In-Reply-To: References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> Date: Thu, 5 Sep 2013 16:06:04 +0200 Message-ID: From: Leon Geyser To: Bo Burman Content-Type: multipart/alternative; boundary=001a11c34374348a5804e5a36ca8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 05 Sep 2013 14:06:07 -0000 --001a11c34374348a5804e5a36ca8 Content-Type: text/plain; charset=ISO-8859-1 It would be nice if a word like mandated/mandatory is present in the new text like it was in the old text. Maybe REQUIRED in uppercase? On 5 September 2013 15:05, Bo Burman wrote: > I also support it. > /Bo > > > -----Original Message----- > > From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto: > uwe.rauschenbach@nsn.com] > > Sent: den 5 september 2013 12:14 > > To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > > Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > I support this proposal. > > > > Kind regards, > > Uwe > > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of ext Mo Zanaty (mzanaty) > > > Sent: Wednesday, September 04, 2013 10:03 PM > > > To: Bo Burman; rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > I support the proposed text addition. But rather than adding at the > > > end of section 3, replace the beginning of section 3 as below. > > > > > > OLD: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > While this section specifies the codecs that will be mandated for > > > all > > > WebRTC client implementations, it leaves the question of supporting > > > additional codecs to the will of the implementer. > > > > > > NEW: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > If other suitable audio codecs are available to the browser to use, > > > it is RECOMMENDED that they are also included in the offer in order > > > to maximize the possibility to establish the session without the > > > need > > > for audio transcoding. > > > > > > Mo > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Bo Burman > > > Sent: Tuesday, August 27, 2013 10:53 AM > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > Based on the previous discussion thread http://www.ietf.org/mail- > > > archive/web/rtcweb/current/msg08501.html, I believe there is support > > > to add some text into this document. > > > > > > I thus propose to add the following text at the end of section 3: > > > > > > If other suitable audio codecs are available to the browser to use, it > > > is RECOMMENDED that they are also included in the offer in order to > > > maximize the possibility to establish the session without the need for > > > audio transcoding > > > > > > Cheers, > > > Bo > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > > > Sent: den 2 augusti 2013 18:30 > > > > To: i-d-announce@ietf.org > > > > Cc: rtcweb@ietf.org > > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Real-Time Communication in WEB- > > > browsers Working Group of the IETF. > > > > > > > > Title : WebRTC Audio Codec and Processing Requirements > > > > Author(s) : Jean-Marc Valin > > > > Cary Bran > > > > Filename : draft-ietf-rtcweb-audio-02.txt > > > > Pages : 6 > > > > Date : 2013-08-02 > > > > > > > > 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-02 > > > > > > > > A diff from the previous version is available at: > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are > > > > available at tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > > > 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 > --001a11c34374348a5804e5a36ca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would be nice if a word like mandated/mandatory is pres= ent in the new text like it was in the old text. Maybe REQUIRED in uppercas= e?


O= n 5 September 2013 15:05, Bo Burman <bo.burman@ericsson.com> wrote:
I also support it.
/Bo

> -----Original Message-----
> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]
> Sent: den 5 september 2013 12:14
> To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org
> Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt
>
> I support this proposal.
>
> Kind regards,
> Uwe
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of ext Mo Zanaty (mzanaty)
> > Sent: Wednesday, September 04, 2013 10:03 PM
> > To: Bo Burman; rtcweb@ietf.org=
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > I support the proposed text addition. But rather than adding at t= he
> > end of section 3, replace the beginning of section 3 as below. > >
> > OLD:
> > =A0 =A0To ensure a baseline level of interoperability between Web= RTC
> > =A0 =A0clients, a minimum set of required codecs are specified be= low.
> > =A0 =A0While this section specifies the codecs that will be manda= ted for
> > all
> > =A0 =A0WebRTC client implementations, it leaves the question of s= upporting
> > =A0 =A0additional codecs to the will of the implementer.
> >
> > NEW:
> > =A0 =A0To ensure a baseline level of interoperability between Web= RTC
> > =A0 =A0clients, a minimum set of required codecs are specified be= low.
> > =A0 =A0If other suitable audio codecs are available to the browse= r to use,
> > =A0 =A0it is RECOMMENDED that they are also included in the offer= in order
> > =A0 =A0to maximize the possibility to establish the session witho= ut the
> > need
> > =A0 =A0for audio transcoding.
> >
> > Mo
> >
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of Bo Burman
> > Sent: Tuesday, August 27, 2013 10:53 AM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > Based on the previous discussion thread http://www.ietf.org/mail-
> > archive/web/rtcweb/current/msg08501.html, I believe there is supp= ort
> > to add some text into this document.
> >
> > I thus propose to add the following text at the end of section 3:=
> >
> > If other suitable audio codecs are available to the browser to us= e, it
> > is RECOMMENDED that they are also included in the offer in order = to
> > maximize the possibility to establish the session without the nee= d for
> > audio transcoding
> >
> > Cheers,
> > Bo
> >
> > > -----Original Message-----
> > > From: i-d-a= nnounce-bounces@ietf.org [mailto:i-d-a= nnounce-
> > bounces@ietf.org] On Beha= lf Of internet-drafts@ietf.org<= /a>
> > > Sent: den 2 augusti 2013 18:30
> > > To: i-d-announce@ie= tf.org
> > > Cc: rtcweb@ietf.org > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-= Drafts
> > directories.
> > > =A0This draft is a work item of the Real-Time Communication = in WEB-
> > browsers Working Group of the IETF.
> > >
> > > =A0 Title =A0 =A0 =A0 =A0 =A0 : WebRTC Audio Codec and Proce= ssing Requirements
> > > =A0 Author(s) =A0 =A0 =A0 : Jean-Marc Valin
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cary Bra= n
> > > =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-rtcweb-audio-02.txt=
> > > =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6
> > > =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-02
> > >
> > > Abstract:
> > > =A0 =A0This document outlines the audio codec and processing= requirements
> > > =A0 =A0for WebRTC client application and endpoint devices. > > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-rtcw= eb-audio
> > >
> > > There's also a htmlized version available at:
> > > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-= 02
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-rtcweb-audio-02
> > >
> > >
> > > Please note that it may take a couple of minutes from the ti= me of
> > submission until the htmlized version and diff are
> > > available at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce@ietf.o= rg
> > > 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
> > _______________________________________________
> > 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

--001a11c34374348a5804e5a36ca8-- From harald@alvestrand.no Thu Sep 5 07:17:55 2013 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 972D311E81A4 for ; Thu, 5 Sep 2013 07:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nds9XVPwZCZt for ; Thu, 5 Sep 2013 07:17:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB1621F9D8B for ; Thu, 5 Sep 2013 07:17:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E927939E194 for ; Thu, 5 Sep 2013 16:17:47 +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 H-4pj9Ogx+K4 for ; Thu, 5 Sep 2013 16:17:46 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 083F739E128 for ; Thu, 5 Sep 2013 16:17:45 +0200 (CEST) Message-ID: <52289289.7040608@alvestrand.no> Date: Thu, 05 Sep 2013 16:17:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040106030501040602060902" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 05 Sep 2013 14:17:55 -0000 This is a multi-part message in MIME format. --------------040106030501040602060902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/05/2013 04:06 PM, Leon Geyser wrote: > It would be nice if a word like mandated/mandatory is present in the > new text like it was in the old text. Maybe REQUIRED in uppercase? REQUIRED is an RFC 2119 reserved word, and means the same thing as MUST. I would strenously object to REQUIRED. RECOMMENDED is also an RFC 2119 reserved word, and means the same thing as SHOULD. I have misgivings about giving such a strongly worded recommendation, but I can live with it. > > > On 5 September 2013 15:05, Bo Burman > wrote: > > I also support it. > /Bo > > > -----Original Message----- > > From: Rauschenbach, Uwe (NSN - DE/Munich) > [mailto:uwe.rauschenbach@nsn.com ] > > Sent: den 5 september 2013 12:14 > > To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > > > Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > I support this proposal. > > > > Kind regards, > > Uwe > > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] On > > > Behalf Of ext Mo Zanaty (mzanaty) > > > Sent: Wednesday, September 04, 2013 10:03 PM > > > To: Bo Burman; rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > I support the proposed text addition. But rather than adding > at the > > > end of section 3, replace the beginning of section 3 as below. > > > > > > OLD: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > While this section specifies the codecs that will be > mandated for > > > all > > > WebRTC client implementations, it leaves the question of > supporting > > > additional codecs to the will of the implementer. > > > > > > NEW: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > If other suitable audio codecs are available to the browser > to use, > > > it is RECOMMENDED that they are also included in the offer > in order > > > to maximize the possibility to establish the session > without the > > > need > > > for audio transcoding. > > > > > > Mo > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] On > > > Behalf Of Bo Burman > > > Sent: Tuesday, August 27, 2013 10:53 AM > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > Based on the previous discussion thread http://www.ietf.org/mail- > > > archive/web/rtcweb/current/msg08501.html, I believe there is > support > > > to add some text into this document. > > > > > > I thus propose to add the following text at the end of section 3: > > > > > > If other suitable audio codecs are available to the browser to > use, it > > > is RECOMMENDED that they are also included in the offer in > order to > > > maximize the possibility to establish the session without the > need for > > > audio transcoding > > > > > > Cheers, > > > Bo > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce- > > > > bounces@ietf.org ] On Behalf Of > internet-drafts@ietf.org > > > > Sent: den 2 augusti 2013 18:30 > > > > To: i-d-announce@ietf.org > > > > Cc: rtcweb@ietf.org > > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > This draft is a work item of the Real-Time Communication in > WEB- > > > browsers Working Group of the IETF. > > > > > > > > Title : WebRTC Audio Codec and Processing > Requirements > > > > Author(s) : Jean-Marc Valin > > > > Cary Bran > > > > Filename : draft-ietf-rtcweb-audio-02.txt > > > > Pages : 6 > > > > Date : 2013-08-02 > > > > > > > > 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-02 > > > > > > > > A diff from the previous version is available at: > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02 > > > > > > > > > > > > Please note that it may take a couple of minutes from the > time of > > > submission until the htmlized version and diff are > > > > available at tools.ietf.org . > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040106030501040602060902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/05/2013 04:06 PM, Leon Geyser wrote:
It would be nice if a word like mandated/mandatory is present in the new text like it was in the old text. Maybe REQUIRED in uppercase?

REQUIRED is an RFC 2119 reserved word, and means the same thing as MUST.
I would strenously object to REQUIRED.

RECOMMENDED is also an RFC 2119 reserved word, and means the same thing as SHOULD.
I have misgivings about giving such a strongly worded recommendation, but I can live with it.




On 5 September 2013 15:05, Bo Burman <bo.burman@ericsson.com> wrote:
I also support it.
/Bo

> -----Original Message-----
> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]
> Sent: den 5 september 2013 12:14
> To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org
> Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt
>
> I support this proposal.
>
> Kind regards,
> Uwe
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of ext Mo Zanaty (mzanaty)
> > Sent: Wednesday, September 04, 2013 10:03 PM
> > To: Bo Burman; rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt
> >
> > I support the proposed text addition. But rather than adding at the
> > end of section 3, replace the beginning of section 3 as below.
> >
> > OLD:
> >    To ensure a baseline level of interoperability between WebRTC
> >    clients, a minimum set of required codecs are specified below.
> >    While this section specifies the codecs that will be mandated for
> > all
> >    WebRTC client implementations, it leaves the question of supporting
> >    additional codecs to the will of the implementer.
> >
> > NEW:
> >    To ensure a baseline level of interoperability between WebRTC
> >    clients, a minimum set of required codecs are specified below.
> >    If other suitable audio codecs are available to the browser to use,
> >    it is RECOMMENDED that they are also included in the offer in order
> >    to maximize the possibility to establish the session without the
> > need
> >    for audio transcoding.
> >
> > Mo
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Bo Burman
> > Sent: Tuesday, August 27, 2013 10:53 AM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt
> >
> > Based on the previous discussion thread http://www.ietf.org/mail-
> > archive/web/rtcweb/current/msg08501.html, I believe there is support
> > to add some text into this document.
> >
> > I thus propose to add the following text at the end of section 3:
> >
> > If other suitable audio codecs are available to the browser to use, it
> > is RECOMMENDED that they are also included in the offer in order to
> > maximize the possibility to establish the session without the need for
> > audio transcoding
> >
> > Cheers,
> > Bo
> >
> > > -----Original Message-----
> > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-
> > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> > > Sent: den 2 augusti 2013 18:30
> > > To: i-d-announce@ietf.org
> > > Cc: rtcweb@ietf.org
> > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > >  This draft is a work item of the Real-Time Communication in WEB-
> > browsers Working Group of the IETF.
> > >
> > >   Title           : WebRTC Audio Codec and Processing Requirements
> > >   Author(s)       : Jean-Marc Valin
> > >                           Cary Bran
> > >   Filename        : draft-ietf-rtcweb-audio-02.txt
> > >   Pages           : 6
> > >   Date            : 2013-08-02
> > >
> > > 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-02
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are
> > > available at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > 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



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

--------------040106030501040602060902-- From mzanaty@cisco.com Thu Sep 5 07:41:59 2013 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 1EF0211E80EC for ; Thu, 5 Sep 2013 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmnlYPCupGJb for ; Thu, 5 Sep 2013 07:41:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C360511E81B2 for ; Thu, 5 Sep 2013 07:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22856; q=dns/txt; s=iport; t=1378392109; x=1379601709; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9e47XMbheQ5yix/6IuPgMwwP/IlCEubf2Lo6LjR3i8E=; b=HN7AjGjb2eMlbdDSiWcM2yhDdmJT9xNRR5l29PjZSSyBre+ez6v3umUG 2TTd+pgMn9kNq/RNa3dzZ0p7Re1O/2eSddbDQPkaaFmDKdsvNnQXePtjC 8rKLPs6A9kuBmVLH2tuCGysV5BGDEWj7C2yRB70pqhVTDw6ih+6QReJN1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFACSXKFKtJV2Y/2dsb2JhbABbgkNENUsGuQ2IPIEnFnSCJAEBAQQBAQEkBkELDAQCAQgOAwQBAQsdByEGCxQJCAIEAQ0FCAGHZwMPBwWxKw2IbIx0gTOBCC0EBgEGA4MUgQADlBuBcYMYiwgDhSyDIIFxOQ X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208,217";a="255976881" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 05 Sep 2013 14:41:48 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85EfmJI027832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 14:41:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 09:41:48 -0500 From: "Mo Zanaty (mzanaty)" To: Leon Geyser , Bo Burman Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOqkEXCTCNRbUxykmV6tr8IYwOK5m3NXTQ Date: Thu, 5 Sep 2013 14:41:47 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.189] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D5265C8xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 05 Sep 2013 14:41:59 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D5265C8xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you mean for the required codecs, that is already in the next sentence. = Full context: OLD: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. While this section specifies the codecs that will be mandated for all WebRTC client implementations, it leaves the question of supporting additional codecs to the will of the implementer. WebRTC clients are REQUIRED to implement the following audio codecs. NEW: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. If other suitable audio codecs are available to the browser to use, it is RECOMMENDED that they are also included in the offer in order to maximize the possibility to establish the session without the need for audio transcoding. WebRTC clients are REQUIRED to implement the following audio codecs. From: Leon Geyser [mailto:lgeyser@gmail.com] Sent: Thursday, September 05, 2013 10:06 AM To: Bo Burman Cc: Rauschenbach, Uwe (NSN - DE/Munich); Mo Zanaty (mzanaty); rtcweb@ietf.o= rg Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt It would be nice if a word like mandated/mandatory is present in the new te= xt like it was in the old text. Maybe REQUIRED in uppercase? On 5 September 2013 15:05, Bo Burman > wrote: I also support it. /Bo > -----Original Message----- > From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.co= m] > Sent: den 5 september 2013 12:14 > To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt > > I support this proposal. > > Kind regards, > Uwe > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:r= tcweb-bounces@ietf.org] On > > Behalf Of ext Mo Zanaty (mzanaty) > > Sent: Wednesday, September 04, 2013 10:03 PM > > To: Bo Burman; rtcweb@ietf.org > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > I support the proposed text addition. But rather than adding at the > > end of section 3, replace the beginning of section 3 as below. > > > > OLD: > > To ensure a baseline level of interoperability between WebRTC > > clients, a minimum set of required codecs are specified below. > > While this section specifies the codecs that will be mandated for > > all > > WebRTC client implementations, it leaves the question of supporting > > additional codecs to the will of the implementer. > > > > NEW: > > To ensure a baseline level of interoperability between WebRTC > > clients, a minimum set of required codecs are specified below. > > If other suitable audio codecs are available to the browser to use, > > it is RECOMMENDED that they are also included in the offer in order > > to maximize the possibility to establish the session without the > > need > > for audio transcoding. > > > > Mo > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:r= tcweb-bounces@ietf.org] On > > Behalf Of Bo Burman > > Sent: Tuesday, August 27, 2013 10:53 AM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > Based on the previous discussion thread http://www.ietf.org/mail- > > archive/web/rtcweb/current/msg08501.html, I believe there is support > > to add some text into this document. > > > > I thus propose to add the following text at the end of section 3: > > > > If other suitable audio codecs are available to the browser to use, it > > is RECOMMENDED that they are also included in the offer in order to > > maximize the possibility to establish the session without the need for > > audio transcoding > > > > Cheers, > > Bo > > > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] On Behalf Of internet-drafts= @ietf.org > > > Sent: den 2 augusti 2013 18:30 > > > To: i-d-announce@ietf.org > > > Cc: rtcweb@ietf.org > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Real-Time Communication in WEB- > > browsers Working Group of the IETF. > > > > > > Title : WebRTC Audio Codec and Processing Requirements > > > Author(s) : Jean-Marc Valin > > > Cary Bran > > > Filename : draft-ietf-rtcweb-audio-02.txt > > > Pages : 6 > > > Date : 2013-08-02 > > > > > > 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-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are > > > available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D5265C8xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you mean for the required codecs, th= at is already in the next sentence. Full context:

 

OLD:

 

To ensure a baseline level of interoper= ability between WebRTC

clients, a minimum set of required code= cs are specified below.

While this section specifies the codecs= that will be mandated for all

WebRTC client implementations, it leave= s the question of supporting

additional codecs to the will of the im= plementer.

 

WebRTC clients are REQUIRED to implemen= t the following audio codecs.

 

NEW:

 

To ensure a baseline level of interoper= ability between WebRTC

clients, a minimum set of required code= cs are specified below.

If other suitable audio codecs are avai= lable to the browser to use,

it is RECOMMENDED that they are also in= cluded in the offer in order

to maximize the possibility to establis= h the session without the need

for audio transcoding.

 

WebRTC clients are REQUIRED to implemen= t the following audio codecs.

 

 

From: Leon Gey= ser [mailto:lgeyser@gmail.com]
Sent: Thursday, September 05, 2013 10:06 AM
To: Bo Burman
Cc: Rauschenbach, Uwe (NSN - DE/Munich); Mo Zanaty (mzanaty); rtcweb= @ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

 

It would be nice if a word like mandated/mandatory i= s present in the new text like it was in the old text. Maybe REQUIRED in up= percase?

 

On 5 September 2013 15:05, Bo Burman <bo.burman@ericsson.com= > wrote:

I also support it.
/Bo=


> -----Original Message-----
> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]
> Sent: den 5 september 2013 12:14
> To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org
> Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt
>
> I support this proposal.
>
> Kind regards,
> Uwe
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of ext Mo Zanaty (mzanaty)
> > Sent: Wednesday, September 04, 2013 10:03 PM
> > To: Bo Burman; rtcweb@ietf.org=
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > I support the proposed text addition. But rather than adding at t= he
> > end of section 3, replace the beginning of section 3 as below. > >
> > OLD:
> >    To ensure a baseline level of interoperability betwe= en WebRTC
> >    clients, a minimum set of required codecs are specif= ied below.
> >    While this section specifies the codecs that will be= mandated for
> > all
> >    WebRTC client implementations, it leaves the questio= n of supporting
> >    additional codecs to the will of the implementer. > >
> > NEW:
> >    To ensure a baseline level of interoperability betwe= en WebRTC
> >    clients, a minimum set of required codecs are specif= ied below.
> >    If other suitable audio codecs are available to the = browser to use,
> >    it is RECOMMENDED that they are also included in the= offer in order
> >    to maximize the possibility to establish the session= without the
> > need
> >    for audio transcoding.
> >
> > Mo
> >
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of Bo Burman
> > Sent: Tuesday, August 27, 2013 10:53 AM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > Based on the previous discussion thread http://www.ietf.org/mail-
> > archive/web/rtcweb/current/msg08501.html, I believe there is supp= ort
> > to add some text into this document.
> >
> > I thus propose to add the following text at the end of section 3:=
> >
> > If other suitable audio codecs are available to the browser to us= e, it
> > is RECOMMENDED that they are also included in the offer in order = to
> > maximize the possibility to establish the session without the nee= d for
> > audio transcoding
> >
> > Cheers,
> > Bo
> >
> > > -----Original Message-----
> > > From: i-d-a= nnounce-bounces@ietf.org [mailto:i-d-a= nnounce-
> > bounces@ietf.org] On Beha= lf Of internet-drafts@ietf.org
> > > Sent: den 2 augusti 2013 18:30
> > > To: i-d-announce@ie= tf.org
> > > Cc: rtcweb@ietf.org > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-= Drafts
> > directories.
> > >  This draft is a work item of the Real-Time Communicati= on in WEB-
> > browsers Working Group of the IETF.
> > >
> > >   Title           : WebRTC Aud= io Codec and Processing Requirements
> > >   Author(s)       : Jean-Marc Valin
> > >                 &nbs= p;         Cary Bran
> > >   Filename        : draft-ietf-rtcw= eb-audio-02.txt
> > >   Pages           : 6
> > >   Date            : 2013-= 08-02
> > >
> > > Abstract:
> > >    This document outlines the audio codec and proc= essing requirements
> > >    for WebRTC client application and endpoint devi= ces.
> > >
> > >
> > > 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-02
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02
> > >
> > >
> > > Please note that it may take a couple of minutes from the ti= me of
> > submission until the htmlized version and diff are
> > > available at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce@ietf.o= rg
> > > 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
> > _______________________________________________
> > 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

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D5265C8xmbrcdx14ciscoc_-- From lijing80@huawei.com Thu Sep 5 21:06:10 2013 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 2FCAC11E8256 for ; Thu, 5 Sep 2013 21:06:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p8b+3-a3+7E for ; Thu, 5 Sep 2013 21:06:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 929CB11E824C for ; Thu, 5 Sep 2013 21:06:02 -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 AVC33291; Fri, 06 Sep 2013 04:05:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 05:05:37 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 05:05:57 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.175]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Fri, 6 Sep 2013 12:05:53 +0800 From: "Lijing (Jessie, Huawei)" To: "Mo Zanaty (mzanaty)" , Bo Burman , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgA6MUZCAAhrMgA== Date: Fri, 6 Sep 2013 04:05:52 +0000 Message-ID: References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 04:06:10 -0000 +1 I also support this proposal. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Mo Zanaty (mzanaty) Sent: Thursday, September 05, 2013 4:03 AM To: Bo Burman; rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt I support the proposed text addition. But rather than adding at the end of = section 3, replace the beginning of section 3 as below. OLD: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. While this section specifies the codecs that will be mandated for all WebRTC client implementations, it leaves the question of supporting additional codecs to the will of the implementer. NEW: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. If other suitable audio codecs are available to the browser to use,=20 it is RECOMMENDED that they are also included in the offer in order=20 to maximize the possibility to establish the session without the need=20 for audio transcoding. Mo -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bo Burman Sent: Tuesday, August 27, 2013 10:53 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Based on the previous discussion thread http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg08501.html, I believe there is support to add some text= into this document. I thus propose to add the following text at the end of section 3: If other suitable audio codecs are available to the browser to use,=20 it is RECOMMENDED that they are also included in the offer in order=20 to maximize the possibility to establish the session without the need=20 for audio transcoding Cheers, Bo > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: den 2 augusti 2013 18:30 > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browsers= Working Group of the IETF. >=20 > Title : WebRTC Audio Codec and Processing Requirements > Author(s) : Jean-Marc Valin > Cary Bran > Filename : draft-ietf-rtcweb-audio-02.txt > Pages : 6 > Date : 2013-08-02 >=20 > Abstract: > This document outlines the audio codec and processing requirements > for WebRTC client application and endpoint devices. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 andrew.hutton@siemens-enterprise.com Fri Sep 6 09:59:24 2013 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 0747511E80E0 for ; Fri, 6 Sep 2013 09:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKNWQ2QdXyeP for ; Fri, 6 Sep 2013 09:59:18 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id BEC1B21E80C2 for ; Fri, 6 Sep 2013 09:59:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CE0251EB8514; Fri, 6 Sep 2013 18:59:08 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Fri, 6 Sep 2013 18:59:08 +0200 From: "Hutton, Andrew" To: "Lijing (Jessie, Huawei)" , "Mo Zanaty (mzanaty)" , Bo Burman , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgA6MUZCAAhrMgIAA2u1Q Date: Fri, 6 Sep 2013 16:59:08 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BAEA15@MCHP04MSX.global-ad.net> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 16:59:24 -0000 There was a discussion on this back in January and I then I thought we had = converged on the following text which made a lower case type recommendation= : "If other suitable audio codecs are available to the browser to use it is r= ecommended that they are also included in the offer in order to maximize th= e possibility to establish the session without the need for audio transcodi= ng" See http://www.ietf.org/mail-archive/web/rtcweb/current/msg06121.html Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Lijing (Jessie, Huawei) > Sent: 06 September 2013 05:06 > To: Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > +1 >=20 > I also support this proposal. >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Mo Zanaty (mzanaty) > Sent: Thursday, September 05, 2013 4:03 AM > To: Bo Burman; rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > I support the proposed text addition. But rather than adding at the end > of section 3, replace the beginning of section 3 as below. >=20 > OLD: > To ensure a baseline level of interoperability between WebRTC > clients, a minimum set of required codecs are specified below. > While this section specifies the codecs that will be mandated for > all > WebRTC client implementations, it leaves the question of supporting > additional codecs to the will of the implementer. >=20 > NEW: > To ensure a baseline level of interoperability between WebRTC > clients, a minimum set of required codecs are specified below. > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the > need > for audio transcoding. >=20 > Mo >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bo Burman > Sent: Tuesday, August 27, 2013 10:53 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 > Based on the previous discussion thread http://www.ietf.org/mail- > archive/web/rtcweb/current/msg08501.html, I believe there is support to > add some text into this document. >=20 > I thus propose to add the following text at the end of section 3: >=20 > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the need > for audio transcoding >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: den 2 augusti 2013 18:30 > > To: i-d-announce@ietf.org > > Cc: rtcweb@ietf.org > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Real-Time Communication in WEB- > browsers Working Group of the IETF. > > > > Title : WebRTC Audio Codec and Processing Requirements > > Author(s) : Jean-Marc Valin > > Cary Bran > > Filename : draft-ietf-rtcweb-audio-02.txt > > Pages : 6 > > Date : 2013-08-02 > > > > 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-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are > > available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 jmvalin@mozilla.com Fri Sep 6 11:49:44 2013 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 4F48F21E80B9 for ; Fri, 6 Sep 2013 11:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ciy8bHRXTbzq for ; Fri, 6 Sep 2013 11:49:39 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8121E80CE for ; Fri, 6 Sep 2013 11:49:39 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 29811F25B5; Fri, 6 Sep 2013 11:49:38 -0700 (PDT) Message-ID: <522A23C1.2030900@mozilla.com> Date: Fri, 06 Sep 2013 14:49:37 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bo Burman References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 18:49:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a consensus call made a while ago and as far as I remember, there was no WG consensus for any SHOULD/RECOMMENDED codecs. Cheers, Jean-Marc On 08/27/2013 10:53 AM, Bo Burman wrote: > Based on the previous discussion thread > http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html, > I believe there is support to add some text into this document. > > I thus propose to add the following text at the end of section 3: > > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in > order to maximize the possibility to establish the session without > the need for audio transcoding > > Cheers, Bo > >> -----Original Message----- From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org Sent: den 2 augusti 2013 18:30 To: >> i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: I-D Action: >> draft-ietf-rtcweb-audio-02.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Real-Time Communication in WEB-browsers Working Group of the >> IETF. >> >> Title : WebRTC Audio Codec and Processing Requirements >> Author(s) : Jean-Marc Valin Cary Bran Filename : >> draft-ietf-rtcweb-audio-02.txt Pages : 6 Date : >> 2013-08-02 >> >> 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-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02 >> >> >> Please note that it may take a couple of minutes from the time >> of submission until the htmlized version and diff are available >> at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ 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 > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKiPAAAoJEJ6/8sItn9q9908H/iMwmIJWroZn/rWH8ndqg/am e6yrEl9ZkcRGXXmhqZB4rhDGtUSFasqKyEi/l9SqD1/CR7CazwA0wFDKIVXrsilM 0iG/AlfmBtLHAC3sF2cIvd08q1oYcQgMowyDxUDGJo4ZnsKkQooMjjOuDFg9yYer WT3WXpgNi3G1XrYWZ+03gwDUY44LmSrNdYfSca0Ys+/QOL4oLROKubAbv6Frou+T FrL3y32701wQceWKXKzLXBIisHC4exF00+8v88BYQKEIwxXpfJvJx/HNdE3z/GIC vVakzxB0p11+suwL3NHnM19S1yYnQLDBadivpT1tWpZ8O2Uh0xHECqXd54i5czc= =bNwR -----END PGP SIGNATURE----- From mzanaty@cisco.com Fri Sep 6 13:28:42 2013 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 B32AF21F9B07 for ; Fri, 6 Sep 2013 13:28: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FK4LmbfVpef for ; Fri, 6 Sep 2013 13:28:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E745821F9C2C for ; Fri, 6 Sep 2013 13:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4160; q=dns/txt; s=iport; t=1378499318; x=1379708918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W5EUbhrFtvot3ZzrHxj9uCpAl5kg0678hq9FdEWwJ50=; b=GyiLf5QVMxDzAxzhSWd0XY8EQ/McxKXONbB5YAyDXJqa+2t3XvtwmmZ6 Qu01I2nDhG/VgEsZBaRYa4MW4mFcOgDzQUuGB6ncfOGjpU5lZglJGuS7P KAXDvw3hsZoI73OCaaZvf6aH9wpU2r48Y6AGAl5X1ytjo3GYgYrrSVBsD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALE5KlKtJV2a/2dsb2JhbABbgwc1SwbBX4EmFnSCJAEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIAYd5BwW9UY5DgQgxAgUGgxeBAAOUG4UJiwuFLIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,856,1371081600"; d="scan'208";a="256447958" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 20:28:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r86KSbhp008524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 20:28:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 15:28:37 -0500 From: "Mo Zanaty (mzanaty)" To: Jean-Marc Valin , Bo Burman Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOqzHVCTCNRbUxykmV6tr8IYwOK5m5JCLw Date: Fri, 6 Sep 2013 20:28:36 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> In-Reply-To: <522A23C1.2030900@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 20:28:42 -0000 Clearly no consensus for any more specific codecs. But the proposed text ju= st says if you have more codecs available (not specific ones), you should o= ffer them all, rather than suppress them and only offer the required codecs= . So if the "will of the implementer" (current text) is neutral, this may s= way them to offer more than required. If the will is hostile to other codec= s, this text won't matter. Mo -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Jean-Marc Valin Sent: Friday, September 06, 2013 2:50 PM To: Bo Burman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a consensus call made a while ago and as far as I remember, there was no WG consensus for any SHOULD/RECOMMENDED codecs. Cheers, Jean-Marc On 08/27/2013 10:53 AM, Bo Burman wrote: > Based on the previous discussion thread=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html, > I believe there is support to add some text into this document. >=20 > I thus propose to add the following text at the end of section 3: >=20 > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in > order to maximize the possibility to establish the session without > the need for audio transcoding >=20 > Cheers, Bo >=20 >> -----Original Message----- From: i-d-announce-bounces@ietf.org=20 >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 >> internet-drafts@ietf.org Sent: den 2 augusti 2013 18:30 To:=20 >> i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: I-D Action:=20 >> draft-ietf-rtcweb-audio-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Real-Time Communication in WEB-browsers Working Group of the >> IETF. >>=20 >> Title : WebRTC Audio Codec and Processing Requirements >> Author(s) : Jean-Marc Valin Cary Bran Filename :=20 >> draft-ietf-rtcweb-audio-02.txt Pages : 6 Date : >> 2013-08-02 >>=20 >> Abstract: This document outlines the audio codec and processing=20 >> requirements for WebRTC client application and endpoint devices. >>=20 >>=20 >> The IETF datatracker status page for this draft is:=20 >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio >>=20 >> There's also a htmlized version available at:=20 >> http://tools.ietf.org/html/draft-ietf-rtcweb-audio-02 >>=20 >> A diff from the previous version is available at:=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time >> of submission until the htmlized version and diff are available >> at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at:=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ I-D-Announce=20 >> mailing list I-D-Announce@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKiPAAAoJEJ6/8sItn9q9908H/iMwmIJWroZn/rWH8ndqg/am e6yrEl9ZkcRGXXmhqZB4rhDGtUSFasqKyEi/l9SqD1/CR7CazwA0wFDKIVXrsilM 0iG/AlfmBtLHAC3sF2cIvd08q1oYcQgMowyDxUDGJo4ZnsKkQooMjjOuDFg9yYer WT3WXpgNi3G1XrYWZ+03gwDUY44LmSrNdYfSca0Ys+/QOL4oLROKubAbv6Frou+T FrL3y32701wQceWKXKzLXBIisHC4exF00+8v88BYQKEIwxXpfJvJx/HNdE3z/GIC vVakzxB0p11+suwL3NHnM19S1yYnQLDBadivpT1tWpZ8O2Uh0xHECqXd54i5czc=3D =3DbNwR -----END PGP SIGNATURE----- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Sep 6 13:38:07 2013 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 53FD511E80F9 for ; Fri, 6 Sep 2013 13:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD2vD3xK9HwY for ; Fri, 6 Sep 2013 13:38:06 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA511E80F3 for ; Fri, 6 Sep 2013 13:38:06 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hj3so1401915wib.7 for ; Fri, 06 Sep 2013 13:38:04 -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=g9/UnWTEtubudvtRKjhBbzctuY6xn2k+PTRIlpMD7hY=; b=Tag2k4b0ql9v+nIKwnMKfrkkd4Cz1yFwkZgqIvAz77PBpZiLGWHBLSm2R27hKE+hFz V/vpuGrKfPq3kjlZdzp8W6ASC7JrtVAlNVlSSYSLfMz79jXd32K2DHP1SZhq5acWPaKM gqumf8yDk7CZgcjmUJWYM+tx1i1lthx6hZaDkTmFGmQDAjbK8AZsZ5Wvh4Ol0gLp8j4h QdsSs0gs40j87f+z49PAylUa1x8JYii1Rl7CHVsdfoCsjavSPjwiztzM+FCyfFPPQLpb ttxdMr7v3/Q1Sc3l4yFUVhKfbM3YREqWeQTSoGABuOuATHUZVvr/wFKRBt8KmFoF+sWV 1rMA== MIME-Version: 1.0 X-Received: by 10.180.20.42 with SMTP id k10mr528751wie.0.1378499884858; Fri, 06 Sep 2013 13:38:04 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 6 Sep 2013 13:38:04 -0700 (PDT) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> Date: Fri, 6 Sep 2013 13:38:04 -0700 Message-ID: From: Martin Thomson To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 20:38:07 -0000 On 6 September 2013 13:28, Mo Zanaty (mzanaty) wrote: > If the will is hostile to other codecs, this text won't matter. The natural disposition of the implementer is hostility toward more work, so I don't see the text making much difference either way. From mzanaty@cisco.com Fri Sep 6 14:42:14 2013 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 30E0111E80F1 for ; Fri, 6 Sep 2013 14:42:14 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znbu4FPtUYeu for ; Fri, 6 Sep 2013 14:42:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E060C11E8108 for ; Fri, 6 Sep 2013 14:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1102; q=dns/txt; s=iport; t=1378503728; x=1379713328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zJ0pFrg29f4PU2sekORfpQonOD9yFseNKBIUhb5J2PI=; b=TgeQ9mryCJD/I9/DLKN8tcQ9MHOCoKovUwPRcDqBJ4iWfS/PfZyfZHIg DR/OqJjkGPeUJzL2MCYwY1/0Xn3bFydzLx3VGFiHJn3LwWXXtnoDZ8Hwe V4+28ZSNoJH2OQwXZeTRP0dQuwLLGJLnyivvolov5qcMQU75YDC0S4/lt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAMJLKlKtJV2b/2dsb2JhbABbgweBBoJjR742F4EPFnSCJAEBAQQjEUUMBAIBCBEEAQEBAgIGHQMCAgIfERQBCAgCBA4FCIdoAw+sKYglDYh7gSmLZYI9MQcGgmM0gQADlgyOIIUvgyCCKg X-IronPort-AV: E=Sophos;i="4.90,857,1371081600"; d="scan'208";a="256635356" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 06 Sep 2013 21:42:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86Lg7F4020462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 21:42:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 16:42:07 -0500 From: "Mo Zanaty (mzanaty)" To: Martin Thomson Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOqzHVCTCNRbUxykmV6tr8IYwOK5m5JCLwgABbRAD//7U6sA== Date: Fri, 6 Sep 2013 21:42:06 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.189] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 21:42:14 -0000 VHJ1ZS4gVGhlIHNhbWUgY2FuIGJlIHNhaWQgYWJvdXQgZXZlcnkgU0hPVUxELCBidXQgd2Ugc3Rp bGwgYm90aGVyIHRvIHNwZWNpZnkgaXQuDQpNYXliZSB3ZSBzaG91bGQgdXBkYXRlIFJGQyAyMTE5 IHRvIHN0YXRlOg0KDQpPYmV5OiAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiDQpJZ25vcmU6ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1F TkRFRCIsICJNQVkiLCAiT1BUSU9OQUwiDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpT ZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNiwgMjAxMyA0OjM4IFBNDQpUbzogTW8gWmFuYXR5ICht emFuYXR5KQ0KQ2M6IEplYW4tTWFyYyBWYWxpbjsgQm8gQnVybWFuOyBydGN3ZWJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRp by0wMi50eHQNCg0KT24gNiBTZXB0ZW1iZXIgMjAxMyAxMzoyOCwgTW8gWmFuYXR5IChtemFuYXR5 KSA8bXphbmF0eUBjaXNjby5jb20+IHdyb3RlOg0KPiBJZiB0aGUgd2lsbCBpcyBob3N0aWxlIHRv IG90aGVyIGNvZGVjcywgdGhpcyB0ZXh0IHdvbid0IG1hdHRlci4NCg0KVGhlIG5hdHVyYWwgZGlz cG9zaXRpb24gb2YgdGhlIGltcGxlbWVudGVyIGlzIGhvc3RpbGl0eSB0b3dhcmQgbW9yZQ0Kd29y aywgc28gSSBkb24ndCBzZWUgdGhlIHRleHQgbWFraW5nIG11Y2ggZGlmZmVyZW5jZSBlaXRoZXIg d2F5Lg0K From martin.thomson@gmail.com Fri Sep 6 15:22:38 2013 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 9BCD711E8138 for ; Fri, 6 Sep 2013 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DpCKD9rfh0Q for ; Fri, 6 Sep 2013 15:22:38 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D25C011E8135 for ; Fri, 6 Sep 2013 15:22:37 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id u57so2466851wes.11 for ; Fri, 06 Sep 2013 15:22:34 -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=2gKkC7iu/IW2nmvV1R+gYzwUyOq2/ZCoji7Tlz5dNAc=; b=PMfK2vDmCplNug5sX7FEe4HklW6db/mkjns896YrcPLJlub0m9nuQQlSHjqPzD/PJ6 8cgmkHNmMOLlu961LRQgAlA3JerZjxBycZpSjcuJxbPheji5KKMiGU46UVhbhkskW6oN NEeC1fPNxCtAst0yk67CdBC7jDUgFCE0QFYdHzcJ/p1GWmDog/6zVVFzS1EHdoJMQNYk +g8BRB9zxIvmtuQRD6dEscNU56QiCPbg5scE5vwTtNNCKmSeYkW4W84bcF6DZEUvpOwD e5COXVc7RX9AZOJIy5tFQ/iZPiBsGjZKQRsPaXvORQr87KCAjH1r6dUx7U6rJU8XwOM3 Ewlg== MIME-Version: 1.0 X-Received: by 10.180.188.132 with SMTP id ga4mr133127wic.10.1378506154613; Fri, 06 Sep 2013 15:22:34 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 6 Sep 2013 15:22:34 -0700 (PDT) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> Date: Fri, 6 Sep 2013 15:22:34 -0700 Message-ID: From: Martin Thomson To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 22:22:38 -0000 On 6 September 2013 14:42, Mo Zanaty (mzanaty) wrote: > True. The same can be said about every SHOULD, but we still bother to specify it. Most SHOULDs I've written are more like "MUST unless you have some some good reasons that we haven't bothered to enumerate". These serve as an escape valve for people who want to break the rules in a controlled environment. That's interoperability requirements though, not implementation. I haven't ever done anything equivalent to MUST implement/SHOULD implement, which is what we are talking about here. From harald@alvestrand.no Fri Sep 6 15:27:22 2013 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 BBBF421F925A for ; Fri, 6 Sep 2013 15:27:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxEZKWY8VQuA for ; Fri, 6 Sep 2013 15:27:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A44EB11E80FC for ; Fri, 6 Sep 2013 15:27:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7876839E1AD for ; Sat, 7 Sep 2013 00:27:12 +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 Wqmy30E52T1v for ; Sat, 7 Sep 2013 00:27:11 +0200 (CEST) Received: from [172.30.42.74] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A2CBE39E170 for ; Sat, 7 Sep 2013 00:27:11 +0200 (CEST) Message-ID: <522A56BF.7050509@alvestrand.no> Date: Sat, 07 Sep 2013 00:27:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 22:27:26 -0000 On 09/06/2013 11:42 PM, Mo Zanaty (mzanaty) wrote: > True. The same can be said about every SHOULD, but we still bother to specify it. > Maybe we should update RFC 2119 to state: > > Obey: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" > Ignore: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" At the time 2119 was written (I remember discussing this with Scott Bradner several times), the intent of the text for "SHOULD" was "you'd better do this if you don't have a real good reason why it's not a reasonable thing to do in your particular case". Quoth: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Of course, people who don't want to cover all the SHOULDs have pushed towards interpreting it as "weak recommendation that we can ignore if we feel like it", but that wasn't the original intent of 2119, and some of us still want to have that word available for use in the stronger meaning. At one time there was push towards saying that "if you write SHOULD in an RFC, you need to spell out the circumstances where it'll be reasonable to ignore it - otherwise, write MUST or MAY". That push has petered out at this time, but I felt sympathetic to the idea. That's why I'm so reluctant to use the word in cases where I think a large part of the implementors are going to ignore it, and where (in my opinion) no great harm comes to interoperability when they do. But this instance not something I storm barricades over; if the consensus of the WG is to use "RECOMMENDED" rather than "recommended", I'll note that I'm the rough part of the consensus, and live with it. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Friday, September 06, 2013 4:38 PM > To: Mo Zanaty (mzanaty) > Cc: Jean-Marc Valin; Bo Burman; rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > On 6 September 2013 13:28, Mo Zanaty (mzanaty) wrote: >> If the will is hostile to other codecs, this text won't matter. > The natural disposition of the implementer is hostility toward more > work, so I don't see the text making much difference either way. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Sep 6 15:39:42 2013 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 7E62C21F9FF9 for ; Fri, 6 Sep 2013 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoAoWEqjy7MO for ; Fri, 6 Sep 2013 15:39:38 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A907121F9E77 for ; Fri, 6 Sep 2013 15:39:36 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hj3so1493083wib.7 for ; Fri, 06 Sep 2013 15:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zd/NEsCY1xLg4yyseoImDU8vL3pzQwHiL9Je/1txUNU=; b=nSiAoHZ5uHpSLF4c+EeiKgCeDTr6+LkPx729suJvzN+kzKw+PflAYbtljnaKwt9ekX Bdhw7Pav/Ev20uoshx4nJG2D+h429F14ZBqH+yB8FlmVU0z9nBg/pI4W7b3ui7ygvRww HeoXHoXEm1HCD6Ux3OkBTc+25MmtsgxGEf3N8unQyxmnHa1vDS8Ysq36hrzj3m3KvSEn TitLJCDpan/srN3845G9XsmWecOUxHXTRpooPDbpzeWB69ChMXfh0uB5wyV+GPFuSJhl dN4d5kfqt8hGQapaYzCc8mBWIZqOmqgI+hobXXzYojR4zqPvOCX3oc3gz3C0FSRIwDhB 29zg== MIME-Version: 1.0 X-Received: by 10.180.39.38 with SMTP id m6mr173713wik.10.1378507175806; Fri, 06 Sep 2013 15:39:35 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 6 Sep 2013 15:39:35 -0700 (PDT) In-Reply-To: <522A56BF.7050509@alvestrand.no> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> <522A56BF.7050509@alvestrand.no> Date: Fri, 6 Sep 2013 15:39:35 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 06 Sep 2013 22:39:42 -0000 On 6 September 2013 15:27, Harald Alvestrand wrote: > That's why I'm so reluctant to use the word in cases where I think a large > part of the implementors are going to ignore it, and where (in my opinion) > no great harm comes to interoperability when they do. I tend to agree, though we have to be careful not to end up with the RFC 6919, Section 1 problem at the same time. I still try to do the "MUST, unless ..." form rather than SHOULD. SHOULD is a bit wishy-washy. In this case, I don't see the point of saying anything at all. I'm sure that browser implementers will add what they believe will be best for their users. And avoiding transcoding is good, which should be sufficient. Ultimately, we're all grown-ups, and having the IETF tells us to eat our vegetables is insulting. From stephane.proust@orange.com Sun Sep 8 23:47:54 2013 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 C383121E814A for ; Sun, 8 Sep 2013 23:47:54 -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=[UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhsaLqD0lP8i for ; Sun, 8 Sep 2013 23:47:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5240D21E8148 for ; Sun, 8 Sep 2013 23:47:34 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7D6822AC361; Mon, 9 Sep 2013 08:47:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6360C38403C; Mon, 9 Sep 2013 08:47:32 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 08:47:32 +0200 From: To: 'Martin Thomson' , 'Harald Alvestrand' Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOj52YNf0VLpHUzEKr6spLBSmfVZmnooUwgBGAZICAABuoAIAAAqUAgAAR5ACAAAyZgIAAA3aAgAPJXtA= Date: Mon, 9 Sep 2013 06:47:31 +0000 Message-ID: <12397_1378709252_522D6F04_12397_16983_1_2842AD9A45C83B44B57635FD4831E60A06C3B148@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> <522A56BF.7050509@alvestrand.no> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.52415 Cc: "'rtcweb@ietf.org'" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Mon, 09 Sep 2013 06:47:54 -0000 Let's avoid reopening the whole discussion about this normative wording!=20 I would like to recall again that the proposal from Bo comes from a comprom= ise statement that was almost reached in e-mail discussions last January (f= rom an initial proposal from Andrew Allen) and almost reached now again http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html So it confirms clearly that the consensus of the group is on the proposed t= ext and especially because it does not include any formal normative languag= e.=20 So I would strongly suggest to not reinvent anything new and close now this= long discussion on the last proposal from Bo on which several supports hav= e been expressed and no objections, possibly with the slight modification s= uggested by Mo Zanaty on the place where the text can be added (beginning o= f section 3) which is a good idea that I support as well http://www.ietf.org/mail-archive/web/rtcweb/current/msg08750.html St=E9phane -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Martin Thomson Envoy=E9=A0: samedi 7 septembre 2013 00:40 =C0=A0: Harald Alvestrand Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt On 6 September 2013 15:27, Harald Alvestrand wrote: > That's why I'm so reluctant to use the word in cases where I think a=20 > large part of the implementors are going to ignore it, and where (in=20 > my opinion) no great harm comes to interoperability when they do. I tend to agree, though we have to be careful not to end up with the RFC 69= 19, Section 1 problem at the same time. I still try to do the "MUST, unless ..." form rather than SHOULD. SHOULD is a bit wishy-washy. In this case, I don't see the point of saying anything at all. I'm sure th= at browser implementers will add what they believe will be best for their u= sers. And avoiding transcoding is good, which should be sufficient. Ultim= ately, we're all grown-ups, and having the IETF tells us to eat our vegetab= les is insulting. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From magnus.westerlund@ericsson.com Mon Sep 9 01:38:04 2013 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 5340F21E8139 for ; Mon, 9 Sep 2013 01:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHvUP7KRfMDQ for ; Mon, 9 Sep 2013 01:37:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 498B921E80AC for ; Mon, 9 Sep 2013 01:37:49 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-44-522d88dd9b63 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AE.F0.03802.DD88D225; Mon, 9 Sep 2013 10:37:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Mon, 9 Sep 2013 10:36:29 +0200 Message-ID: <522D88A8.3010209@ericsson.com> Date: Mon, 9 Sep 2013 10:36:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvje7dDt0ggzv9IhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9nC64wFfZwVR+ZPYWpgPM/excjBISFgIjH9mHMXIyeQKSZx 4d56ti5GLg4hgcOMEvsPdEE5yxglTvw6xg5SxSugLbHjaw+YzSKgInHtygc2EJtNwELi5o9G MFtUIFiifftXNoh6QYmTM5+wgNgiAuoSlx9eAOsVFjCXuLx2JyPEZkmJbYsg5jML6ElMudrC CGHLSzRvnc0MYgsB7W1o6mCdwMg/C8nYWUhaZiFpWcDIvIqRPTcxMye93GgTIzCcDm75rbqD 8c45kUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgXG1zqHzH1DMN9ly7 urh6hVZLHEud4Zrp7VOZeKajwfHg/aP9hdrnHXVjpVmvWcmVV+skC3x2uz19+7p483lb9Tn9 bZjn8GRVV3S2TH03e01a5YO1k2111dKvF90LubBGUss59YfFj/A5s8J+J9wO65oq6eZ/8e/F +1+edxdt/urRXOD7qdpRiaU4I9FQi7moOBEA+3QOYfUBAAA= Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 08:38:04 -0000 WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter. The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as WG item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Sep 9 01:47:39 2013 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 CA44921E80B6 for ; Mon, 9 Sep 2013 01:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57EEFAx8FKtE for ; Mon, 9 Sep 2013 01:47:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0344121E80B4 for ; Mon, 9 Sep 2013 01:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8A3139E1BD; Mon, 9 Sep 2013 10:47:17 +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 CaMXiYo0atg0; Mon, 9 Sep 2013 10:47:15 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 196B339E04C; Mon, 9 Sep 2013 10:47:15 +0200 (CEST) Message-ID: <522D8B12.9000109@alvestrand.no> Date: Mon, 09 Sep 2013 10:47:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: stephane.proust@orange.com References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> <522A56BF.7050509@alvestrand.no> <12397_1378709252_522D6F04_12397_16983_1_2842AD9A45C83B44B57635FD4831E60A06C3B148@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <12397_1378709252_522D6F04_12397_16983_1_2842AD9A45C83B44B57635FD4831E60A06C3B148@PEXCVZYM14.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'rtcweb@ietf.org'" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Mon, 09 Sep 2013 08:47:39 -0000 This last round was triggered by Leon Geyser suggesting that we put REQUIRED in there. I'm happy with the proposal made in January (lowercase "recommended"), weakly opposed to SHOULD / RECOMMENDED and strongly opposed to MUST / REQUIRED. I'm perfectly willing to go along with a chairs' declaration that the WG has consensus for SHOULD / RECOMMENDED, but it's up to the chairs to make the call. I'll try to remain silent on the issue until the chairs have spoken. On 09/09/2013 08:47 AM, stephane.proust@orange.com wrote: > Let's avoid reopening the whole discussion about this normative wording! > > I would like to recall again that the proposal from Bo comes from a compromise statement that was almost reached in e-mail discussions last January (from an initial proposal from Andrew Allen) and almost reached now again > http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html > > So it confirms clearly that the consensus of the group is on the proposed text and especially because it does not include any formal normative language. > So I would strongly suggest to not reinvent anything new and close now this long discussion on the last proposal from Bo on which several supports have been expressed and no objections, possibly with the slight modification suggested by Mo Zanaty on the place where the text can be added (beginning of section 3) which is a good idea that I support as well > http://www.ietf.org/mail-archive/web/rtcweb/current/msg08750.html > > Stéphane > > > > > > > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Martin Thomson > Envoyé : samedi 7 septembre 2013 00:40 > À : Harald Alvestrand > Cc : rtcweb@ietf.org > Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > On 6 September 2013 15:27, Harald Alvestrand wrote: >> That's why I'm so reluctant to use the word in cases where I think a >> large part of the implementors are going to ignore it, and where (in >> my opinion) no great harm comes to interoperability when they do. > I tend to agree, though we have to be careful not to end up with the RFC 6919, Section 1 problem at the same time. > > I still try to do the "MUST, unless ..." form rather than SHOULD. > SHOULD is a bit wishy-washy. > > In this case, I don't see the point of saying anything at all. I'm sure that browser implementers will add what they believe will be best for their users. And avoiding transcoding is good, which should be sufficient. Ultimately, we're all grown-ups, and having the IETF tells us to eat our vegetables is insulting. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From simon.perreault@viagenie.ca Mon Sep 9 02:24:45 2013 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 1A2DF21F8749 for ; Mon, 9 Sep 2013 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP5j+1kZeBEJ for ; Mon, 9 Sep 2013 02:24:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6062811E81B5 for ; Mon, 9 Sep 2013 02:24:33 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8FC4B403D2 for ; Mon, 9 Sep 2013 05:24:31 -0400 (EDT) Message-ID: <522D93CE.2050103@viagenie.ca> Date: Mon, 09 Sep 2013 11:24:30 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 09:24:45 -0000 Le 2013-09-09 10:36, Magnus Westerlund a écrit : > This is a call for WG adoption of STUN Usage for Consent Freshness > (draft-muthu-behave-consent-freshness-04). This document defines a STUN > usage for consent freshness. As this requires no protocol extensions we > as intended users can define this usage in our WG. Such work also > matches our charter. The draft-ietf-rtcweb-security-arch-07 is > normatively dependent on this STUN usage. > > Document: > https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > > WG, please indicate your support or issues with adopting this document > as WG item with a proposed milestone: > > Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication > as proposed standard. I have commented multiple times on this doc. I support its adoption now. Simon From harald@alvestrand.no Mon Sep 9 03:00:47 2013 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 DDDF421E815C for ; Mon, 9 Sep 2013 03:00: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0D2YI4Tz8Ap for ; Mon, 9 Sep 2013 03:00:30 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3FD21E8159 for ; Mon, 9 Sep 2013 03:00:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A816839E1A6 for ; Mon, 9 Sep 2013 12:00:28 +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 zzWsxQgsUtyI for ; Mon, 9 Sep 2013 12:00:27 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1ED7639E04C for ; Mon, 9 Sep 2013 12:00:27 +0200 (CEST) Message-ID: <522D9C3A.6020103@alvestrand.no> Date: Mon, 09 Sep 2013 12:00:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 10:00:47 -0000 I support adoption as a working group document. On 09/09/2013 10:36 AM, Magnus Westerlund wrote: > WG, > > This is a call for WG adoption of STUN Usage for Consent Freshness > (draft-muthu-behave-consent-freshness-04). This document defines a STUN > usage for consent freshness. As this requires no protocol extensions we > as intended users can define this usage in our WG. Such work also > matches our charter. The draft-ietf-rtcweb-security-arch-07 is > normatively dependent on this STUN usage. > > Document: > https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > > WG, please indicate your support or issues with adopting this document > as WG item with a proposed milestone: > > Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication > as proposed standard. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Mon Sep 9 05:22:29 2013 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 54A2F21E81AA for ; Mon, 9 Sep 2013 05:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18DYaXj9b1LC for ; Mon, 9 Sep 2013 05:22:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE021E81BC for ; Mon, 9 Sep 2013 05:20:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d9-522dbd0398af Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.D0.16099.30DBD225; Mon, 9 Sep 2013 14:20:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 14:20:17 +0200 From: Christer Holmberg To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOrTfpPPSJ2RpCQEK9doXqsrtdnpm9T/RA Date: Mon, 9 Sep 2013 12:20:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvjS7zXt0gg72d/BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/iJqawFnwQqHmw6xNLA+I23i5GTQ0LARGJB32k2CFtM4sK9 9UA2F4eQwGFGiV/X3kI5ixklpu/vYe9i5OBgE7CQ6P6nDdIgIhAr8X72VVYQW1jAReLZ3MOM EHFXiSmrrzFD2EYSH3a+ZwKxWQRUJE62fQazeQV8JZYd2wzWKySgLXFrxiR2EJtTQEdiw4Qf YAcxAh30/dQasHpmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaiRPvTBkaIej2JG1OnsEHY 2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9NzMxJLzfcxAgM+4Nbfuvu YDx1TuQQozQHi5I47ya9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKUrT17k2Dp9PsN2 0QdTnkfw2uTPfRa+dvYLOe8HWnNVGPtFXPKWPvVb7d7z5czv7H7ll6F34lauzn61zXR2CI9D S3PUjsibj03vahgZ6O6delbF9cDMlwtYH1XUsM4+8JkzPLP5lHrtgoWXz0x49jEneZr/ytxj 65Zz9L4Ksdiveu+Pa0vWpi9KLMUZiYZazEXFiQAttHmnSQIAAA== Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 12:22:29 -0000 Hi, I don't object adoption, but a question for clarification. The draft says: "While a WebRTC browser could verify whether the peer continues to send SRTCP reports before sending traffic to the peer, the usage of SRTCP together with Security Descriptions [RFC4568] requires exposing the media keys to the JavaScript and renders SRTCP unsuitable for consent freshness." Now, as we have decided to not use SDES, I guess that can be removed. But, based on that, I'd just like to verify whether there is still a need f= or the draft :) Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: 9. syyskuuta 2013 11:37 To: rtcweb@ietf.org Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-m= uthu-behave-consent-freshness-04). This document defines a STUN usage for c= onsent freshness. As this requires no protocol extensions we as intended us= ers can define this usage in our WG. Such work also matches our charter. Th= e draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN = usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as W= G item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as p= roposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Sep 9 05:29:51 2013 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 5FC9F11E81C3 for ; Mon, 9 Sep 2013 05:29:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akikl2Er3SbM for ; Mon, 9 Sep 2013 05:29:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E83121E81A8 for ; Mon, 9 Sep 2013 05:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7C3539E1C9 for ; Mon, 9 Sep 2013 14:27:37 +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 3pED7YmqACSJ for ; Mon, 9 Sep 2013 14:27:37 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3B4F039E04C for ; Mon, 9 Sep 2013 14:27:37 +0200 (CEST) Message-ID: <522DBEB8.5090207@alvestrand.no> Date: Mon, 09 Sep 2013 14:27:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <522D88A8.3010209@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?) 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, 09 Sep 2013 12:29:51 -0000 Changing the subject line to make life simpler for those who count the respondents :-) On 09/09/2013 02:20 PM, Christer Holmberg wrote: > Hi, > > I don't object adoption, but a question for clarification. > > The draft says: > > "While a WebRTC browser could verify whether the peer continues to > send SRTCP reports before sending traffic to the peer, the usage of > SRTCP together with Security Descriptions [RFC4568] requires exposing > the media keys to the JavaScript and renders SRTCP unsuitable for > consent freshness." > > Now, as we have decided to not use SDES, I guess that can be removed. > > But, based on that, I'd just like to verify whether there is still a need for the draft :) > Personal opinion: I think SRTCP is still unsuitable for consent freshness. One reason (apart from any aspect that deals with security, on which I don't want to comment) is that if one sets up a connection with only a data channel, there will be no SSRCs to send SRTCP on. From christer.holmberg@ericsson.com Mon Sep 9 05:46:55 2013 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 0963111E81D2 for ; Mon, 9 Sep 2013 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6T+Oe3j5m-a for ; Mon, 9 Sep 2013 05:46:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA611E81DC for ; Mon, 9 Sep 2013 05:44:24 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-10-522dc2a76d60 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.5E.03802.7A2CD225; Mon, 9 Sep 2013 14:44:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 14:44:23 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?) Thread-Index: AQHOrVhKxrqBvv9r0EWDNy7/gfNt45m9WOTg Date: Mon, 9 Sep 2013 12:44:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C49B5F7@ESESSMB209.ericsson.se> References: <522D88A8.3010209@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> <522DBEB8.5090207@alvestrand.no> In-Reply-To: <522DBEB8.5090207@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6KQ7pBBn1H2C2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGVs/dXGWjCHt+LpJpcGxrNcXYycHBICJhK3 Lz1jhrDFJC7cW8/WxcjFISRwmFGiddouRghnMaPEzx17gBwODjYBC4nuf9ogDSICwRK9z98z gtjCAmUSyy/sYoGIl0ss2P6MEcI2klh35Ss7iM0ioCLRv+YIE4jNK+ArsfXSNahlkxglJi58 wgqS4BTQlVg54zwbiM0IdNH3U2vAGpgFxCVuPZnPBHGpgMSSPeehrhaVePn4HyuErSjR/rSB EaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL jTYxAmPh4JbfqjsY75wTOcQozcGiJM67We9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG 7fob2qetucjP+3+rr3r3+b07j39Tuv//tvZfzwt2n/lKY5yXua8TT+ObH3z69X8zxd/19Xwh gtIdTSJPnYyyLFa9+v7d7d7vy79E36cbi81cPVuXP1T5RmlJ9KHFT0/fcbX47HJZ/eqL4rwV T3c8qr0u1F5zzOZHzq/cmBfTl7/atEvMX5e5TYmlOCPRUIu5qDgRAMPfSZ9TAgAA Subject: Re: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?) 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, 09 Sep 2013 12:46:55 -0000 Hi, And, from a security perspective (the backward compatibility is a separate = issue) the requirement to integrity protect the STUN binding requests are n= ot affected by the SDES decision? Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 9. syyskuuta 2013 15:28 To: rtcweb@ietf.org Subject: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting d= raft-muthu-behave-consent-freshness?) Changing the subject line to make life simpler for those who count the resp= ondents :-) On 09/09/2013 02:20 PM, Christer Holmberg wrote: > Hi, > > I don't object adoption, but a question for clarification. > > The draft says: > > "While a WebRTC browser could verify whether the peer continues to > send SRTCP reports before sending traffic to the peer, the usage of > SRTCP together with Security Descriptions [RFC4568] requires exposing > the media keys to the JavaScript and renders SRTCP unsuitable for > consent freshness." > > Now, as we have decided to not use SDES, I guess that can be removed. > > But, based on that, I'd just like to verify whether there is still a=20 > need for the draft :) > Personal opinion: I think SRTCP is still unsuitable for consent freshness. = One reason (apart from any aspect that deals with security, on which I don'= t want to comment) is that if one sets up a connection with only a data cha= nnel, there will be no SSRCs to send SRTCP on. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Mon Sep 9 06:08:40 2013 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 9A88621E817B for ; Mon, 9 Sep 2013 06:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IiJZH05+9Kj for ; Mon, 9 Sep 2013 06:08:28 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id E089A21E81DC for ; Mon, 9 Sep 2013 06:05:13 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id r5so3235155qcx.23 for ; Mon, 09 Sep 2013 06:05:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uLPUXIxpyQ7CDE0bwqbQ5SyHtd+CkDElsp6OL+CYRPM=; b=HLfPz6/3WRb/Em6swtOAeJYNsYKORd96Maf6PuE2bmgeeG18I/1zbCfTgJgAYmWuro PeMyXtcoyFtZEH5W4OekuMGznhPQraH5b5JQGbBrbpEWUvLjju5fY4hE24zmVXJTm6ex oQS6lJWUKUuHnFJX3zzbMZ0VRdq75DhlK1tjek9nw7IQro6Fdhc+bLgDSu9Ofs8DEHM6 YsNgShkAvJgbuCaIHCfvWcHC7xPlkaK8hScW0OV6ekneQ5R1g7N/iaDqOZ+VgRvDSwUE 6cWkVthk1LR8InwrNWElxddvPjuzEatkkX2QclWUik/SeZhO7WztUuPhtl37S+gh5d16 EIHg== X-Gm-Message-State: ALoCoQlP9hmOikeZ6o1WlqdmCmuUpL9Dro14adretUesTNXISh37Ucs+Z9EU5aKk01wyPUJ6lQpB X-Received: by 10.229.127.74 with SMTP id f10mr24143345qcs.16.1378731913331; Mon, 09 Sep 2013 06:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.42.68 with HTTP; Mon, 9 Sep 2013 06:04:33 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <522D8B12.9000109@alvestrand.no> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> <522A56BF.7050509@alvestrand.no> <12397_1378709252_522D6F04_12397_16983_1_2842AD9A45C83B44B57635FD4831E60A06C3B148@PEXCVZYM14.corporate.adroot.infra.ftgroup> <522D8B12.9000109@alvestrand.no> From: Eric Rescorla Date: Mon, 9 Sep 2013 06:04:33 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1133dd4cef56f304e5f30914 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Mon, 09 Sep 2013 13:08:40 -0000 --001a1133dd4cef56f304e5f30914 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 9, 2013 at 1:47 AM, Harald Alvestrand wro= te: > This last round was triggered by Leon Geyser suggesting that we put > REQUIRED in there. > > I'm happy with the proposal made in January (lowercase "recommended"), > weakly opposed to SHOULD / RECOMMENDED and strongly opposed to MUST / > REQUIRED. I'm perfectly willing to go along with a chairs' declaration th= at > the WG has consensus for SHOULD / RECOMMENDED, but it's up to the chairs = to > make the call. > > I'll try to remain silent on the issue until the chairs have spoken. I would like to hear from the chairs as well. It was not my impression that we had consensus on any kind of recommendation here but rather that those against a recommendation had merely grown tired of arguing. I would suggest that we schedule a small amount of discussion time at the next IETF to resolve this (20 min should be sufficient) and verify consensus. However, I will defer to the chairs' judgement. -Ekr > > On 09/09/2013 08:47 AM, stephane.proust@orange.com wrote: > >> Let's avoid reopening the whole discussion about this normative wording! >> >> I would like to recall again that the proposal from Bo comes from a >> compromise statement that was almost reached in e-mail discussions last >> January (from an initial proposal from Andrew Allen) and almost reached = now >> again >> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg08501.html >> >> So it confirms clearly that the consensus of the group is on the propose= d >> text and especially because it does not include any formal normative >> language. >> So I would strongly suggest to not reinvent anything new and close now >> this long discussion on the last proposal from Bo on which several suppo= rts >> have been expressed and no objections, possibly with the slight >> modification suggested by Mo Zanaty on the place where the text can be >> added (beginning of section 3) which is a good idea that I support as we= ll >> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg08750.html >> >> St=E9phane >> >> >> >> >> >> >> -----Message d'origine----- >> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.**org] >> De la part de Martin Thomson >> Envoy=E9 : samedi 7 septembre 2013 00:40 >> =C0 : Harald Alvestrand >> Cc : rtcweb@ietf.org >> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >> >> On 6 September 2013 15:27, Harald Alvestrand >> wrote: >> >>> That's why I'm so reluctant to use the word in cases where I think a >>> large part of the implementors are going to ignore it, and where (in >>> my opinion) no great harm comes to interoperability when they do. >>> >> I tend to agree, though we have to be careful not to end up with the RFC >> 6919, Section 1 problem at the same time. >> >> I still try to do the "MUST, unless ..." form rather than SHOULD. >> SHOULD is a bit wishy-washy. >> >> In this case, I don't see the point of saying anything at all. I'm sure >> that browser implementers will add what they believe will be best for th= eir >> users. And avoiding transcoding is good, which should be sufficient. >> Ultimately, we're all grown-ups, and having the IETF tells us to eat ou= r >> vegetables is insulting. >> ______________________________**_________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/**listinfo/rtcweb >> >> ______________________________**______________________________** >> ______________________________**______________________________**_ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --001a1133dd4cef56f304e5f30914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 9, 2013 at 1:47 AM, Harald Alvestrand <har= ald@alvestrand.no> wrote:
This last round was triggered by Leon Geyser= suggesting that we put REQUIRED in there.

I'm happy with the proposal made in January (lowercase "recommende= d"), weakly opposed to SHOULD / RECOMMENDED and strongly opposed to MU= ST / REQUIRED. I'm perfectly willing to go along with a chairs' dec= laration that the WG has consensus for SHOULD / RECOMMENDED, but it's u= p to the chairs to make the call.

I'll try to remain silent on the issue until the chairs have spoken.

I would like to hear from the chairs as well.= It was not my impression that
we had consensus on any kind of re= commendation here but rather that
those against a recommendation had merely grown tired of arguing.

I would suggest that we schedule a small amount of dis= cussion time
at the next IETF to resolve this (20 min should be s= ufficient) and verify
consensus. However, I will defer to the chairs' judgement.

-Ekr



On 09/09/2013 08:47 AM, stephane.proust@orange.com wrote:
Let's avoid reopening the whole discussion about this normative wording= !

I would like to recall again that the proposal from Bo comes from a comprom= ise statement that was almost reached in e-mail discussions last January (f= rom an initial proposal from Andrew Allen) and almost reached now again
http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg08501.html

So it confirms clearly that the consensus of the group is on the proposed t= ext and especially because it does not include any formal normative languag= e.
So I would strongly suggest to not reinvent anything new and close now this= long discussion on the last proposal from Bo on which several supports hav= e been expressed and no objections, possibly with the slight modification s= uggested by Mo Zanaty on the place where the text can be added (beginning o= f section 3) which is a good idea that I support as well
http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg08750.html

St=E9phane






-----Message d'origine-----
De : rtcweb-bo= unces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Martin Thoms= on
Envoy=E9 : samedi 7 septembre 2013 00:40
=C0 : Harald Alvestrand
Cc : rtcweb@ietf.org
Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

On 6 September 2013 15:27, Harald Alvestrand <harald@alvestrand.no> wrote:
That's why I'm so reluctant to use the word in cases where I think = a
large part of the implementors are going to ignore it, and where (in
my opinion) no great harm comes to interoperability when they do.
I tend to agree, though we have to be careful not to end up with the RFC 69= 19, Section 1 problem at the same time.

I still try to do the "MUST, unless ..." form rather than SHOULD.=
SHOULD is a bit wishy-washy.

In this case, I don't see the point of saying anything at all. =A0I'= ;m sure that browser implementers will add what they believe will be best f= or their users. =A0And avoiding transcoding is good, which should be suffic= ient. =A0Ultimately, we're all grown-ups, and having the IETF tells us = to eat our vegetables is insulting.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

_____________________________________________________________= ____________________________________________________________<= br>
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.


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

--001a1133dd4cef56f304e5f30914-- From aeh@db.org Mon Sep 9 06:39:55 2013 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 01F9621F925A for ; Mon, 9 Sep 2013 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nnFp0kGrJw3 for ; Mon, 9 Sep 2013 06:39:42 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5663721F8E7C for ; Mon, 9 Sep 2013 06:38:41 -0700 (PDT) Received: from [173.38.208.169] (helo=[10.54.86.44]) by mailstore06.sysedata.no with esmtpa (Exim 4.71) (envelope-from ) id 1VJ1fp-00006W-I0; Mon, 09 Sep 2013 15:38:37 +0200 Message-ID: <522DCF5C.9080507@db.org> Date: Mon, 09 Sep 2013 15:38:36 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Magnus Westerlund References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 13:39:55 -0000 On 09/09/13 10:36, Magnus Westerlund wrote: > WG, > > This is a call for WG adoption of STUN Usage for Consent Freshness > (draft-muthu-behave-consent-freshness-04). This document defines a STUN > usage for consent freshness. As this requires no protocol extensions we > as intended users can define this usage in our WG. Such work also > matches our charter. The draft-ietf-rtcweb-security-arch-07 is > normatively dependent on this STUN usage. > > Document: > https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > > WG, please indicate your support or issues with adopting this document > as WG item with a proposed milestone: > I support adopting this document. /alfred From bernard_aboba@hotmail.com Mon Sep 9 08:45:22 2013 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 7D61A21E81C7 for ; Mon, 9 Sep 2013 08:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.109 X-Spam-Level: X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbvm1epJEPBe for ; Mon, 9 Sep 2013 08:45:09 -0700 (PDT) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4A30A21F883D for ; Mon, 9 Sep 2013 08:29:07 -0700 (PDT) Received: from BLU169-W71 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 08:29:07 -0700 X-TMN: [nTy2VrrGFiLwSIfleruKK5rtBBJjB1B0] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c54d25a5-1f1c-41c6-be7b-3bb8e7145466_" From: Bernard Aboba To: Harald Alvestrand , "rtcweb@ietf.org" Date: Mon, 9 Sep 2013 08:29:06 -0700 Importance: Normal In-Reply-To: <522D9C3A.6020103@alvestrand.no> References: <522D88A8.3010209@ericsson.com>,<522D9C3A.6020103@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2013 15:29:07.0431 (UTC) FILETIME=[52EA2770:01CEAD71] Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 15:45:22 -0000 --_c54d25a5-1f1c-41c6-be7b-3bb8e7145466_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Harald said:=20 > I support adoption as a working group document. = --_c54d25a5-1f1c-41c6-be7b-3bb8e7145466_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1

Harald said: =3B

>=3B I support adoption as a working = group document.

= --_c54d25a5-1f1c-41c6-be7b-3bb8e7145466_-- From bernard_aboba@hotmail.com Mon Sep 9 09:18:50 2013 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 821B911E81CE for ; Mon, 9 Sep 2013 09:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.853 X-Spam-Level: X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5fXT50bb+Uw for ; Mon, 9 Sep 2013 09:18:44 -0700 (PDT) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01921E81C7 for ; Mon, 9 Sep 2013 08:45:56 -0700 (PDT) Received: from BLU169-W33 ([65.55.116.74]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 08:45:56 -0700 X-TMN: [nLS2Ieop6SdljWdoRX4+gSR6XoS2LwFd] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d5d4e94b-4032-4052-9dc2-5ecf8cb4c1c5_" From: Bernard Aboba To: Christer Holmberg , "rtcweb@ietf.org" Date: Mon, 9 Sep 2013 08:45:55 -0700 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> References: <522D88A8.3010209@ericsson.com>, <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2013 15:45:56.0248 (UTC) FILETIME=[AC376980:01CEAD73] Subject: Re: [rtcweb] consent freshness vs. circuit breakers 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, 09 Sep 2013 16:18:50 -0000 --_d5d4e94b-4032-4052-9dc2-5ecf8cb4c1c5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= Christer said:=20 "Now=2C as we have decided to not use SDES=2C I guess that can be removed." [BA] Actually=2C I believe that a sentence or two describing why the needs = of consent freshness are not met by mechanisms such as SRTCP is worth keepi= ng=2C and possibly should even be expanded upon. One reason is that we als= o have the "circuit breakers" mechanism which *does* rely (in part) on SRTC= P. =20 Christer said:=20 "But=2C based on that=2C I'd just like to verify whether there is still a n= eed for the draft :)" [BA] I do think that the draft is still necessary=2C even without SDES/SRTP= . The usage of ICE for consent seems to me to be less susceptible to a va= riety of issues than a dependency on SRTCP might be.=20 However=2C I am concerned about the interaction between circuit breakers an= d consent freshness. At IETF 87=2C we heard that the circuit breakers mech= anism could fire even when the overall loss rate was quite low=2C due to bu= rst losses. That shouldn't be true of consent=2C since loss of consent req= uires up to 30 consecutive losses over a 15 second period. However=2C it w= ould appear to me that the current circuit breakers algorithms will cause m= edia sending to be curtailed prior to loss of consent in many cases. =20 =0A= = --_d5d4e94b-4032-4052-9dc2-5ecf8cb4c1c5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A= =0A= =0A=

Christer said:&nbs= p=3B

"Now=2C as we have decided to not use S= DES=2C I guess that can be removed."

[BA] Actually= =2C I believe that a sentence or two describing why the needs of consent fr= eshness are not met by mechanisms such as SRTCP is worth keeping=2C and pos= sibly should even be expanded upon.  =3BOne reason is that we also have= the "circuit breakers" mechanism which *does* rely (in part) on SRTCP. &nb= sp=3B =3B

Christer said: =3B

"But=2C based on that=2C I'd just like to verify whether there is still a = need for the draft :)"

[BA] I do think that the dr= aft is still necessary=2C even without SDES/SRTP.  =3B The usage of ICE= for consent seems to me to be less susceptible to a variety of issues than= a dependency on SRTCP might be. =3B

However= =2C I am concerned about the interaction between circuit breakers and conse= nt freshness.  =3BAt IETF 87=2C we heard that the circuit breakers mech= anism could fire even when the overall loss rate was quite low=2C due to bu= rst losses.  =3BThat shouldn't be true of consent=2C since loss of cons= ent requires up to 30 consecutive losses over a 15 second period.  =3BH= owever=2C it would appear to me that the current circuit breakers algorithm= s will cause media sending to be curtailed prior to loss of consent in many= cases.  =3B

=0A= = --_d5d4e94b-4032-4052-9dc2-5ecf8cb4c1c5_-- From andrew.hutton@siemens-enterprise.com Mon Sep 9 09:36:57 2013 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 A494111E8112 for ; Mon, 9 Sep 2013 09:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6K7uFNlaqHw for ; Mon, 9 Sep 2013 09:36:52 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 79D0911E8101 for ; Mon, 9 Sep 2013 09:36:51 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B62AF1EB84AF; Mon, 9 Sep 2013 18:36:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 18:36:46 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. Thread-Index: AQHOqIuNkwYToBE58EykiB8AyoOij5m9npdg Date: Mon, 9 Sep 2013 16:36:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> <5225B1AF.7050906@alvestrand.no> In-Reply-To: <5225B1AF.7050906@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 16:36:57 -0000 Q3VycmVudGx5IGRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDEgZG9lcyBub3Qgc2F5IGFu eXRoaW5nIGFib3V0IElQVjYgd2hpY2ggSSBhc3N1bWUgaXQgc2hvdWxkLiBTcGVjaWZpY2FsbHkg SSBhbSB0aGlua2luZyB0aGF0IGl0IG5lZWRzIHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQgdG8gc3Vw cG9ydCBSRkM2MTU2IHN1cHBvcnQgIlRyYXZlcnNhbCBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCAo VFVSTikgRXh0ZW5zaW9uIGZvciBJUHY2Ii4NCg0KSSBhbSBub3Qgc3VyZSBob3cgbXVjaCB3ZSBu ZWVkIHRvIHNheSBhYm91dCB3ZWJydGMgY2xpZW50IHByb2NlZHVyZXMgYXJvdW5kIFJGQzYxNTYg YW5kIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGRyYWZ0LWlldGYtcnRj d2ViLXRyYW5zcG9ydCBvciB3aGV0aGVyIGl0IGlzIHNvbWV0aGluZyB3ZSBzaG91bGQgYWRkIHRv IG91ciBuYXQvZmlyZXdhbGwgZHJhZnQgKGRyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxs LWNvbnNpZGVyYXRpb25zKS4gIEFueSBvcGluaW9ucyBvbiB0aGlzPw0KDQpSZWdhcmRzDQpBbmR5 DQoNCg0K From simon.perreault@viagenie.ca Mon Sep 9 09:44:33 2013 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 44D9911E8155 for ; Mon, 9 Sep 2013 09:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8JSIbgtGiPB for ; Mon, 9 Sep 2013 09:44:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51211E80D7 for ; Mon, 9 Sep 2013 09:44:32 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA81F4039A for ; Mon, 9 Sep 2013 12:44:31 -0400 (EDT) Message-ID: <522DFAEE.3060200@viagenie.ca> Date: Mon, 09 Sep 2013 18:44:30 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> <5225B1AF.7050906@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 16:44:33 -0000 Le 2013-09-09 18:36, Hutton, Andrew a écrit : > Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV6 which I assume it should. Specifically I am thinking that it needs to state a requirement to support RFC6156 support "Traversal Using Relays around NAT (TURN) Extension for IPv6". +1 > I am not sure how much we need to say about webrtc client procedures around RFC6156 and whether they should be included in the draft-ietf-rtcweb-transport or whether it is something we should add to our nat/firewall draft (draft-hutton-rtcweb-nat-firewall-considerations). Any opinions on this? Something along the lines of "IPv6 allocations MUST be requested even when the client only has IPv4 connectivity." ? Simon From cb.list6@gmail.com Mon Sep 9 09:50:59 2013 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 D8E5B11E8109 for ; Mon, 9 Sep 2013 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdWu7NUA0-Fy for ; Mon, 9 Sep 2013 09:50:59 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E686021F9E9A for ; Mon, 9 Sep 2013 09:50:29 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so3682343wiw.5 for ; Mon, 09 Sep 2013 09:50:29 -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=Fvn9KzcNTn1cHMocST/sNX9yh57Pb1k6EAQTES/8Qws=; b=Jf990w8NV0vyT/5whkWJ6cugPr9sOlM8TU7Q2Dic1rysSIfPwKjWMBPPiOY1UM/Mut G+MsffCScMhT8IM7eGyW3vg+zoPH4rUKonDQZbUkt5CdrqjiePVuGU+qsIkijgUoE8ZE jxN9dOVDYn4QARNJZEoeRx/9TjXWabpXATSCaCzqF8F28q9XRqGp8oWqsNYAgVqGq5OI jkCZFPw2oBBEAThY/oDZGPQLmo46fmD7Vdh7e7LGwCKj5BW+YZP6AhFZR+RQUJCwgKHp uRTjSxep71Gu8pBm8EafeOS+6nZLjUa+mkMjkpM73jb3fDa+8nIR1XmzntEBEPTXI0wk cYxw== MIME-Version: 1.0 X-Received: by 10.194.134.97 with SMTP id pj1mr1726537wjb.58.1378745429117; Mon, 09 Sep 2013 09:50:29 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Mon, 9 Sep 2013 09:50:29 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> <5225B1AF.7050906@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> Date: Mon, 9 Sep 2013 09:50:29 -0700 Message-ID: From: "cb.list6" To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 16:51:00 -0000 On Mon, Sep 9, 2013 at 9:36 AM, Hutton, Andrew wrote: > Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV= 6 which I assume it should. Specifically I am thinking that it needs to sta= te a requirement to support RFC6156 support "Traversal Using Relays around = NAT (TURN) Extension for IPv6". > > I am not sure how much we need to say about webrtc client procedures arou= nd RFC6156 and whether they should be included in the draft-ietf-rtcweb-tra= nsport or whether it is something we should add to our nat/firewall draft (= draft-hutton-rtcweb-nat-firewall-considerations). Any opinions on this? > +1 on covering IPv6 in the transport draft. I would specifically state that much of the challenges with NATs are resolved by preferring IPv6. I would also cover the use case of using TURN to bridge IPv6-only clients to communicate with IPv4 clients. It would also be wise to reference RFC6540 to underscore that IPv6 use is a BCP of the IETF CB > Regards > Andy > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Mon Sep 9 10:01:51 2013 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 6FE8711E819F for ; Mon, 9 Sep 2013 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sY9C9GjaPIE for ; Mon, 9 Sep 2013 10:01:32 -0700 (PDT) Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id B452B21F9D87 for ; Mon, 9 Sep 2013 10:01:30 -0700 (PDT) Received: from BLU169-W24 ([65.55.111.136]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 10:01:29 -0700 X-TMN: [ZAouUi/1wypA/3Vbp8WGzApkrjYSeoJ4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_72251298-e3a3-42af-90dd-d4acfa7eeea6_" From: Bernard Aboba To: cb.list6 , "Hutton, Andrew" Date: Mon, 9 Sep 2013 10:01:28 -0700 Importance: Normal In-Reply-To: References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com>, <5225B1AF.7050906@alvestrand.no>, <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net>, MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2013 17:01:29.0222 (UTC) FILETIME=[3A145A60:01CEAD7E] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 17:01:51 -0000 --_72251298-e3a3-42af-90dd-d4acfa7eeea6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I would specifically state that much of the challenges with NATs are > resolved by preferring IPv6. [BA] That isn't what we've seen in practice=2C since IPv6 addresses (parti= cularly tunnel addresses) may not be routable. So in practice=2C things see= m to work better if IPv4 addresses are preferred and in fact=2C government = profiles such as DISA UCR 2008 require the ability to configure an IPv4 pre= ference. =20 > I would also cover the use case of using TURN to bridge IPv6-only > clients to communicate with IPv4 clients. [BA] Yes=2C this is an important use case (and one that some ICE implementa= tions don't support very well). =20 > It would also be wise to reference RFC6540 to underscore that IPv6 use > is a BCP of the IETF. = --_72251298-e3a3-42af-90dd-d4acfa7eeea6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B I would specifically= state that much of the challenges with NATs are
>=3B resolved by pref= erring IPv6.
 =3B
[BA] That isn't what we've seen in pract= ice=2C since IPv6 addresses (particularly tunnel addresses) may not be rout= able. =3B
So in practice=2C things seem to work better if IPv= 4 addresses are preferred and in fact=2C government profiles such as DISA U= CR 2008 require the ability to configure an IPv4 preference.  =3B
=

>=3B I would also cover the use case of using TURN to bridge IPv= 6-only
>=3B clients to communicate with IPv4 clients.

[BA] Yes=2C this is an important use case (and one that some ICE i= mplementations don't support very well).  =3B

>=3B It w= ould also be wise to reference RFC6540 to underscore that IPv6 use
>= =3B is a BCP of the IETF.
= --_72251298-e3a3-42af-90dd-d4acfa7eeea6_-- From cb.list6@gmail.com Mon Sep 9 10:26:08 2013 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 2EA6611E8115 for ; Mon, 9 Sep 2013 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV9efbVpwdgd for ; Mon, 9 Sep 2013 10:26:07 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id E034721F9E2B for ; Mon, 9 Sep 2013 10:25:35 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so3736299wib.12 for ; Mon, 09 Sep 2013 10:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wVwtsxt5vWHmOjFsDn5s3sbqKzLJ+jc/hOPBmgerBcQ=; b=lxrLLdQMEKIsyPCpxiJeYYK6HPQZDduoePozbjYpDkX5/1j3kWI02hDTJYmqxJYX8/ sNAzYnISfosUUqtCssnSLvoeMIn3N7YtkEiocvIwD+W6lJFRENSGxEW6nzOaI0jyqvSa CdP4VsiV5NaaQGUcCxP/0VtgWwZELxPM5qzUF/0cu4BJwFa9ve+Ip3mWHM6mQ2Zi3lyt zuEG782DV0vgUgdiucnkdy0RjYE5Yoq6tRaUwJ3JHGXtEjXGZ7x/JdtYiN420BAEdmUj qXV1ub06DKu1CUFkkWtEPc7Cb8pojlnAXNRSDoiJocfqN04X8UJFnnU+JQBkuzvG/d5U P4Rg== MIME-Version: 1.0 X-Received: by 10.180.106.65 with SMTP id gs1mr8073652wib.34.1378747535071; Mon, 09 Sep 2013 10:25:35 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Mon, 9 Sep 2013 10:25:35 -0700 (PDT) In-Reply-To: References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com> <5225B1AF.7050906@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> Date: Mon, 9 Sep 2013 10:25:35 -0700 Message-ID: From: "cb.list6" To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 17:26:08 -0000 On Mon, Sep 9, 2013 at 10:01 AM, Bernard Aboba wrote: >> I would specifically state that much of the challenges with NATs are >> resolved by preferring IPv6. > > [BA] That isn't what we've seen in practice, since IPv6 addresses > (particularly tunnel addresses) may not be routable. > So in practice, things seem to work better if IPv4 addresses are preferred > and in fact, government profiles such as DISA UCR 2008 require the ability > to configure an IPv4 preference. > Is there a citation for this data point about IPv6 not working as well in production? I see the DISA thing as not particularly relevant to the Internet. That's one way to run a private network, with knobs to adjust. There used to be an issue with 6to4 and maybe Teredo, but i believe the data shows that this issue has largely been resolved http://www.google.com/intl/en/ipv6/statistics.html via host treatment of those tunnels as well as happy-eyeballs in browsers. I believe happy-eyeballs / RFC6555 would apply to WebRTC interactions equally well, since the signalling is over the standard HTTP/HTTPS calls. Maybe RFC6555 needs to be mentioned in the transport draft as well since it can be leveraged to mitigate the use of broken IPv6 connections. CB >> I would also cover the use case of using TURN to bridge IPv6-only >> clients to communicate with IPv4 clients. > > [BA] Yes, this is an important use case (and one that some ICE > implementations don't support very well). > >> It would also be wise to reference RFC6540 to underscore that IPv6 use >> is a BCP of the IETF. From bernard_aboba@hotmail.com Mon Sep 9 10:37:22 2013 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 2BFA921E813B for ; Mon, 9 Sep 2013 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpFmEkrKIsEy for ; Mon, 9 Sep 2013 10:37:17 -0700 (PDT) Received: from blu0-omc4-s7.blu0.hotmail.com (blu0-omc4-s7.blu0.hotmail.com [65.55.111.146]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9911E8118 for ; Mon, 9 Sep 2013 10:37:13 -0700 (PDT) Received: from BLU169-W140 ([65.55.111.135]) by blu0-omc4-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 10:37:13 -0700 X-TMN: [TinjasyT3lB3EbwFdsAPJ28ZwgI0BscX] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d80e08cb-6865-4bd2-92ad-a569bcc1bbf1_" From: Bernard Aboba To: cb.list6 Date: Mon, 9 Sep 2013 10:37:12 -0700 Importance: Normal In-Reply-To: References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com>, <5225B1AF.7050906@alvestrand.no>, <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2013 17:37:13.0353 (UTC) FILETIME=[3814C790:01CEAD83] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 09 Sep 2013 17:37:22 -0000 --_d80e08cb-6865-4bd2-92ad-a569bcc1bbf1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Is there a citation for this data point about IPv6 not working as well in= production?=20 [BA] At IETF 87 (and in several meetings prior to that)=2C we have had a di= scussion within the MMUSIC WG about "Happy Eyeballs for ICE" (draft-reddy-m= music-ice-happy-eyeballs):http://www.ietf.org/proceedings/87/slides/slides-= 87-mmusic-0.pdf > There used to be an issue with 6to4 and maybe Teredo=2C but i believe > the data shows that this issue has largely been resolved > http://www.google.com/intl/en/ipv6/statistics.html via host treatment > of those tunnels as well as happy-eyeballs in browsers. [BA] Those statistics do not relate to ICEv6 usage=2C and in particular=2C = they don't cover the range of behavior that we see in enterprise and carrie= r networks. As an example=2C in deployments we have encountered IPv6 NATs = and firewalls with a wide range of behavior=2C IPv6-only carrier networks w= here connectivity to IPv4 endpoints is needed=2C etc. =20 > I believe happy-eyeballs / RFC6555 would apply to WebRTC interactions > equally well=2C since the signalling is over the standard HTTP/HTTPS call= s. [BA] RFC 6555 doesn't directly apply to ICE=2C which is why we've been havi= ng a distinct "ICE Happy Eyeballs" discussion.=20 = --_d80e08cb-6865-4bd2-92ad-a569bcc1bbf1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Is there a citation = for this data point about IPv6 not working as well =3Bin production?&nb= sp=3B

[BA] At IETF 87 (and in several meetings pri= or to that)=2C we have had a discussion within the MMUSIC WG about "Happy E= yeballs for ICE" (draft-reddy-mmusic-ice-happy-eyeballs):

>=3B There used to be an issue with 6to4 = and maybe Teredo=2C but i believe
>=3B the data shows that this issue = has largely been resolved
>=3B http://www.google.com/intl/en/ipv6/stat= istics.html via host treatment
>=3B of those tunnels as well as happy-= eyeballs in browsers.

[BA] Those statistics do not= relate to ICEv6 usage=2C and in particular=2C they don't cover the range o= f behavior that we see in enterprise and carrier networks.  =3BAs an ex= ample=2C in deployments we have encountered IPv6 NATs and firewalls with a = wide range of behavior=2C IPv6-only carrier networks where connectivity to = IPv4 endpoints is needed=2C etc.  =3B

>=3B I= believe happy-eyeballs / RFC6555 would apply to WebRTC interactions
>= =3B equally well=2C since the signalling is over the standard HTTP/HTTPS&nb= sp=3Bcalls.

[BA] RFC 6555 doesn't directly apply t= o ICE=2C which is why we've been having a distinct "ICE Happy Eyeballs" dis= cussion. =3B

= --_d80e08cb-6865-4bd2-92ad-a569bcc1bbf1_-- From eckelcu@cisco.com Mon Sep 9 10:55:14 2013 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 2958821F9B08 for ; Mon, 9 Sep 2013 10:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uvm+LBcCX-t for ; Mon, 9 Sep 2013 10:55:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94921E805F for ; Mon, 9 Sep 2013 10:54:44 -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=1378749284; x=1379958884; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PurNt/2jnBmE6WT78ocOzEUvlYs+SC3YvnIGO15MGAg=; b=Eh5sArZGGHL8eDP2tFk1M/MH8mfX+yTWeuN1c0Lpix06hnbNzUm39TrT v18RFquOWQm4RU+6iEDjP0qaNd++vG821wYtrfL3GoRs1uxrVORsmaZmU ZmFTfw/RaNQMSDbSUPti4GtSDjuhjd98E3Kv3bdWu+KPA64Pg4tKOaP0E M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACUKLlKtJXG+/2dsb2JhbABbgwc4UcIYgSQWdIInAQQBAQEJEVEZBAEIIh0iDAsUEQIEARIIh3kBDMNKBASPSziDHYEAA4h9oF6DIIIq X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="257439843" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 09 Sep 2013 17:54:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r89HsgAd002470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 17:54:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 12:54:42 -0500 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOrTftfWmjdtHJBkSd9W7m/TxdPZm9j1qA Date: Mon, 9 Sep 2013 17:54:41 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882805C1A91A@xmb-aln-x08.cisco.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.44] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <668C118F9AD29649865DB73F74C5881C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 17:55:14 -0000 I support adoption of this draft as a WG item for the given milestone. Cheers, Charles On 9/9/13 1:36 AM, "Magnus Westerlund" wrote: >WG, > >This is a call for WG adoption of STUN Usage for Consent Freshness >(draft-muthu-behave-consent-freshness-04). This document defines a STUN >usage for consent freshness. As this requires no protocol extensions we >as intended users can define this usage in our WG. Such work also >matches our charter. The draft-ietf-rtcweb-security-arch-07 is >normatively dependent on this STUN usage. > >Document: >https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > >WG, please indicate your support or issues with adopting this document >as WG item with a proposed milestone: > >Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication >as proposed standard. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Mon Sep 9 11:04:28 2013 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 9854321E8082 for ; Mon, 9 Sep 2013 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8Lij3N2ghgY for ; Mon, 9 Sep 2013 11:04:28 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id EE87311E811F for ; Mon, 9 Sep 2013 11:04:27 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m14so5680231wgh.19 for ; Mon, 09 Sep 2013 11:04:27 -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=YnY1aAUrO9e7nbQcvIgR+nDiCj77HKMgbXDsKfbRYE4=; b=h4Nddd+ZIIIDBmH3eHp9jTz9XCbsAw0dLz0IPsYeKfwY+IxekZF5SZUCl9KZQKWm8h KA7auKHqFDuRCKqV3jIZjN3txCRIYMijgugNJK1pBsetOko3HSvlRuLddXnf4km4pJJK Ywt8bwu3DYBwYKzm3mkrEuE1yMb1X608D5RUYOzW51S+JC+xdFZhGTvzifzQ5bisRQ6T HDa0NNAWuH7MDmOQbjUAnXHm5iSd5lh0yK6BooE8Nopw3s89xArIqXiZHXrFYrN7NzLI YUNzhOdBT6mwJFQEODxsrUVi0o8fkKP/oUohzg5pwyVUW1dJIGqIZ2S66/kjPGJKbX+B xZtg== MIME-Version: 1.0 X-Received: by 10.180.187.2 with SMTP id fo2mr9384240wic.65.1378749867081; Mon, 09 Sep 2013 11:04:27 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 9 Sep 2013 11:04:27 -0700 (PDT) In-Reply-To: <522DBEB8.5090207@alvestrand.no> References: <522D88A8.3010209@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> <522DBEB8.5090207@alvestrand.no> Date: Mon, 9 Sep 2013 11:04:27 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?) 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, 09 Sep 2013 18:04:28 -0000 On 9 September 2013 05:27, Harald Alvestrand wrote: > Personal opinion: I think SRTCP is still unsuitable for consent freshness. > One reason (apart from any aspect that deals with security, on which I don't > want to comment) is that if one sets up a connection with only a data > channel, there will be no SSRCs to send SRTCP on. This is my opinion too. From martin.thomson@gmail.com Mon Sep 9 11:07:12 2013 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 A32E311E811F for ; Mon, 9 Sep 2013 11:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xyExWJ2HNRP for ; Mon, 9 Sep 2013 11:07:05 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5E21F9C9A for ; Mon, 9 Sep 2013 11:07:05 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so5606338wes.21 for ; Mon, 09 Sep 2013 11:06:56 -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=9XQpwNQFXqPyYDBr+tlQxcCAI2lDMlalgxVArrAn05s=; b=Wm8QLsJqGG2+RwOGClmwoc/lqF/jj6+RYXE7aKeNA1ts01e6IJAVFMQ0L5MarSHEnI No/hqXMOnetEPyRRHJFXzHRfB7v0Fbg+t6ggHwTGsqhIxX13OFHsnb/S65JpohnM6zYK LOK/9+Hyxm57Wg4OHX2D0ZZ+P49JX/jVbnSat2MS0EqOHGUVlPQvmR5D9/XF3oF9RzTR qJHnv3l57LjCqQ4Dy6TDmeX8f0jzmwzt4pR31D37Hmu5VlZNTuVphlGRBy/Nf6+2QcBd gbNe/2jq6PdK2r2DbUH3eAWvGIJyKqlAc0ympdRwy5vtL5LC0V2J0XahSRzXcGTOdudc 6Adg== MIME-Version: 1.0 X-Received: by 10.180.108.162 with SMTP id hl2mr1246791wib.14.1378750015440; Mon, 09 Sep 2013 11:06:55 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 9 Sep 2013 11:06:55 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C49B5F7@ESESSMB209.ericsson.se> References: <522D88A8.3010209@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> <522DBEB8.5090207@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C49B5F7@ESESSMB209.ericsson.se> Date: Mon, 9 Sep 2013 11:06:55 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?) 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, 09 Sep 2013 18:07:12 -0000 On 9 September 2013 05:44, Christer Holmberg wrote: > And, from a security perspective (the backward compatibility is a separate issue) the requirement to integrity protect the STUN binding requests are not affected by the SDES decision? Integrity protection prevents an on-path attacker who is ignorant of ICE credentials from artificially extending consent. That's a fairly restricted set. The whole SDES interaction with consent is pretty weak, if you ask me. From martin.thomson@gmail.com Mon Sep 9 11:19:52 2013 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 7B11E21E8152 for ; Mon, 9 Sep 2013 11:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wihEejxaYu9T for ; Mon, 9 Sep 2013 11:19:52 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7C21E813B for ; Mon, 9 Sep 2013 11:19:51 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so5785531wes.34 for ; Mon, 09 Sep 2013 11:19: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=j4TwqmtjTFA1uHZ8Zy2RLQJsk6uSstIC9bWpzi627Os=; b=JrvpJcPaxUznjZuJn4Oi1B5QT51cSGXpmbUkGJsvauR4CvVxPHWfGXkta66+e2YZrc 64+J/R6q2BP/UhPLlQLN/8U/GGqc6KKrx/UOB8U1g7FNymWbYVfPMSoG12Xu+EnJUF2Q 4IjNkVfGe8ejb4UDvbGK6AxSBBMQldJTBP55AnGdv0WHMt8rFmF0K/KCKjU1XCGtX7W/ +cw2aDszr4unWsqxn6SrkpsZNMy7nrlGEUNTiVBseHUs8UljDihScMZEEQ8RH8nU0Obg B1PejwjEc61SBNtAZbTrOxgUTKs9BHDhdj/fCPBrkK4uMkBTseofSpjny9G09xvTj2/q FfCQ== MIME-Version: 1.0 X-Received: by 10.180.187.2 with SMTP id fo2mr9430842wic.65.1378750790865; Mon, 09 Sep 2013 11:19:50 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 9 Sep 2013 11:19:50 -0700 (PDT) In-Reply-To: <522D88A8.3010209@ericsson.com> References: <522D88A8.3010209@ericsson.com> Date: Mon, 9 Sep 2013 11:19:50 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 18:19:52 -0000 On 9 September 2013 01:36, Magnus Westerlund wrote: > Document: > https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > > WG, please indicate your support or issues with adopting this document > as WG item with a proposed milestone: I think that we should adopt this draft, then fix it. The proposed algorithm is still quite confusingly specified. It also unnecessarily conflates liveness testing with consent. From gsalguei@cisco.com Mon Sep 9 12:01:54 2013 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 F28DA21F9D65 for ; Mon, 9 Sep 2013 12:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2W9USoYIgCv for ; Mon, 9 Sep 2013 12:01:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F121E81BC for ; Mon, 9 Sep 2013 12:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1864; q=dns/txt; s=iport; t=1378753303; x=1379962903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/O49HMUtqRBqZ95btuuIahcIBhsB3exQozSHekF71y0=; b=hsnIXJ1e9yDL1qFq8veUqNjz2FAUTFdOB9qixLGeRpFP2NgLg5FIb5TM k8AuTxbTy/far0w92Njlx/bc6QTgp4lqwbHu7gXz7wTNqBiUn5LkpCDXh OWWNIV+vrFt0jHtBm1H5GwDnEddO8lbnSXI3ViOB1w1As0GWAtPsRn9OE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEMaLlKtJV2b/2dsb2JhbABbgwc4RQzCGYEmFnSCJQEBAQMBAQEBCRFRCwUJAgIBCBgKHQcbDAsUEQIEDgUIh3QGDMMxBASPSQIxB4MdgQADiH2gXoMggio X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="257273552" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 09 Sep 2013 19:01:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r89J1gds014582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 19:01:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 14:01:42 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Charles Eckel (eckelcu)" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOrTfy2vTfAGghxU2pFK2ISu0DdZm+BLKAgAASuYA= Date: Mon, 9 Sep 2013 19:01:41 +0000 Message-ID: References: <92B7E61ADAC1BB4F941F943788C0882805C1A91A@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882805C1A91A@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.59] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4612AAE7FE742749855C3172E6E15AF5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 09 Sep 2013 19:01:54 -0000 +1 On Sep 9, 2013, at 1:54 PM, Charles Eckel (eckelcu) wro= te: > I support adoption of this draft as a WG item for the given milestone. >=20 > Cheers, > Charles >=20 > On 9/9/13 1:36 AM, "Magnus Westerlund" > wrote: >=20 >> WG, >>=20 >> This is a call for WG adoption of STUN Usage for Consent Freshness >> (draft-muthu-behave-consent-freshness-04). This document defines a STUN >> usage for consent freshness. As this requires no protocol extensions we >> as intended users can define this usage in our WG. Such work also >> matches our charter. The draft-ietf-rtcweb-security-arch-07 is >> normatively dependent on this STUN usage. >>=20 >> Document: >> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ >>=20 >> WG, please indicate your support or issues with adopting this document >> as WG item with a proposed milestone: >>=20 >> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication >> as proposed standard. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> 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 >=20 From victor.pascual.avila@gmail.com Mon Sep 9 20:57:42 2013 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 D139A21F9C8E for ; Mon, 9 Sep 2013 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-lh9U4IXZKg for ; Mon, 9 Sep 2013 20:57:41 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id EB0DB21F9C13 for ; Mon, 9 Sep 2013 20:57:40 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m14so6135201wgh.7 for ; Mon, 09 Sep 2013 20:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=ZA0t3rjKJYiGMYjJnTP2VSa/Fx6o8dfzcEhA8NmMhMo=; b=tkfxbL85swGPI0b4eelRLWz/Ybu7HJ16gVvwWWLJ1uzUvuHHW1kHiURqVs9/Jq1Wwh H456Rwm0efN3O2lZki6Mgmw+KiqMIRChL8hrdBRBHNtxT9pdOz7WvrHKIhLLBQ8P0JDT UdlnPmS345txou6I2MuwPGBj9shODHSSG3ZYmkiny5ZAaN52aCJhyTAL/0aLcMXD0syt vLOXzPgw6FQQw1MS+Asht8+aDg7cEzAx8s94+LQPtz1qTOjIt1cTLrSbYI6qkBXqT/L8 VNW1ajMVk2oT0f14oN6Zs9UMY9a/D7lqncjnYNjYv0TYM2lDKll4cvIUWle+xAdMckZZ OL7g== X-Received: by 10.180.81.71 with SMTP id y7mr7109983wix.63.1378785460003; Mon, 09 Sep 2013 20:57:40 -0700 (PDT) Received: from [192.168.0.10] (233.85-86-126.dynamic.clientes.euskaltel.es. [85.86.126.233]) by mx.google.com with ESMTPSA id w19sm483553wia.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 20:57:39 -0700 (PDT) References: <92B7E61ADAC1BB4F941F943788C0882805C1A91A@xmb-aln-x08.cisco.com> From: Victor Pascual Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (10B329) In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882805C1A91A@xmb-aln-x08.cisco.com> Message-Id: <42D97C8E-1305-4A57-82BA-0FF8E1A7E249@gmail.com> Date: Tue, 10 Sep 2013 05:57:37 +0200 To: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 10 Sep 2013 03:57:42 -0000 +1 On Sep 9, 2013, at 7:54 PM, "Charles Eckel (eckelcu)" wr= ote: > I support adoption of this draft as a WG item for the given milestone. >=20 > Cheers, > Charles >=20 > On 9/9/13 1:36 AM, "Magnus Westerlund" > wrote: >=20 >> WG, >>=20 >> This is a call for WG adoption of STUN Usage for Consent Freshness >> (draft-muthu-behave-consent-freshness-04). This document defines a STUN >> usage for consent freshness. As this requires no protocol extensions we >> as intended users can define this usage in our WG. Such work also >> matches our charter. The draft-ietf-rtcweb-security-arch-07 is >> normatively dependent on this STUN usage. >>=20 >> Document: >> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ >>=20 >> WG, please indicate your support or issues with adopting this document >> as WG item with a proposed milestone: >>=20 >> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication >> as proposed standard. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> 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 >> ---------------------------------------------------------------------- >>=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 tterriberry@mozilla.com Tue Sep 10 00:45:54 2013 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 848F311E8186 for ; Tue, 10 Sep 2013 00:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFQcFMflxNlD for ; Tue, 10 Sep 2013 00:45: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 47E7E11E817A for ; Tue, 10 Sep 2013 00:45:46 -0700 (PDT) Received: from [192.168.1.141] (host81-136-161-25.in-addr.btopenworld.com [81.136.161.25]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 24989F2264 for ; Tue, 10 Sep 2013 00:45:42 -0700 (PDT) Message-ID: <522ECE1F.7030901@mozilla.com> Date: Tue, 10 Sep 2013 00:45:35 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <522D88A8.3010209@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 10 Sep 2013 07:45:54 -0000 Martin Thomson wrote: > I think that we should adopt this draft, then fix it. The proposed +1 From victor.pascual.avila@gmail.com Tue Sep 10 06:47:39 2013 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 CD80511E81AC for ; Tue, 10 Sep 2013 06:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PK53susrHyE for ; Tue, 10 Sep 2013 06:47:39 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2897C11E816F for ; Tue, 10 Sep 2013 06:47:36 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ec20so6321164lab.0 for ; Tue, 10 Sep 2013 06:47:34 -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=/UZXlNvr5bUTViKXNT4ZPXp6rlYH8SpnwsG12bql0oU=; b=tcQxzk//W225vvpOBZsNfLhBufpRrBW1YkHWjVJ0ZrJES8K+jxDWVqxHwaguGBszK7 xQBFA8eVxlLSeeXLobY17giqELRzhvNnn2WIRN5qG+4Skps5hqQTGEJ1j/qWKrq9GCgL B5nYh7NCESudMw4v8wyeAmLMIwPw65OrQHJlE+QFoAG33iQq+FXaA2tVwqEMdkEUPQ4m h9ZH2bENR2WPhfG11vd4vRcTYa6FbpQMvgTDatSBeEM2lT7tVp795bvq8qpXIhXrd0DC blslWfF0nbJLnbf8ovUMwnnlmO5rI8IPZvCCOiL4+og75QtFHgcqhdbfhU5ch65xOtUt dxHw== MIME-Version: 1.0 X-Received: by 10.112.14.3 with SMTP id l3mr7010572lbc.27.1378820854427; Tue, 10 Sep 2013 06:47:34 -0700 (PDT) Received: by 10.114.68.135 with HTTP; Tue, 10 Sep 2013 06:47:34 -0700 (PDT) Date: Tue, 10 Sep 2013 15:47:34 +0200 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Plan for MTI video 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, 10 Sep 2013 13:47:39 -0000 Dear WG Chairs, What's the plan for the MTI video codec discussion? Are we planning to discuss this during our next meeting? Is there a reason to delay this decision? My apologies if this has already been discussed but could not find it in the archives. Thanks, -Victor From ekr@rtfm.com Tue Sep 10 07:16:56 2013 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 28AAD11E81B4 for ; Tue, 10 Sep 2013 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.727 X-Spam-Level: X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n9w190OWFQv for ; Tue, 10 Sep 2013 07:16:51 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id B66E521F8EB2 for ; Tue, 10 Sep 2013 07:16:46 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id 1so4212543qec.15 for ; Tue, 10 Sep 2013 07:16:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GVe390BnmY3LLKouQYUFWPyLj/k+kqshlYvfGWbXCaU=; b=eQQ3T/2Qs09kTxLWvkVNWUW5N4n5hYqGrJna3H3ZI+Jdj1WYolSraOl0zWZgynUxXs fwbfz45IH6lbNymoujOoZ8meyUuGppojbf5wsjkAgFpgabc45tkNR2MzuZChqR6zD38Z lMIDz38Rjf2g6SfvDAcizlWPp5j8yYlD42Fs2/8E6BBav5uY67CMsylN8UQGrZ8fMEj9 ESEsLeYx7Au+ZWdWbJZrnsD3CxcPgOU/dyayaUH4OlDYVjW0dONNKk6rh+PPfyuAOKR2 P7K3Zc92eJcyHmmKyHW9d2xgYU9ekBFfHF1vP7ySDVgOV1Z8pjQelvPJQI8XNpE4nogf nWtw== X-Gm-Message-State: ALoCoQkuXpfsXwUwAthmIBgG6jwOZOrNBmOG+fv9buuCEKL8/Ira/Ges4ypcaypftkpZ/WkvNAu/ X-Received: by 10.49.35.106 with SMTP id g10mr33193821qej.35.1378822605985; Tue, 10 Sep 2013 07:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.42.68 with HTTP; Tue, 10 Sep 2013 07:16:05 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <522ECE1F.7030901@mozilla.com> References: <522D88A8.3010209@ericsson.com> <522ECE1F.7030901@mozilla.com> From: Eric Rescorla Date: Tue, 10 Sep 2013 07:16:05 -0700 Message-ID: To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=047d7b6766f8a3948b04e6082723 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 10 Sep 2013 14:16:56 -0000 --047d7b6766f8a3948b04e6082723 Content-Type: text/plain; charset=ISO-8859-1 +1 On Tue, Sep 10, 2013 at 12:45 AM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Martin Thomson wrote: > >> I think that we should adopt this draft, then fix it. The proposed >> > > +1 > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7b6766f8a3948b04e6082723 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Tue, Sep 10, 2013 at 12:45 AM, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
Martin Thomson wrote:
I think that we should adopt this draft, then fix it. =A0The proposed

+1


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

--047d7b6766f8a3948b04e6082723-- From creslin@digium.com Tue Sep 10 07:59:21 2013 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 3274821E8053 for ; Tue, 10 Sep 2013 07:59:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp1P8DPmA2GQ for ; Tue, 10 Sep 2013 07:58:56 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3639C21E8051 for ; Tue, 10 Sep 2013 07:58:55 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so6400009lbi.32 for ; Tue, 10 Sep 2013 07:58:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SgbqR2T3MvtlKSOHWKmTccsLUb+j5/35gF8qyG9Bi+o=; b=aPQMqw+lHPu65G/phBe0nFOOES94dq9g1GJzErEYztaSh9RKTiXJJHA63k1xQ6p5Vm Rwn4WXuMnGbHbmoJAiphaBgCkKHC16zt3qURXD11LYz81iMiGSC5rkGpEF/2pC0biiDC ET6598O6YE7rrdr1egXHEphSBtFqwYJApHjiVUOGSxkJapy6kxa+w9txYZxevlEhwIrg dabYCY5XbSB4MgUZAfGeyJzw+LYzPXN3UPsd2PucPy71ymaOFaKq3kvnE0OcaOnd4KlZ /zO0JtFKqu4x1/7p5u8RxOdu4LPbVRwXh/B14Hxsk/3EAipOu8Sn750zPZi4FDku88+3 blZA== X-Gm-Message-State: ALoCoQk970Tj/luK8TDaEYTgMAKtKP02g1Knf/0IgOn59wqaH5WwZxRWWdBmqIbhjzkgS1aAjN+t MIME-Version: 1.0 X-Received: by 10.112.29.17 with SMTP id f17mr1548675lbh.45.1378825123043; Tue, 10 Sep 2013 07:58:43 -0700 (PDT) Received: by 10.112.132.102 with HTTP; Tue, 10 Sep 2013 07:58:42 -0700 (PDT) In-Reply-To: <522A56BF.7050509@alvestrand.no> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <522A23C1.2030900@mozilla.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527148@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D527209@xmb-rcd-x14.cisco.com> <522A56BF.7050509@alvestrand.no> Date: Tue, 10 Sep 2013 09:58:42 -0500 Message-ID: From: Matt Fredrickson To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1133c690aaac8e04e608bd76 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Tue, 10 Sep 2013 14:59:21 -0000 --001a1133c690aaac8e04e608bd76 Content-Type: text/plain; charset=ISO-8859-1 Coming from an implementor's perspective (typically), and having read quite a few RFCs, I strongly concur with your statement, about using SHOULD in an RFC requiring spelling out the circumstances where it's reasonable to ignore. As Martin said, and I agree, usually implementors take liberties to ignore the "SHOULDs, RECOMMENDEDs, MAYs, and OPTIONALs" until they get bit by something (usually in interop). Then they curse the spec for using non mandatory language for whatever bit them :-) Matthew Fredrickson On Fri, Sep 6, 2013 at 5:27 PM, Harald Alvestrand wrote: > On 09/06/2013 11:42 PM, Mo Zanaty (mzanaty) wrote: > >> True. The same can be said about every SHOULD, but we still bother to >> specify it. >> Maybe we should update RFC 2119 to state: >> >> Obey: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" >> Ignore: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" >> > > At the time 2119 was written (I remember discussing this with Scott > Bradner several times), the intent of the text for "SHOULD" was "you'd > better do this if you don't have a real good reason why it's not a > reasonable thing to do in your particular case". > > Quoth: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Of course, people who don't want to cover all the SHOULDs have pushed > towards interpreting it as "weak recommendation that we can ignore if we > feel like it", but that wasn't the original intent of 2119, and some of us > still want to have that word available for use in the stronger meaning. > > At one time there was push towards saying that "if you write SHOULD in an > RFC, you need to spell out the circumstances where it'll be reasonable to > ignore it - otherwise, write MUST or MAY". That push has petered out at > this time, but I felt sympathetic to the idea. > > That's why I'm so reluctant to use the word in cases where I think a large > part of the implementors are going to ignore it, and where (in my opinion) > no great harm comes to interoperability when they do. > > But this instance not something I storm barricades over; if the consensus > of the WG is to use "RECOMMENDED" rather than "recommended", I'll note that > I'm the rough part of the consensus, and live with it. > > > > >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.**com >> ] >> Sent: Friday, September 06, 2013 4:38 PM >> To: Mo Zanaty (mzanaty) >> Cc: Jean-Marc Valin; Bo Burman; rtcweb@ietf.org >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >> >> On 6 September 2013 13:28, Mo Zanaty (mzanaty) wrote: >> >>> If the will is hostile to other codecs, this text won't matter. >>> >> The natural disposition of the implementer is hostility toward more >> work, so I don't see the text making much difference either way. >> ______________________________**_________________ >> 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 > --001a1133c690aaac8e04e608bd76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Coming from an implementor's perspective (typically), = and having read quite a few RFCs, I strongly concur with your statement, ab= out using SHOULD in an RFC requiring spelling out the circumstances where i= t's reasonable to ignore.

As Martin said, and I agree, usually implementors take liber= ties to ignore the "SHOULDs, RECOMMENDEDs, MAYs, and OPTIONALs" u= ntil they get bit by something (usually in interop). =A0Then they curse the= spec for using non mandatory language for whatever bit them :-)

Matthew Fredrickson



On Fri, Sep 6, 2013 at= 5:27 PM, Harald Alvestrand <harald@alvestrand.no> wrote:=
On 09/06/2013 11:42 PM, Mo= Zanaty (mzanaty) wrote:
True. The same can be said about every SHOULD, but we still bother to speci= fy it.
Maybe we should update RFC 2119 to state:

Obey: "MUST", "MUST NOT", "REQUIRED", "S= HALL", "SHALL NOT"
Ignore: "SHOULD", "SHOULD NOT", "RECOMMENDED"= , "MAY", "OPTIONAL"

At the time 2119 was written (I remember discussing this with Scott Bradner= several times), the intent of the text for "SHOULD" was "yo= u'd better do this if you don't have a real good reason why it'= s not a reasonable thing to do in your particular case".

Quoth:

3. SHOULD =A0 This word, or the adjective "RECOMMENDED", mean tha= t there
=A0 =A0may exist valid reasons in particular circumstances to ignore a
=A0 =A0particular item, but the full implications must be understood and =A0 =A0carefully weighed before choosing a different course.

Of course, people who don't want to cover all the SHOULDs have pushed t= owards interpreting it as "weak recommendation that we can ignore if w= e feel like it", but that wasn't the original intent of 2119, and = some of us still want to have that word available for use in the stronger m= eaning.

At one time there was push towards saying that "if you write SHOULD in= an RFC, you need to spell out the circumstances where it'll be reasona= ble to ignore it - otherwise, write MUST or MAY". That push has petere= d out at this time, but I felt sympathetic to the idea.

That's why I'm so reluctant to use the word in cases where I think = a large part of the implementors are going to ignore it, and where (in my o= pinion) no great harm comes to interoperability when they do.

But this instance not something I storm barricades over; if the consensus o= f the WG is to use "RECOMMENDED" rather than "recommended&qu= ot;, I'll note that I'm the rough part of the consensus, and live w= ith it.




-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Friday, September 06, 2013 4:38 PM
To: Mo Zanaty (mzanaty)
Cc: Jean-Marc Valin; Bo Burman; rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

On 6 September 2013 13:28, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
If the will is hostile to other codecs, this text won't matter.
The natural disposition of the implementer is hostility toward more
work, so I don't see the text making much difference either way.
_______________________________________________
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

--001a1133c690aaac8e04e608bd76-- From creslin@digium.com Tue Sep 10 08:02:12 2013 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 55AA121E80CF for ; Tue, 10 Sep 2013 08:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyseHB423msa for ; Tue, 10 Sep 2013 08:02:07 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF721E811D for ; Tue, 10 Sep 2013 08:01:52 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id p5so6156026lbi.8 for ; Tue, 10 Sep 2013 08:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZuaWJEJc+sOekxxYU7Ylbnx00eUYYA6f3UNUIHop7+g=; b=UwCLsD88q+cZqtNWFdEkKdHu2BUVckfk5nJlBWf2hDI++PCCQxMfK69bqUoFpmSITB GbhcyP4cnclBSysFGJnYvA7ALnCCyirkHLB187T82acOLM5U/ISyulBMIGyy/8p8cZzt e9x5QbdpSLIRHQmWNVSlOkfyDr/1+OA2mw6o6BvCR+JSSctVPdwPVUgLcxnL7FUjRqcA BSJrTjxZQTkTvlXm2PPX93zXm0PoyN+ueDufdGEGpBs7zzRp3G+OWbmH3jhmgC5r/FbZ be1xzZouLyDiQzGIuulArCnAlY6j9ioU+nemfxTuAIqh48S+hV39ecfOwn3ahi2/wZQl rDFg== X-Gm-Message-State: ALoCoQm3utYHUWIaLAbY59x/5PTc292Ul019kq7yz8ceJBaW5Wu/HNeYZgJ4zPRKS58zQ9rsdwvY MIME-Version: 1.0 X-Received: by 10.112.189.162 with SMTP id gj2mr762437lbc.53.1378825307394; Tue, 10 Sep 2013 08:01:47 -0700 (PDT) Received: by 10.112.132.102 with HTTP; Tue, 10 Sep 2013 08:01:47 -0700 (PDT) In-Reply-To: References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> Date: Tue, 10 Sep 2013 10:01:47 -0500 Message-ID: From: Matt Fredrickson To: Bo Burman Content-Type: multipart/alternative; boundary=001a11c3799ca7a69d04e608c824 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Tue, 10 Sep 2013 15:02:12 -0000 --001a11c3799ca7a69d04e608c824 Content-Type: text/plain; charset=ISO-8859-1 I support it as well. Matthew Fredrickson On Thu, Sep 5, 2013 at 8:05 AM, Bo Burman wrote: > I also support it. > /Bo > > > -----Original Message----- > > From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto: > uwe.rauschenbach@nsn.com] > > Sent: den 5 september 2013 12:14 > > To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org > > Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > I support this proposal. > > > > Kind regards, > > Uwe > > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of ext Mo Zanaty (mzanaty) > > > Sent: Wednesday, September 04, 2013 10:03 PM > > > To: Bo Burman; rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > I support the proposed text addition. But rather than adding at the > > > end of section 3, replace the beginning of section 3 as below. > > > > > > OLD: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > While this section specifies the codecs that will be mandated for > > > all > > > WebRTC client implementations, it leaves the question of supporting > > > additional codecs to the will of the implementer. > > > > > > NEW: > > > To ensure a baseline level of interoperability between WebRTC > > > clients, a minimum set of required codecs are specified below. > > > If other suitable audio codecs are available to the browser to use, > > > it is RECOMMENDED that they are also included in the offer in order > > > to maximize the possibility to establish the session without the > > > need > > > for audio transcoding. > > > > > > Mo > > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Bo Burman > > > Sent: Tuesday, August 27, 2013 10:53 AM > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > Based on the previous discussion thread http://www.ietf.org/mail- > > > archive/web/rtcweb/current/msg08501.html, I believe there is support > > > to add some text into this document. > > > > > > I thus propose to add the following text at the end of section 3: > > > > > > If other suitable audio codecs are available to the browser to use, it > > > is RECOMMENDED that they are also included in the offer in order to > > > maximize the possibility to establish the session without the need for > > > audio transcoding > > > > > > Cheers, > > > Bo > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > > > Sent: den 2 augusti 2013 18:30 > > > > To: i-d-announce@ietf.org > > > > Cc: rtcweb@ietf.org > > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Real-Time Communication in WEB- > > > browsers Working Group of the IETF. > > > > > > > > Title : WebRTC Audio Codec and Processing Requirements > > > > Author(s) : Jean-Marc Valin > > > > Cary Bran > > > > Filename : draft-ietf-rtcweb-audio-02.txt > > > > Pages : 6 > > > > Date : 2013-08-02 > > > > > > > > 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-02 > > > > > > > > A diff from the previous version is available at: > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are > > > > available at tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > > > 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 > --001a11c3799ca7a69d04e608c824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support it as well.

Matthew Fredrickson


On Thu, Se= p 5, 2013 at 8:05 AM, Bo Burman <bo.burman@ericsson.com> wrote:
I also support it.
/Bo

> -----Original Message-----
> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]
> Sent: den 5 september 2013 12:14
> To: ext Mo Zanaty (mzanaty); Bo Burman; rtcweb@ietf.org
> Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt
>
> I support this proposal.
>
> Kind regards,
> Uwe
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of ext Mo Zanaty (mzanaty)
> > Sent: Wednesday, September 04, 2013 10:03 PM
> > To: Bo Burman; rtcweb@ietf.org=
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > I support the proposed text addition. But rather than adding at t= he
> > end of section 3, replace the beginning of section 3 as below. > >
> > OLD:
> > =A0 =A0To ensure a baseline level of interoperability between Web= RTC
> > =A0 =A0clients, a minimum set of required codecs are specified be= low.
> > =A0 =A0While this section specifies the codecs that will be manda= ted for
> > all
> > =A0 =A0WebRTC client implementations, it leaves the question of s= upporting
> > =A0 =A0additional codecs to the will of the implementer.
> >
> > NEW:
> > =A0 =A0To ensure a baseline level of interoperability between Web= RTC
> > =A0 =A0clients, a minimum set of required codecs are specified be= low.
> > =A0 =A0If other suitable audio codecs are available to the browse= r to use,
> > =A0 =A0it is RECOMMENDED that they are also included in the offer= in order
> > =A0 =A0to maximize the possibility to establish the session witho= ut the
> > need
> > =A0 =A0for audio transcoding.
> >
> > Mo
> >
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of Bo Burman
> > Sent: Tuesday, August 27, 2013 10:53 AM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt<= br> > >
> > Based on the previous discussion thread http://www.ietf.org/mail-
> > archive/web/rtcweb/current/msg08501.html, I believe there is supp= ort
> > to add some text into this document.
> >
> > I thus propose to add the following text at the end of section 3:=
> >
> > If other suitable audio codecs are available to the browser to us= e, it
> > is RECOMMENDED that they are also included in the offer in order = to
> > maximize the possibility to establish the session without the nee= d for
> > audio transcoding
> >
> > Cheers,
> > Bo
> >
> > > -----Original Message-----
> > > From: i-d-a= nnounce-bounces@ietf.org [mailto:i-d-a= nnounce-
> > bounces@ietf.org] On Beha= lf Of internet-drafts@ietf.org<= /a>
> > > Sent: den 2 augusti 2013 18:30
> > > To: i-d-announce@ie= tf.org
> > > Cc: rtcweb@ietf.org > > > Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-= Drafts
> > directories.
> > > =A0This draft is a work item of the Real-Time Communication = in WEB-
> > browsers Working Group of the IETF.
> > >
> > > =A0 Title =A0 =A0 =A0 =A0 =A0 : WebRTC Audio Codec and Proce= ssing Requirements
> > > =A0 Author(s) =A0 =A0 =A0 : Jean-Marc Valin
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cary Bra= n
> > > =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-rtcweb-audio-02.txt=
> > > =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6
> > > =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-02
> > >
> > > Abstract:
> > > =A0 =A0This document outlines the audio codec and processing= requirements
> > > =A0 =A0for WebRTC client application and endpoint devices. > > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-rtcw= eb-audio
> > >
> > > There's also a htmlized version available at:
> > > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-= 02
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-rtcweb-audio-02
> > >
> > >
> > > Please note that it may take a couple of minutes from the ti= me of
> > submission until the htmlized version and diff are
> > > available at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce@ietf.o= rg
> > > 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
> > _______________________________________________
> > 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

--001a11c3799ca7a69d04e608c824-- From jmvalin@mozilla.com Tue Sep 10 09:26:58 2013 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 EEF4A21E808E for ; Tue, 10 Sep 2013 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eor22ZqwUmuF for ; Tue, 10 Sep 2013 09:26:51 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id A270121E80F7 for ; Tue, 10 Sep 2013 09:26:51 -0700 (PDT) Received: from [192.168.1.14] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 391A4F26E3; Tue, 10 Sep 2013 09:26:50 -0700 (PDT) Message-ID: <522F4836.6030001@mozilla.com> Date: Tue, 10 Sep 2013 12:26:30 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Tue, 10 Sep 2013 16:26:58 -0000 > To ensure a baseline level of interoperability between WebRTC > clients, a minimum set of required codecs are specified below. > If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the need > for audio transcoding. Let's look at the practical effect here, assuming people were to actually follow such a recommendation. The only audio codecs that are implemented in browsers but not available for WebRTC are the ones used for HTML5. According to http://html5test.com/ these codecs are Vorbis, MP3, AAC, and uncompressed PCM. These are the codecs that would be recommended under such text. None of them is really ideal for interactive audio, none of them is implemented in old phones AFAIK, but all of them would require time and effort to add to a browser's RTP stack. I really don't see the point here. Jean-Marc From roman@telurix.com Tue Sep 10 09:54:49 2013 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 E0BEB21E8178 for ; Tue, 10 Sep 2013 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODjgjM1WPpsq for ; Tue, 10 Sep 2013 09:54:45 -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 DAFCD21E815F for ; Tue, 10 Sep 2013 09:54:44 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hn9so1017081wib.17 for ; Tue, 10 Sep 2013 09:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y419gDRNdm+JQecwpPT/g1AzWMzasyfaEp5duc55na4=; b=izSeZahAwqdw8o8eNpJqTkYcxk8FHlbV9VEgNELV58+Rspys2KNtbVLJ+eIokPmmyi 8qN4IwyyNoXcNYuf4U1BXSJ8N52eIjEl1P1agFivkrwDNulnWgi3NVJFp5Os3QpPbNcq CgZ1JU6xGhBtoW8VmG1sgZ4/TtdNrN9TFvQKLs7+yFoOJX9rBNCu3wGJ9yRMEjUGbhuF nzvZdUCLY1DLk9gxpJ/irKYnMLBtDKANaeM6myNVO319F+Szj6QDUyZ9Kg2xip3IgAZ4 FcpOSNWTVO5aD/q0P0xoLL4kLhBAf5KTkccZO1rX5Z3l+GfD4m6DcmErRQ5QjL+Pq+60 vlBw== X-Gm-Message-State: ALoCoQlhtdac5AqYLjtdbpCxrsZ3TIa+2LProYTf+pdSqwHmFnykz2j0PvZFBpd0u+ZjvddkT7e9 X-Received: by 10.194.9.33 with SMTP id w1mr2634836wja.47.1378832083937; Tue, 10 Sep 2013 09:54:43 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [2a00:1450:400c:c00::236]) by mx.google.com with ESMTPSA id ey2sm4812854wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 09:54:43 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e11so5897785wgh.9 for ; Tue, 10 Sep 2013 09:54:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.222.2 with SMTP id qi2mr18533854wjc.14.1378832082507; Tue, 10 Sep 2013 09:54:42 -0700 (PDT) Received: by 10.216.26.1 with HTTP; Tue, 10 Sep 2013 09:54:42 -0700 (PDT) In-Reply-To: <522F4836.6030001@mozilla.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> <522F4836.6030001@mozilla.com> Date: Tue, 10 Sep 2013 12:54:42 -0400 Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a11c278147ba2a304e60a5c9a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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: Tue, 10 Sep 2013 16:54:50 -0000 --001a11c278147ba2a304e60a5c9a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 12:26 PM, Jean-Marc Valin wrote: > > To ensure a baseline level of interoperability between WebRTC > > clients, a minimum set of required codecs are specified below. > > If other suitable audio codecs are available to the browser to use, > > it is RECOMMENDED that they are also included in the offer in order > > to maximize the possibility to establish the session without the need > > for audio transcoding. > > Let's look at the practical effect here, assuming people were to > actually follow such a recommendation. The only audio codecs that are > implemented in browsers but not available for WebRTC are the ones used > for HTML5. According to http://html5test.com/ these codecs are Vorbis, > MP3, AAC, and uncompressed PCM. These are the codecs that would be > recommended under such text. None of them is really ideal for > interactive audio, none of them is implemented in old phones AFAIK, but > all of them would require time and effort to add to a browser's RTP > stack. I really don't see the point here. > > My biggest problem with the recommendation text is "other suitable audio codecs are available to the browser to use". Jean-Marc's comment underlines the problem. His interpretation is that this refers to codecs already implemented in the browser. Another interpretation is that this refers to codecs already implemented in the underlying OS or platform, such as AMR-WB or H.264. Yet another interpretation implies codecs with no associated patents, such as G.722 or G.726. Yet another interpretation is that implies codecs with patent licenses which allows free implementation such as iLBC or iSAC. What is the intent here? With so many interpretations this language is completely useless. I think original intent was to encourage browser implementers to add support for G.722, AMR and AMR-WB if available in underlying platform, and H.264, if available in underlying platform or browser. In this regards this language fails completely. Don't you think it would be better to state exactly what the intent is and provide the language when implementation of each of those codecs is not required (meaning if additional license fees will need to be paid or due to incompatible licensing policy). _____________ Roman Shpount --001a11c278147ba2a304e60a5c9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 10, 2013 at 12:26 PM, Jean-Marc Valin <jmvalin@mozilla.com> wrote:
> To= ensure a baseline level of interoperability between WebRTC
> clients, a minimum set of required codecs are specified below.
> If other suitable audio codecs are available to the browser to use, > it is RECOMMENDED that they are also included in the offer in order > to maximize the possibility to establish the session without the need<= br> > for audio transcoding.

Let's look at the practical effect here, assuming people were to<= br> actually follow such a recommendation. The only audio codecs that are
implemented in browsers but not available for WebRTC are the ones used
for HTML5. According to http://html5test.com/ these codecs are Vorbis,
MP3, AAC, and uncompressed PCM. These are the codecs that would be
recommended under such text. None of them is really ideal for
interactive audio, none of them is implemented in old phones AFAIK, but
all of them would require time and effort to add to a browser's RTP
stack. I really don't see the point here.


My biggest problem with the recommendation text is "other suita= ble audio codecs are available to the browser to use". Jean-Marc's= comment underlines the problem. His interpretation is that this refers to = codecs already implemented in the browser. Another interpretation is that t= his refers to codecs already implemented in the underlying OS or platform, = such as AMR-WB or H.264. Yet another interpretation implies codecs with no = associated patents, such as G.722 or G.726. Yet another interpretation is t= hat implies codecs with patent licenses which allows free implementation su= ch as iLBC or iSAC. What is the intent here? With so many interpretations t= his language is completely useless.

I think original intent was to encoura= ge browser implementers to add support for G.722, AMR and AMR-WB if availab= le in underlying platform, and H.264, if available in underlying platform o= r browser. In this regards this language fails completely. Don't you th= ink it would be better to state exactly what the intent is and provide the = language when implementation of each of those codecs is not required (meani= ng if additional license fees will need to be paid or due to incompatible l= icensing policy).
_____________
Roman Shpount

--001a11c278147ba2a304e60a5c9a-- From sanjay.mishra@verizon.com Tue Sep 10 12:08:37 2013 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 538BF21F84D9 for ; Tue, 10 Sep 2013 12:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d92llDRLWjUN for ; Tue, 10 Sep 2013 12:08:31 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6290421F9A61 for ; Tue, 10 Sep 2013 12:08:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 10 Sep 2013 19:08:28 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208";a="545109181" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 10 Sep 2013 19:08:27 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Tue, 10 Sep 2013 15:08:27 -0400 To: "mperumal@cisco.com" , "dwing@cisco.com" , "rmohanr@cisco.com" , "tireddy@cisco.com" Date: Tue, 10 Sep 2013 15:08:26 -0400 Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: Ac6tN+qfR6vXQELAQEiGliH2MY4jagBGN0NQ Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C79869199@FHDP1LUMXC7V23.us.one.verizon.com> References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 10 Sep 2013 19:08:37 -0000 Muthu et al --=20 In the abstract, second paragraph, the text states "how" a WebRTC browser c= an verify peer consent and as I read through the rest of the document I als= o understood "why" this is needed. So, just a knit pick, it may be clear to= the reader if the statement also includes why within the body of the Abstr= act. One minor typo in section 7. Please change "in-intended" to "un-intended". Thanks Sanjay -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: Monday, September 09, 2013 4:37 AM To: rtcweb@ietf.org Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-m= uthu-behave-consent-freshness-04). This document defines a STUN usage for c= onsent freshness. As this requires no protocol extensions we as intended us= ers can define this usage in our WG. Such work also matches our charter. Th= e draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN = usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as W= G item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as p= roposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Tue Sep 10 13:33:27 2013 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 5B6A511E811B for ; Tue, 10 Sep 2013 13:33:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai+YmZ8Vb4ra for ; Tue, 10 Sep 2013 13:33:22 -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 E32CE21E8094 for ; Tue, 10 Sep 2013 13:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5353; q=dns/txt; s=iport; t=1378845202; x=1380054802; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=jFnyyjnUAy8MiKOBmJv430+/4xUGhSiid4zf59qWelY=; b=eZ89DMSx8Yyx0AsdNGRr53PYl1K08lCBSJib/AgdWNApXQRwgMMGHkCo LykkBHNLS28F7vR4G8WbVl+Chlf/oEdTePZM/uJvQxydc8jsFbNHthsU3 GF6gycc7KfxUTBY0ePv9HTUndOCwj73cEGVl3yZVVvRfmavWhU4oEYcP9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAJ2BL1KrRDoH/2dsb2JhbABbgkNEOLBgklCBJhZ0giUBAQECAQEBAQFrCxALBEInMAYTCYdnAwkFDcMpjHCCaweDHYEAA4k2jFiBaIw7hTCDQBw X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208,217";a="91547677" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 10 Sep 2013 20:33:13 +0000 Received: from dhcp-10-155-84-136.cisco.com (dhcp-10-155-84-136.cisco.com [10.155.84.136]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8AKWlHC020665; Tue, 10 Sep 2013 20:33:13 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_970D3A7B-7DA7-431D-B846-4DDF881D6F30" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Tue, 10 Sep 2013 13:33:29 -0700 Message-Id: References: <522D88A8.3010209@ericsson.com>, <7594FB04B1934943A5C02806D1A2204B1C49B5A1@ESESSMB209.ericsson.se> To: Bernard Aboba X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness vs. circuit breakers 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, 10 Sep 2013 20:33:27 -0000 --Apple-Mail=_970D3A7B-7DA7-431D-B846-4DDF881D6F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 9, 2013, at 8:45 AM, Bernard Aboba = wrote: >=20 > Christer said:=20 >=20 > "Now, as we have decided to not use SDES, I guess that can be = removed." >=20 > [BA] Actually, I believe that a sentence or two describing why the = needs of consent freshness are not met by mechanisms such as SRTCP is = worth keeping, and possibly should even be expanded upon. One reason is = that we also have the "circuit breakers" mechanism which *does* rely (in = part) on SRTCP. =20 >=20 > Christer said:=20 >=20 > "But, based on that, I'd just like to verify whether there is still a = need for the draft :)" >=20 > [BA] I do think that the draft is still necessary, even without = SDES/SRTP. The usage of ICE for consent seems to me to be less = susceptible to a variety of issues than a dependency on SRTCP might be.=20= >=20 > However, I am concerned about the interaction between circuit breakers = and consent freshness. At IETF 87, we heard that the circuit breakers = mechanism could fire even when the overall loss rate was quite low, due = to burst losses. That shouldn't be true of consent, since loss of = consent requires up to 30 consecutive losses over a 15 second period. = However, it would appear to me that the current circuit breakers = algorithms will cause media sending to be curtailed prior to loss of = consent in many cases. =20 Yes, consent needs to avoid the same pitfalls that were explained for = circuit breakers. =20 (For others that might be interested, the AVT presentation describing = the research on circuit breakers is at = http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf.) -d >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_970D3A7B-7DA7-431D-B846-4DDF881D6F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bernard_aboba@hotmail.com>= ; wrote:


Christer = said: 

"Now, as we have decided to = not use SDES, I guess that can be = removed."

[BA] Actually, I believe that a = sentence or two describing why the needs of consent freshness are not = met by mechanisms such as SRTCP is worth keeping, and possibly should = even be expanded upon.  One reason is that we also have the = "circuit breakers" mechanism which *does* rely (in part) on SRTCP. =   

Christer = said: 

"But, based on that, I'd just like = to verify whether there is still a need for the draft = :)"

[BA] I do think that the draft is still = necessary, even without SDES/SRTP.   The usage of ICE for consent = seems to me to be less susceptible to a variety of issues than a = dependency on SRTCP might be. 

However, I = am concerned about the interaction between circuit breakers and consent = freshness.  At IETF 87, we heard that the circuit breakers = mechanism could fire even when the overall loss rate was quite low, due = to burst losses.  That shouldn't be true of consent, since loss of = consent requires up to 30 consecutive losses over a 15 second period. =  However, it would appear to me that the current circuit breakers = algorithms will cause media sending to be curtailed prior to loss of = consent in many cases. =  

Y= es, consent needs to avoid the same pitfalls that were explained for = circuit breakers.  

(For others that might = be interested, the AVT presentation describing the research on circuit = breakers is at http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf.)

-d



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

= --Apple-Mail=_970D3A7B-7DA7-431D-B846-4DDF881D6F30-- From mperumal@cisco.com Tue Sep 10 20:51:34 2013 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 D19D721F9027 for ; Tue, 10 Sep 2013 20:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSIEsfUveClg for ; Tue, 10 Sep 2013 20:51:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A8FFF11E810D for ; Tue, 10 Sep 2013 20:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3222; q=dns/txt; s=iport; t=1378871489; x=1380081089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AFeEZ8C5cbYk+xGr7guD81LrL9ejSd76RhWQIAWfR9I=; b=ZJ7VjNYcgA9xGx4pxP9WbRLwpWQpL1RFjx60LLL/a9f1zvVqC8n1ooIk gFnm3V15+UYhmASuh6sRRWBt8rTVtW1AQPFSA7l/C0S+F0CGzTxjGOzVF IevQs5ku+uh69USG8zH87XMtJVr+z56b5MwsS8pFecg8WDIt2esYdnAkV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIXnL1KtJV2a/2dsb2JhbABbgwc4UcJmgR8WdIIlAQEBBAEBAQkRUQsMAgICAQgRBAEBCx0HGwwLFAkIAQEEAQ0FCIdoAw8MwnUEBIx0gj0xBwaDF4EAA4h+oGyDIIIq X-IronPort-AV: E=Sophos;i="4.90,881,1371081600"; d="scan'208";a="257943822" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Sep 2013 03:51:29 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8B3pTvw022623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Sep 2013 03:51:29 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.35]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 22:51:28 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Mishra, Sanjay" , "Dan Wing (dwing)" , "Ram Mohan R (rmohanr)" , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: Ac6tN+qfR6vXQELAQEiGliH2MY4jagBGN0NQABQuU4A= Date: Wed, 11 Sep 2013 03:51:28 +0000 Message-ID: References: <522D88A8.3010209@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C79869199@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C79869199@FHDP1LUMXC7V23.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 11 Sep 2013 03:51:34 -0000 |In the abstract, second paragraph, the text states "how" a WebRTC=20 |browser can verify peer consent and as I read through the rest of=20 |the document I also understood "why" this is needed. So, just a knit |pick, it may be clear to the reader if the statement also includes=20 |why within the body of the Abstract. The "why" part is mentioned in the first paragraph of the abstract: Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. Are you suggesting expanding this? The abstract needs to be concise, howeve= r. |One minor typo in section 7. Please change "in-intended" to "un-intended". Will fix it. Thanks for the review.. Muthu=20 |-----Original Message----- |From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] |Sent: Wednesday, September 11, 2013 12:38 AM |To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing); Ram Mohan R (rm= ohanr); Tirumaleswar Reddy |(tireddy) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness? | |Muthu et al -- | | |In the abstract, second paragraph, the text states "how" a WebRTC browser = can verify peer consent and |as I read through the rest of the document I also understood "why" this is= needed. So, just a knit |pick, it may be clear to the reader if the statement also includes why wit= hin the body of the |Abstract. | |One minor typo in section 7. Please change "in-intended" to "un-intended". | |Thanks |Sanjay | |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Magnus Westerlund |Sent: Monday, September 09, 2013 4:37 AM |To: rtcweb@ietf.org |Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? | |WG, | |This is a call for WG adoption of STUN Usage for Consent Freshness (draft-= muthu-behave-consent- |freshness-04). This document defines a STUN usage for consent freshness. A= s this requires no protocol |extensions we as intended users can define this usage in our WG. Such work= also matches our charter. |The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this ST= UN usage. | |Document: |https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ | |WG, please indicate your support or issues with adopting this document as = WG item with a proposed |milestone: | |Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as = proposed standard. | |Cheers | |Magnus Westerlund | |---------------------------------------------------------------------- |Multimedia Technologies, Ericsson Research EAB/TVM |---------------------------------------------------------------------- |Ericsson AB | Phone +46 10 7148287 |F=E4r=F6gatan 6 | Mobile +46 73 0949079 |SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com |---------------------------------------------------------------------- | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Tue Sep 10 22:59:18 2013 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 92A1B11E8173 for ; Tue, 10 Sep 2013 22:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.945 X-Spam-Level: X-Spam-Status: No, score=-105.945 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcojOprcXE8S for ; Tue, 10 Sep 2013 22:58:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6711E8179 for ; Tue, 10 Sep 2013 22:58:36 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-e1-5230068a48ca Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F4.0D.22048.A8600325; Wed, 11 Sep 2013 07:58:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Wed, 11 Sep 2013 07:58:33 +0200 Message-ID: <523006A3.4020907@ericsson.com> Date: Wed, 11 Sep 2013 07:58:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvjW4Xm0GQwe0nlhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/POO9aCudIV/2dtZGxgfCjWxcjBISFgIrHhsUgXIyeQKSZx 4d56ti5GLg4hgcOMEn/PXGSBcJYzSnx4fogVpIpXQFvi/YN9bCA2i4CqRNejRjCbTcBC4uYP CFtUIFiifftXNoh6QYmTM5+wgNgiAuoSlx9eYAexhQUiJDbdeM8IsVlSYtuiY2BxZgEDiSOL 5rBC2PISzVtnM4PYQkB7G5o6WCcw8s9CMnYWkpZZSFoWMDKvYmTPTczMSS8338QIDKeDW34b 7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhVarZkpfdfrZ/K 73zL0SfPT1dE5ulzJ9Oa+TULu1lXPZjvdElZaCdXkv/yKYy7mX9OfvFd6rawqHJ+8L/8kNv2 VZLlt06f1963ZC7jq9JanfYbAaXRQVvSTgVvcc7jb3oTwspp4aGklvzv6luFmnV2Cb3Pg6cL SFdzaD6dvub+/TX+b81qzyixFGckGmoxFxUnAgAbYNhL9QEAAA== Subject: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 11 Sep 2013 05:59:19 -0000 WG, There will be a new version of JSEP draft coming out Monday. As a follow up to get as much progress on this topic as possible. The chairs and authors are offering a informal walk through session on Wednesday the 18th. People will be strongly recommended to have reviewed the new draft. The intention of the session is enable the authors to inform you about the latest changes, any issues to consider and what needs further discussion. The will also enable you as participant after your review of the document to ask clarifying questions or for motivations behind choices, and raise issues you have spotted. The session is not intended to solve issues or judge consensus on part of the draft. Discussions of what is the best solution etc, will to be cut off. This will be a webex conference per details below. Cheers Magnus Westerlund Topic: RTCWeb - JSEP Date: Wednesday, September 18, 2013 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 302 061 238 Meeting Password: ietf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0 2. Enter your name and email address. 3. Enter the meeting password: ietf 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. -- 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 stephane.proust@orange.com Wed Sep 11 02:19:50 2013 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 E88DF21E8091 for ; Wed, 11 Sep 2013 02:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ7nydHF3qTr for ; Wed, 11 Sep 2013 02:19:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3521E809B for ; Wed, 11 Sep 2013 02:19:46 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 93BB62AC7CC; Wed, 11 Sep 2013 11:19:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7A41B384069; Wed, 11 Sep 2013 11:19:43 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 11 Sep 2013 11:19:42 +0200 From: To: 'Jean-Marc Valin' , "'Mo Zanaty (mzanaty)'" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt Thread-Index: AQHOrkKBNf0VLpHUzEKr6spLBSmfVZnAQkCw Date: Wed, 11 Sep 2013 09:19:41 +0000 Message-ID: <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> <522F4836.6030001@mozilla.com> In-Reply-To: <522F4836.6030001@mozilla.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.11.81514 Cc: "'rtcweb@ietf.org'" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 11 Sep 2013 09:19:51 -0000 >These are the codecs that would be recommended under such text. None of th= em is really ideal for interactive audio That is the reason why the proposed text only applies to "suitable" audio c= odecs " If other suitable audio codecs..." That's also why it cannot be interpreted as a strictly normative text and w= hy I also suggested (as it was previously suggested by the Chairs) to have = some additional informative (and separate) text about what are those suitab= le codecs to be considered and what is the rationale behind this (http://ww= w.ietf.org/mail-archive/web/rtcweb/current/msg08501.html) St=E9phane -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Jean-Marc Valin Envoy=E9=A0: mardi 10 septembre 2013 18:27 =C0=A0: Mo Zanaty (mzanaty) Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt > To ensure a baseline level of interoperability between WebRTC clients,=20 > a minimum set of required codecs are specified below. > If other suitable audio codecs are available to the browser to use, it=20 > is RECOMMENDED that they are also included in the offer in order to=20 > maximize the possibility to establish the session without the need for=20 > audio transcoding. Let's look at the practical effect here, assuming people were to actually f= ollow such a recommendation. The only audio codecs that are implemented in = browsers but not available for WebRTC are the ones used for HTML5. Accordin= g to http://html5test.com/ these codecs are Vorbis, MP3, AAC, and uncompres= sed PCM. These are the codecs that would be recommended under such text. No= ne of them is really ideal for interactive audio, none of them is implement= ed in old phones AFAIK, but all of them would require time and effort to ad= d to a browser's RTP stack. I really don't see the point here. Jean-Marc _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From sanjay.mishra@verizon.com Wed Sep 11 05:53:20 2013 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 2591111E8249 for ; Wed, 11 Sep 2013 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCaYCTjWApOz for ; Wed, 11 Sep 2013 05:53:14 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id E173611E8242 for ; Wed, 11 Sep 2013 05:53:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 11 Sep 2013 12:53:05 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.90,884,1371081600"; d="scan'208";a="555488954" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 11 Sep 2013 12:53:05 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 11 Sep 2013 08:53:05 -0400 To: "Muthu Arul Mozhi Perumal (mperumal)" , "Dan Wing (dwing)" , "Ram Mohan R (rmohanr)" , "Tirumaleswar Reddy (tireddy)" Date: Wed, 11 Sep 2013 08:53:03 -0400 Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: Ac6tN+qfR6vXQELAQEiGliH2MY4jagBGN0NQABQuU4AAEOtJEA== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C7986931A@FHDP1LUMXC7V23.us.one.verizon.com> References: <522D88A8.3010209@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C79869199@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 11 Sep 2013 12:53:20 -0000 On Tuesday, September 10, 2013 11:51 PM Muthu Arul Mozhi Perumal wrote: >The "why" part is mentioned in the first paragraph of the abstract: > Verification of peer consent before sending traffic is necessary in > WebRTC deployments to ensure that a malicious JavaScript cannot use > the browser as a platform for launching attacks. > Are you suggesting expanding this? The abstract needs to be concise, howe= ver. I agree the first paragraph states the premise and that is good, however, t= he second paragraph which lays out the purpose of this document, and since = the purpose is both how and why, the second paragraph could state something= like this: "This document describes both how and why a webRTC browser can and must ver= ify peer consent to continue sending traffic and detect connection failure.= " Thanks Sanjay -----Original Message----- From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Tuesday, September 10, 2013 11:51 PM To: Mishra, Sanjay; Dan Wing (dwing); Ram Mohan R (rmohanr); Tirumaleswar R= eddy (tireddy) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness? |In the abstract, second paragraph, the text states "how" a WebRTC=20 |browser can verify peer consent and as I read through the rest of the=20 |document I also understood "why" this is needed. So, just a knit pick,=20 |it may be clear to the reader if the statement also includes why within=20 |the body of the Abstract. The "why" part is mentioned in the first paragraph of the abstract: Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. Are you suggesting expanding this? The abstract needs to be concise, howeve= r. |One minor typo in section 7. Please change "in-intended" to "un-intended". Will fix it. Thanks for the review.. Muthu=20 |-----Original Message----- |From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] |Sent: Wednesday, September 11, 2013 12:38 AM |To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing); Ram Mohan R=20 |(rmohanr); Tirumaleswar Reddy |(tireddy) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness? | |Muthu et al -- | | |In the abstract, second paragraph, the text states "how" a WebRTC=20 |browser can verify peer consent and as I read through the rest of the=20 |document I also understood "why" this is needed. So, just a knit pick,=20 |it may be clear to the reader if the statement also includes why within th= e body of the Abstract. | |One minor typo in section 7. Please change "in-intended" to "un-intended". | |Thanks |Sanjay | |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 |Behalf Of Magnus Westerlund |Sent: Monday, September 09, 2013 4:37 AM |To: rtcweb@ietf.org |Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? | |WG, | |This is a call for WG adoption of STUN Usage for Consent Freshness=20 |(draft-muthu-behave-consent- freshness-04). This document defines a=20 |STUN usage for consent freshness. As this requires no protocol extensions = we as intended users can define this usage in our WG. Such work also matche= s our charter. |The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this ST= UN usage. | |Document: |https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ | |WG, please indicate your support or issues with adopting this document=20 |as WG item with a proposed |milestone: | |Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as = proposed standard. | |Cheers | |Magnus Westerlund | |---------------------------------------------------------------------- |Multimedia Technologies, Ericsson Research EAB/TVM |---------------------------------------------------------------------- |Ericsson AB | Phone +46 10 7148287 |F=E4r=F6gatan 6 | Mobile +46 73 0949079 |SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com |---------------------------------------------------------------------- | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From lijing80@huawei.com Thu Sep 12 00:58:35 2013 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 C028F21E808C for ; Thu, 12 Sep 2013 00:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWHY7trlfCUv for ; Thu, 12 Sep 2013 00:58:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 350AF11E8160 for ; Thu, 12 Sep 2013 00:58:31 -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 AVI17367; Thu, 12 Sep 2013 07:58:23 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 08:57:35 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 08:57:46 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.31]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Thu, 12 Sep 2013 15:57:41 +0800 From: "Lijing (Jessie, Huawei)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOrTfux2KRel+DmEaaqMlDUjQllpnAHbDwgAGeH0A= Date: Thu, 12 Sep 2013 07:57:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? 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, 12 Sep 2013 07:58:35 -0000 Hi all, As a newcomer to RTCWEB, I have some doubts after I have read the draft.=20 1. in "4. Solution Overview", may be it would be better to clarify when to= send a STUN Binding Request(in the middle of a media session or before sen= ding traffic, during sending traffic or only during silence periods) and wh= ich side to send the request(controlling agent or both sides)? 2. in " 7. Security Considerations", there are the following words. As whe= n one agent receives STUN Binding Request, unlike the processing of indicat= ion message, it have to do more processes to send the Response message, I a= m not sure whether it is appreciate not to authenticate the source and resp= ond directly. Is it more open to malicious attacks? "Once that connection to the remote peer has been established with ICE, the consent to continue sending traffic does not benefit from re-asserting that same username and password, so long as the senders and receiver's IP addresses remain the same (as they usually do)." Neglect my words, if my understandings are wrong. Best regards, Jessie -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: Monday, September 09, 2013 4:37 PM To: rtcweb@ietf.org Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter. The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as WG item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu Sep 12 02:54:17 2013 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 6C11421E8091 for ; Thu, 12 Sep 2013 02:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzphrNcF6V8i for ; Thu, 12 Sep 2013 02:54:12 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 3577611E81BF for ; Thu, 12 Sep 2013 02:54:11 -0700 (PDT) Received: (qmail 23002 invoked from network); 12 Sep 2013 09:54:09 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 12 Sep 2013 09:54:09 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9A24118A0AE3; Thu, 12 Sep 2013 10:54:09 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6F43318A0462; Thu, 12 Sep 2013 10:54:09 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Thu, 12 Sep 2013 10:54:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E948534-4ADA-4CB7-8705-C970E5294ACD@phonefromhere.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> <522F4836.6030001@mozilla.com> <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) Cc: "'rtcweb@ietf.org'" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 12 Sep 2013 09:54:17 -0000 As I said last time this came up, we need to include language that = ensures that these non-mandatory codecs don't=20 get used unless the mandatory ones are unavailable, or the web developer = explicitly selected them. I don't want to find that I'm getting amr-nb between a pair of phone = based browsers and getting narrow band because both the phones happen to have that codec available. How about:=20 To ensure a baseline level of interoperability between WebRTC clients,=20= a minimum set of required codecs are specified below. If other suitable audio codecs are available to the browser to use, it=20= is advised that they are also included in the offer at a lower priority = than the required codecs in order to=20 maximize the possibility to establish the session without the need for=20= audio transcoding when the required codecs are unavailable to one party. - Of course this whole discussion highlights the need for a set of = constraints (or an API) that let the web developer=20 express her preferences wrt codec selection. Tim. On 11 Sep 2013, at 10:19, = wrote: >> These are the codecs that would be recommended under such text. None = of them is really ideal for interactive audio >=20 > That is the reason why the proposed text only applies to "suitable" = audio codecs > " If other suitable audio codecs..." >=20 > That's also why it cannot be interpreted as a strictly normative text = and why I also suggested (as it was previously suggested by the Chairs) = to have some additional informative (and separate) text about what are = those suitable codecs to be considered and what is the rationale behind = this (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html) >=20 > St=E9phane >=20 >=20 > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Jean-Marc Valin > Envoy=E9 : mardi 10 septembre 2013 18:27 > =C0 : Mo Zanaty (mzanaty) > Cc : rtcweb@ietf.org > Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt >=20 >> To ensure a baseline level of interoperability between WebRTC = clients,=20 >> a minimum set of required codecs are specified below. >> If other suitable audio codecs are available to the browser to use, = it=20 >> is RECOMMENDED that they are also included in the offer in order to=20= >> maximize the possibility to establish the session without the need = for=20 >> audio transcoding. >=20 > Let's look at the practical effect here, assuming people were to = actually follow such a recommendation. The only audio codecs that are = implemented in browsers but not available for WebRTC are the ones used = for HTML5. According to http://html5test.com/ these codecs are Vorbis, = MP3, AAC, and uncompressed PCM. These are the codecs that would be = recommended under such text. None of them is really ideal for = interactive audio, none of them is implemented in old phones AFAIK, but = all of them would require time and effort to add to a browser's RTP = stack. I really don't see the point here. >=20 > Jean-Marc > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu Sep 12 10:57:54 2013 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 1E05C11E80EC for ; Thu, 12 Sep 2013 10:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoOpiIj4k7pN for ; Thu, 12 Sep 2013 10:57:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20811E81E3 for ; Thu, 12 Sep 2013 10:57:35 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA4A2509B6; Thu, 12 Sep 2013 13:57:33 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Sep 2013 11:57:31 -0600 Message-Id: <5EBAE818-D5C3-4DF2-8382-385613B88D09@iii.ca> To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Cary Bran Subject: [rtcweb] Consensus on text around additional 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: Thu, 12 Sep 2013 17:57:54 -0000 I have reviewed all the emails about this since January 1. Many people = have spoken in favor of the "recommended to support whatever the = platform has that makes sense" style text and there has been close to no = strong objections to this. My belief is that based on the email record, = there is WG consensus to add text around that. Now there is some = possibility there are a bunch of people that object given there has been = no formal consensus call so here's what I would like to have happen.=20 I would like the editors of to make the following change to = draft-ietf-rtcweb-audio --------------------- OLD: =20 To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. While this section specifies the codecs that will be mandated for all WebRTC client implementations, it leaves the question of supporting additional codecs to the will of the implementer. =20 WebRTC clients are REQUIRED to implement the following audio codecs. =20 NEW: =20 To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs are specified below. If other suitable audio codecs are available for the browser to use, it is RECOMMENDED that they are also be included in the offer in order to maximize the possibility to establish the session without the need for audio transcoding. =20 WebRTC clients are REQUIRED to implement the following audio codecs. ---------------------- This will then get publish as a new draft. The WG can comment on that = draft and if lots of people have an issue with that text, then we can = allocate time to discuss it at a future meeting and, if needed, make a = more formal consensus call so that no one misses it.=20 My hope is that the people that care about this have expressed their = opinions on the list and that when the draft comes out, the consensus = will not change. If that turns out to be wrong, folks can still object = about text in the draft.=20 I will note that several people have pointed out this text is fairly = weak. However, at this point in time, I don't think there is consensus = to add stronger language. (Note: I also don't see consensus to not add = stronger language).=20 Thanks, Cullen PS - I have received off list suggestions that this is an ideal place to = use rfc6919 language - as chair I MUST strongly encourage people to = stick with the the more traditional rfc2119 language. =20 From bernard_aboba@hotmail.com Thu Sep 12 12:43:15 2013 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 2F86F11E8100 for ; Thu, 12 Sep 2013 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPLSOQgBwmTe for ; Thu, 12 Sep 2013 12:43:09 -0700 (PDT) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2621E8099 for ; Thu, 12 Sep 2013 12:43:08 -0700 (PDT) Received: from BLU169-W40 ([65.55.116.72]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 12:43:08 -0700 X-TMN: [jNGa9fwQBRLeVxzz7CqbzdoqstaSVuYn+yDONt7jDQU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9f76e178-2df1-4484-9753-405e59534448_" From: Bernard Aboba To: Tim Panton , "stephane.proust@orange.com" Date: Thu, 12 Sep 2013 12:43:08 -0700 Importance: Normal In-Reply-To: <9E948534-4ADA-4CB7-8705-C970E5294ACD@phonefromhere.com> References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com>, , <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com>, <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net>, , , <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com>, <522F4836.6030001@mozilla.com>, <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup>, <9E948534-4ADA-4CB7-8705-C970E5294ACD@phonefromhere.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2013 19:43:08.0501 (UTC) FILETIME=[4E8A2050:01CEAFF0] Cc: "'rtcweb@ietf.org'" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 12 Sep 2013 19:43:15 -0000 --_9f76e178-2df1-4484-9753-405e59534448_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tim said:=20 > - Of course this whole discussion highlights the need for a set of constr= aints (or an API) that let the web developer=20 > express her preferences wrt codec selection. [BA] This - and the need to specify the default ordering of codecs within t= he API=2C so that by default the MTI codecs will be offered at a higher pri= ority.=20 > How about:=20 >=20 > To ensure a baseline level of interoperability between WebRTC clients=2C= =20 > a minimum set of required codecs are specified below. > If other suitable audio codecs are available to the browser to use=2C it= =20 > is advised that they are also included in the offer at a lower priority t= han the required codecs in order to=20 > maximize the possibility to establish the session without the need for=20 > audio transcoding when the required codecs are unavailable to one party. =20 [BA] On reading this I'm unsure whether by "offer" you mean the SDP used in= the API=2C of if you're talking about an offer sent over the wire. The t= ext makes more sense to me if you're talking about the API.=20 =20 If the developer decides they want to offer amr-nb as the preferred codec i= n an Offer sent over the wire=2C that's their choice=2C as long as they don= 't delete the MTI codecs from the offer=2C which could potentially cause an= interoperability failure. However=2C if the developer is just trusting t= he API to do something sensible=2C then by default I'd say that one of the = MTI codecs should be negotiated by default. In particular=2C in the browse= r-browser case I'd advocate that Opus by negotiated by default=2C for audio= . =20 = --_9f76e178-2df1-4484-9753-405e59534448_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tim said:

>=3B - Of co= urse this whole discussion highlights the need for a set of constraints (or= an API) that let the web developer
>=3B express her preferences wrt = codec selection.

[BA] =3BThis - and the need to specify the defa= ult ordering of =3Bcodecs within the API=2C so that by default the MTI = codecs will be offered at a higher priority.

>=3B How about:
= >=3B
>=3B To ensure a baseline level of interoperability between We= bRTC clients=2C
>=3B a minimum set of required codecs are specified b= elow.
>=3B If other suitable audio codecs are available to the browser= to use=2C it
>=3B is advised that they are also included in the offe= r at a lower priority than the required codecs in order to
>=3B maxim= ize the possibility to establish the session without the need for
>= =3B audio transcoding when the required codecs are unavailable to one party= .
 =3B
[BA] =3BOn reading this I'm unsure whether by =3B"= offer" you mean the SDP used in the API=2C of if you're talking about an of= fer sent over the wire. =3B =3B The text makes more sense to me if = you're talking about the API.
 =3B
If the developer decides they= want to offer =3Bamr-nb as the preferred codec in an Offer sent over t= he wire=2C that's their choice=2C as long as they don't delete the MTI code= cs from the offer=2C which could potentially cause an interoperability fail= ure. =3B =3B However=2C if the developer is just trusting the API t= o do something sensible=2C then by default I'd say that one of the MTI code= cs should be negotiated by default. =3B In particular=2C in the browser= -browser case I'd advocate that Opus by negotiated by default=2C for audio.=  =3B

= --_9f76e178-2df1-4484-9753-405e59534448_-- From roman@telurix.com Thu Sep 12 12:49:53 2013 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 6F68411E8273 for ; Thu, 12 Sep 2013 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woCv1nGMf0Pj for ; Thu, 12 Sep 2013 12:49:48 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3233411E8267 for ; Thu, 12 Sep 2013 12:49:46 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so277828wes.9 for ; Thu, 12 Sep 2013 12:49:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E3wo69OwBH4QbqjndAxTdfyuc6j3MAwY5zeE4fVBvrs=; b=culFz6Qw3UUx8sxnQn1jC6dOe+NDVjQi81EL82yyPCWI52wk0CQ0NPmJDWIi19S9ww PWYPiCKca9WJ3aXQ3JCT1RGYFvC7lxhdUAfvlVfTmym2fCqDAOKBsnzuAJmoOfo28Qyq YdpjLx/Z5WOPZ1U4p+WtLGfJq2/2l1HIb69jrFEXUnGq44WklXQtRhBpbnkZocbS7OIl woE1kS6zVI5Lu9M4o4cGNAVqOZwvCmUCo9J48FZl6bmCiAAfQVuG/vyO78U6KbCcAp+c ippF/SmnqGJSC3uT2oBXUskrSSA8rhV3IWvH1Wnb8mrGkJL9kdKyFpBn2TuA2BXVqCUp hcGQ== X-Gm-Message-State: ALoCoQnrYKfNAoDiHarV6NKFVbtqBCSISjCQ1wD678wZRlCmeFANXyv+OPBRvRyif8HM6xRNY6NZ X-Received: by 10.180.13.13 with SMTP id d13mr7385071wic.34.1379015384169; Thu, 12 Sep 2013 12:49:44 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [2a00:1450:400c:c05::231]) by mx.google.com with ESMTPSA id e5sm20066138wiy.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 12:49:43 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so295184wib.10 for ; Thu, 12 Sep 2013 12:49:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.100.202 with SMTP id fa10mr22961141wib.8.1379015382575; Thu, 12 Sep 2013 12:49:42 -0700 (PDT) Received: by 10.216.26.1 with HTTP; Thu, 12 Sep 2013 12:49:42 -0700 (PDT) In-Reply-To: References: <20130802162957.17108.79281.idtracker@ietfa.amsl.com> <3879D71E758A7E4AA99A35DD8D41D3D91D5260A2@xmb-rcd-x14.cisco.com> <56C2F665D49E0341B9DF5938005ACDF80E8A65@DEMUMBX005.nsn-intra.net> <3879D71E758A7E4AA99A35DD8D41D3D91D5265C8@xmb-rcd-x14.cisco.com> <522F4836.6030001@mozilla.com> <4066_1378891183_523035AF_4066_5132_1_2842AD9A45C83B44B57635FD4831E60A06C3C1BE@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9E948534-4ADA-4CB7-8705-C970E5294ACD@phonefromhere.com> Date: Thu, 12 Sep 2013 15:49:42 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d04447fe504b42204e6350ad1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.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, 12 Sep 2013 19:49:53 -0000 --f46d04447fe504b42204e6350ad1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 12, 2013 at 3:43 PM, Bernard Aboba wrote: > > [BA] This - and the need to specify the default ordering of codecs within > the API, so that by default the MTI codecs will be offered at a higher > priority. > I am not sure that MTI codecs should always be highest priority. If optional codec would be developed of higher quality then Opus or the yet to be defined MTI video codec (for instance if someone created Opus-NG or in case of VP9 or H.265), then there is no reason for this codec not to be offered at higher priority then MTI. _____________ Roman Shpount --f46d04447fe504b42204e6350ad1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 12, 2013 at 3:43 PM, Bernard Aboba <bernard_aboba@hotmail.= com> wrote:

[BA]=A0This - and the nee= d to specify the default ordering of=A0codecs within the API, so that by de= fault the MTI codecs will be offered at a higher priority.
=

I am not sure that MTI codecs sh= ould always be highest priority. If optional codec would be developed of hi= gher quality then Opus or the yet to be defined MTI video codec (for insta= nce if someone created Opus-NG or in case of VP9 or H.265), then there is n= o reason for this codec not to be offered at higher priority then MTI.
_____________
Roman Shpount

--f46d04447fe504b42204e6350ad1-- From bernard_aboba@hotmail.com Thu Sep 12 12:57:07 2013 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 5DBA821E8201 for ; Thu, 12 Sep 2013 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-vMhpqW2XEH for ; Thu, 12 Sep 2013 12:57:01 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F921E820E for ; Thu, 12 Sep 2013 12:57:01 -0700 (PDT) Received: from BLU169-W79 ([65.55.111.71]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 12:57:01 -0700 X-TMN: [cLJzK//TCDafmuk7MyKP12FqiXDT1RW1mHsPdvb7gH0=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a796e556-5b05-4be3-9481-4be2829ec8f9_" From: Bernard Aboba To: "Hutton, Andrew" , "rtcweb@ietf.org" Date: Thu, 12 Sep 2013 12:57:00 -0700 Importance: Normal In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com>, <5225B1AF.7050906@alvestrand.no>, <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2013 19:57:01.0124 (UTC) FILETIME=[3ED25040:01CEAFF2] Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 12 Sep 2013 19:57:07 -0000 --_a796e556-5b05-4be3-9481-4be2829ec8f9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Hutton said:=20 > Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV= 6 which I assume it should. Specifically I am thinking that it needs to sta= te a requirement to support RFC6156 support "Traversal Using Relays around = NAT (TURN) Extension for IPv6". >=20 > I am not sure how much we need to say about webrtc client procedures arou= nd RFC6156 and whether they should be included in the draft-ietf-rtcweb-tra= nsport or whether it is something we should add to our nat/firewall draft (= draft-hutton-rtcweb-nat-firewall-considerations). Any opinions on this? [BA] Adding it to the NAT/Firewall draft makes the most sense to me. Among= other things=2C it might provide more of an opportunity to get into some o= f the "Happy Eyeballs" issues that have come up=2C such as relative priorit= ization of IPv4 versus IPv6. =20 = --_a796e556-5b05-4be3-9481-4be2829ec8f9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andrew Hutton said:

>= =3B Currently draft-ietf-rtcweb-transports-01 does not say anything about I= PV6 which I assume it should. Specifically I am thinking that it needs to s= tate a requirement to support RFC6156 support "Traversal Using Relays aroun= d NAT (TURN) Extension for IPv6".
>=3B
>=3B I am not sure how mu= ch we need to say about webrtc client procedures around RFC6156 and whether= they should be included in the draft-ietf-rtcweb-transport or whether it i= s something we should add to our nat/firewall draft (draft-hutton-rtcweb-na= t-firewall-considerations). Any opinions on this?

[BA] Adding it to= the NAT/Firewall draft makes the most sense to me. =3B Among other thi= ngs=2C it might provide more of an opportunity to get into some of the "Hap= py Eyeballs" issues that have come up=2C such as relative =3Bprioritiza= tion of IPv4 versus IPv6. =3B =3B

= --_a796e556-5b05-4be3-9481-4be2829ec8f9_-- From bernard_aboba@hotmail.com Thu Sep 12 13:06:35 2013 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 EE7CB11E810B for ; Thu, 12 Sep 2013 13:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr7Ng9L3e9qA for ; Thu, 12 Sep 2013 13:06:26 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29221E8053 for ; Thu, 12 Sep 2013 13:06:23 -0700 (PDT) Received: from BLU169-W96 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 13:06:23 -0700 X-TMN: [sBPwkNtQJT9ijqkC2HvG2VP91PCY5JoFt27HCtS/UIY=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d6856e87-7dac-4d49-a6ee-a09945305943_" From: Bernard Aboba To: "Hutton, Andrew" , "rtcweb@ietf.org" Date: Thu, 12 Sep 2013 13:06:23 -0700 Importance: Normal In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> References: <20130903094045.23789.92925.idtracker@ietfa.amsl.com>, <5225B1AF.7050906@alvestrand.no>, <9F33F40F6F2CD847824537F3C4E37DDF17BBC905@MCHP04MSX.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2013 20:06:23.0406 (UTC) FILETIME=[8DF7BCE0:01CEAFF3] Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156. 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, 12 Sep 2013 20:06:35 -0000 --_d6856e87-7dac-4d49-a6ee-a09945305943_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Hutton said:=20 > Currently draft-ietf-rtcweb-transports-01 does not say anything about IPV= 6 which I assume it should. Specifically I am thinking that it needs to sta= te a requirement to support RFC6156 support "Traversal Using Relays around = NAT (TURN) Extension for IPv6". >=20 > I am not sure how much we need to say about webrtc client procedures arou= nd RFC6156 and whether they should be included in the draft-ietf-rtcweb-tra= nsport or whether it is something we should add to our nat/firewall draft (= draft-hutton-rtcweb-nat-firewall-considerations). Any opinions on this? [BA] Adding it to the NAT/Firewall draft makes the most sense to me. Among= other things=2C it might provide more of an opportunity to get into some o= f the "Happy Eyeballs" issues that have come up=2C such as relative priorit= ization of IPv4 versus IPv6. =20 = --_d6856e87-7dac-4d49-a6ee-a09945305943_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andrew Hutton said:

>= =3B Currently draft-ietf-rtcweb-transports-01 does not say anything about I= PV6 which I assume it should. Specifically I am thinking that it needs to s= tate a requirement to support RFC6156 support "Traversal Using Relays aroun= d NAT (TURN) Extension for IPv6".
>=3B
>=3B I am not sure how mu= ch we need to say about webrtc client procedures around RFC6156 and whether= they should be included in the draft-ietf-rtcweb-transport or whether it i= s something we should add to our nat/firewall draft (draft-hutton-rtcweb-na= t-firewall-considerations). Any opinions on this?

[BA] Adding it to= the NAT/Firewall draft makes the most sense to me. =3B Among other thi= ngs=2C it might provide more of an opportunity to get into some of the "Hap= py Eyeballs" issues that have come up=2C such as relative =3Bprioritiza= tion of IPv4 versus IPv6. =3B =3B

= --_d6856e87-7dac-4d49-a6ee-a09945305943_-- From trac+rtcweb@trac.tools.ietf.org Thu Sep 12 17:08:07 2013 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 ECB8721E80F7 for ; Thu, 12 Sep 2013 17:08:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyT3eZDLrEBX for ; Thu, 12 Sep 2013 17:08:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4821E80ED for ; Thu, 12 Sep 2013 17:08:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:58270 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKGvb-00011m-80; Fri, 13 Sep 2013 02:08:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Fri, 13 Sep 2013 00:08:03 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/30 Message-ID: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: christer.holmberg@ericsson.com, goran.ap.eriksson@ericsson.com, stefan.lk.hakansson@ericsson.com Resent-Message-Id: <20130913000807.19E4821E80ED@ietfa.amsl.com> Resent-Date: Thu, 12 Sep 2013 17:08:05 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] #30: Wiretapping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 00:08:08 -0000 #30: Wiretapping In several sections of the document, the phrase "It is essential that the communication cannot be wiretapped [RFC2804]" is used. The phrase is used in Sections 3.2.1.1, 3.2.11.1, 3.2.12.1, 3.2.13.1, 3.3.1.1 and 3.2.3.1, but not in 3.2.14.1 (which also does not reference F20). Given the recent revelations, and the discussion of SRTP/SDES at IETF 87, I would suggest the following: a. Use of more precise terminology than what is in F20. For example, I think what we are asking for in many of the F20 scenarios is per-packet encryption and integrity protection of media, utilizing keys known only by the endpoints, as well as support for perfect forward secrecy. b. Inclusion of a reference to F20 in Section 3.2.14.1 (Distributed Music Band). Not sure why protection against snooping wouldn't be relevant in this use case (there are countries where musicians have been severely punished). c. Consideration of the requirement in gateway scenarios. For gateway scenarios such as 3.3.1.1, the e2e key management requirement probably isn't realistic, so maybe we need to just cite F35/F36 for that case. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-use- bernard_aboba@hotmail.com | cases-and- Type: defect | requirements@tools.ietf.org Priority: critical | Status: new Component: rtp-usage | Milestone: milestone1 Severity: In WG Last Call | Version: 1.0 | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Thu Sep 12 17:08:53 2013 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 7EFB221E80F7 for ; Thu, 12 Sep 2013 17:08:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAdsbs81p88Q for ; Thu, 12 Sep 2013 17:08:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EC56521E80ED for ; Thu, 12 Sep 2013 17:08:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:58287 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKGwN-0006Nh-EP; Fri, 13 Sep 2013 02:08:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Fri, 13 Sep 2013 00:08:51 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/rtcweb/trac/ticket/30#comment:1 Message-ID: <081.b488fa469a6209cfd8101fed6e257750@trac.tools.ietf.org> References: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: christer.holmberg@ericsson.com, goran.ap.eriksson@ericsson.com, stefan.lk.hakansson@ericsson.com Resent-Message-Id: <20130913000852.EC56521E80ED@ietfa.amsl.com> Resent-Date: Thu, 12 Sep 2013 17:08:52 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #30: Wiretapping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 00:08:53 -0000 #30: Wiretapping Changes (by bernard_aboba@hotmail.com): * component: rtp-usage => use-cases-and-requirements -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-use- bernard_aboba@hotmail.com | cases-and- Type: defect | requirements@tools.ietf.org Priority: critical | Status: new Component: use-cases-and- | Milestone: milestone1 requirements | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Thu Sep 12 17:19:07 2013 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 AAA4D21E821E for ; Thu, 12 Sep 2013 17:19:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9xCgc3W1aEr for ; Thu, 12 Sep 2013 17:19:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0801D21F95D0 for ; Thu, 12 Sep 2013 17:18:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:58864 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKH69-0002m8-AS; Fri, 13 Sep 2013 02:18:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Fri, 13 Sep 2013 00:18:57 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/31 Message-ID: <066.72974763150f699b699079e791c67107@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: christer.holmberg@ericsson.com, goran.ap.eriksson@ericsson.com, stefan.lk.hakansson@ericsson.com Resent-Message-Id: <20130913001859.0801D21F95D0@ietfa.amsl.com> Resent-Date: Thu, 12 Sep 2013 17:18:58 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] #31: Miscellaneous X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 00:19:07 -0000 #31: Miscellaneous Section 3.2.1.1 "The application gives the users the opportunity to stop it from exposing the host IP address to the application of the other user." [BA] This text suggests a requirement for the browser to ask user consent, which seems different from what is in F39: "The browser must make it possible to set up a call between two parties without one party learning the other party's host IP address." IMHO, F39 seems somewhat closer to the requirement we want. Section 3.2.10.1 "NOTE: More profiling of what this means may be needed." [BA] Section 3.3.1.1 already describes a telephony gateway scenario, but for some reason that section doesn't cite requirement F27 (SIP) or A20. FWIW, I'm not sure what this scenario adds, because RFC 3261 inter-domain federation isn't widely deployed, as opposed to E.164 inter-connect. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-use- bernard_aboba@hotmail.com | cases-and- Type: defect | requirements@tools.ietf.org Priority: minor | Status: new Component: use-cases-and- | Milestone: milestone1 requirements | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Thu Sep 12 17:28:21 2013 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 2EC6521F9D38 for ; Thu, 12 Sep 2013 17:28: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RmoaQPe+vwh for ; Thu, 12 Sep 2013 17:28:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9983A21F9D34 for ; Thu, 12 Sep 2013 17:28:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:59418 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKHFD-0005Ms-GZ; Fri, 13 Sep 2013 02:28:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Fri, 13 Sep 2013 00:28:19 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/32 Message-ID: <066.5fbb20716b37306444e2b32ff3085ce3@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: christer.holmberg@ericsson.com, goran.ap.eriksson@ericsson.com, stefan.lk.hakansson@ericsson.com Resent-Message-Id: <20130913002820.9983A21F9D34@ietfa.amsl.com> Resent-Date: Thu, 12 Sep 2013 17:28:20 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] #32: Section 3.2.1.1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 00:28:21 -0000 #32: Section 3.2.1.1 "One user has an unreliable Internet connection. It sometimes loses packets, and sometimes goes down completely." [BA] I assume that this is generating requirement F8 (The browser must detect when a stream from a peer is not received anymore). Since we are using a consent mechanism to send mechanism, you might consider rephrasing F8 to "The browser must detect peer loss of connectivity." However, if we just focus at the packet loss issue, this might suggest a requirement for statistics (F38) or repair of some kind (e.g. either RTX or FEC). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-use- bernard_aboba@hotmail.com | cases-and- Type: defect | requirements@tools.ietf.org Priority: minor | Status: new Component: use-cases-and- | Milestone: milestone1 requirements | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From lijing80@huawei.com Thu Sep 12 19:09:28 2013 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 B647311E80D5 for ; Thu, 12 Sep 2013 19:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDUmQ5ydbOgl for ; Thu, 12 Sep 2013 19:09:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 468E811E8131 for ; Thu, 12 Sep 2013 19:09:23 -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 AVI88962; Fri, 13 Sep 2013 02:09:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:08:30 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:08:44 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.31]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 13 Sep 2013 10:08:36 +0800 From: "Lijing (Jessie, Huawei)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOrTfux2KRel+DmEaaqMlDUjQllpnC4zIg Date: Fri, 13 Sep 2013 02:08:35 +0000 Message-ID: References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 13 Sep 2013 02:09:28 -0000 Hi all, As a newcomer to RTCWEB, I have some doubts after I have read the draft.=20 1. in "4. Solution Overview", may be it would be better to clarify when to= send a STUN Binding Request(in the middle of a media session or before sen= ding traffic, during sending traffic or only during silence periods) and wh= ich side to send the request(controlling agent or both sides)? During the s= ession, there are RTP/RTCP media streams which can keep the NAT mapping and= confirm the connectivity state of the media plane. Before the session, we = can use the ICE connectivity checks.=20 So according to my understanding, the STUN Binding Request should only be s= ent during the silence periods. A media connectivity check with a request a= nd a response during a session, is this the main idea of this document? 2. in " 7. Security Considerations", there are the following words.=20 "Once that connection to the remote peer has been established with ICE, the consent to continue sending traffic does not benefit from re-asserting that same username and password, so long as the senders and receiver's IP addresses remain the same (as they usually do)." As when one agent receives STUN Binding Request, unlike the processing o= f STUN Binding Indication message, it have to do more processes to send the= Response message, I am not sure whether it is appreciate not to authentica= te the source and respond directly. Is it more likely to receive malicious = attacks? Neglect my words, if my understandings are wrong. Best regards, Jessie -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: Monday, September 09, 2013 4:37 PM To: rtcweb@ietf.org Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter. The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as WG item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Fri Sep 13 00:15:35 2013 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 4ACD311E8153 for ; Fri, 13 Sep 2013 00:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNhUs9o70SBR for ; Fri, 13 Sep 2013 00:15:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A64D821E8051 for ; Fri, 13 Sep 2013 00:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39FCB39E202 for ; Fri, 13 Sep 2013 09:15:20 +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 GO8rhp+DBKEN for ; Fri, 13 Sep 2013 09:15:19 +0200 (CEST) Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1E2BC39E03B for ; Fri, 13 Sep 2013 09:15:19 +0200 (CEST) Message-ID: <5232BB86.5010202@alvestrand.no> Date: Fri, 13 Sep 2013 09:15:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> In-Reply-To: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] #30: Wiretapping 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, 13 Sep 2013 07:15:35 -0000 On 09/13/2013 02:08 AM, rtcweb issue tracker wrote: > #30: Wiretapping > > In several sections of the document, the phrase "It is essential > that the communication cannot be wiretapped [RFC2804]" is used. > The phrase is used in Sections 3.2.1.1, 3.2.11.1, 3.2.12.1, 3.2.13.1, > 3.3.1.1 and 3.2.3.1, but not in 3.2.14.1 (which also does not > reference F20). > > Given the recent revelations, and the discussion of SRTP/SDES at > IETF 87, I would suggest the following: > > a. Use of more precise terminology than what is in F20. For example, > I think what we are asking for in many of the F20 scenarios is > per-packet encryption and integrity protection of media, > utilizing keys known only by the endpoints, as well as support > for perfect forward secrecy. I think this is a too low level of detail for an use cases document. It does belong in the security / security-arch document, where we detail both what the requirement implies and how the requirement is implemented. If we want to add details here, I suggest adding "against an adversary that has access to the signalling path and/or access to one of the end systems after the communication has occured" (which would lead to a requirement for DTLS key exchange and PFS). > > b. Inclusion of a reference to F20 in Section 3.2.14.1 (Distributed > Music Band). Not sure why protection against snooping wouldn't be > relevant in this use case (there are countries where musicians > have been severely punished). > > c. Consideration of the requirement in gateway scenarios. For gateway > scenarios such as 3.3.1.1, the e2e key management > requirement probably isn't realistic, so maybe we need to > just cite F35/F36 for that case. > If we use the language I suggested above, noting that this spec can do nothing to secure things beyond the gateway is probably enough ("e2e" key management in this case would mean "end to gateway" - it's up to the gateway and what's beyond it to protect the keys after that). -- Surveillance is pervasive. Go Dark. From simon.perreault@viagenie.ca Fri Sep 13 02:23:52 2013 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 8D9D211E818A; Fri, 13 Sep 2013 02:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOF3BFQXT-Zx; Fri, 13 Sep 2013 02:23:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8211E8187; Fri, 13 Sep 2013 02:23:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B462041485; Fri, 13 Sep 2013 05:23:47 -0400 (EDT) Message-ID: <5232D9A2.8050800@viagenie.ca> Date: Fri, 13 Sep 2013 11:23:46 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org, "rtcweb@ietf.org" References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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, 13 Sep 2013 09:23:52 -0000 Le 2013-09-13 10:58, Chenxin (Xin) a écrit : > We have been working on a new version of the TURN over Websocket draft, which is now available at: > > http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt There are two major things missing in this draft: - How are TURN UDP "channels" supported? (See RFC 5766 section 2.5.) - How are TURN TCP "data connections" supported? (See RFC 6062 section 3.) I think the answers to these questions will greatly affect the overall design of TURN-over-WebSocket. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ted.ietf@gmail.com Fri Sep 13 09:52:28 2013 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 10E7B11E8171 for ; Fri, 13 Sep 2013 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgO3ZyURkoX8 for ; Fri, 13 Sep 2013 09:52:25 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CD37821F9D92 for ; Fri, 13 Sep 2013 09:52:24 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id u16so3014697iet.39 for ; Fri, 13 Sep 2013 09:52:24 -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=vnRCr41xZnTxYFhqpw5V3JlOKYl1EKbynM1hpsWm874=; b=llnFPXTxSgQbs0rJ0FjD4cLvwqtXlEhUtRmAwHxitIRwSJBwZeqIARH0gpFKGiXIHC QJTLqM9kc2iwbsehZwAryZEYOMsUeDaShQltemrX8pRh77FfLjm2ULsmMmH/ODfSGDGo /NBYE3wWb/UTqoMhMqL2123qUwOUazNqvaJYNIhOPFa0U4OfKDl9AXyo6+mryqrjXAN4 pxJK2Q0TnfQu6i6AstD2rzTOUuW9TaXbDLrL9oHK1F452KNd+8v2fA+oAVS3iY5dHmTU wZqI7m8MciUHpt5FPciw95S6oNWfGaHP5hjW1HhijLG59u12PkTOo/3+6b2D50xjiq06 8NlA== MIME-Version: 1.0 X-Received: by 10.43.19.198 with SMTP id ql6mr1976513icb.22.1379091144364; Fri, 13 Sep 2013 09:52:24 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 13 Sep 2013 09:52:24 -0700 (PDT) Date: Fri, 13 Sep 2013 09:52:24 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec519694bc5e53004e646adb0 Subject: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 16:52:28 -0000 --bcaec519694bc5e53004e646adb0 Content-Type: text/plain; charset=ISO-8859-1 WG, The chairs have created a plan for how to perform the Video Codec selection in our WG. The chairs are asking for review of our plan on how to undertake the mandatory-to-implement video codec selection. We'd much prefer to have comments on the mechanics before they begin, so please review now. Proponents of a particular proposal should note both the actions required and the timelines proposed. The main goal of this plan is to hold a consensus call on which of the proposed alternatives we as a WG should select at one of the WG sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate. The chairs will recuse themselves from judging this particular consensus. In the WG session each codec proposal will be allowed an equal amount of time to highlight the arguments for their proposal. After that a there will be a slot for discussion and clarifying questions. To enable the WG participants to get answers to any questions, the proposals in draft form and any supporting material MUST be made available by 6th of October. This is to ensure that the WG participants can verify or object to any claims or statements in the proposal material prior to the WG session. We chairs would really not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any arguments on the list ahead of time to enable the proponents to respond to such arguments. The proposed consensus questions will be of the following form: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. You may indicate support on both questions and we encourage you to do so if you can live with either, even if you have a preference for one over the other. Additional proposals than the previous ones are welcome, but must be submitted as draft and their proponents must notify the chairs no later than the 6th of October that they also have a candidate proposal. In case the WG fails to reach consensus we chairs propose that we use the alternative decision process as discussed in RFC3929. The method and its usage will be discussed on the list should the WG not establish consensus on a proposal for mandatory to implement video codec. regards, Magnus, Cullen, and Ted --bcaec519694bc5e53004e646adb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
WG,

The chairs have created a plan for how to = perform the Video Codec
selection in our WG. The chairs are asking for r= eview of our plan on
how to undertake the mandatory-to-implement video c= odec selection.
We'd much prefer to have comments on the mechanics before they begin,so please review now.=A0 Proponents of a particular proposal should
no= te both the actions required and the timelines proposed.

The main go= al of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sess= ions in Vancouver. Such a consensus call will of course be
verified on t= he mailing list for anyone who can't participate. The
chairs will re= cuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an = equal amount
of time to highlight the arguments for their proposal. Afte= r that a
there will be a slot for discussion and clarifying questions.
To enable the WG participants to get answers to any questions, the
p= roposals in draft form and any supporting material MUST be made
availabl= e by 6th of October. This is to ensure that the WG
participants can veri= fy or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
no= t like to see the proponents bring up new arguments at their
presentatio= n. Also the WG participants are expected to raise any
arguments on the l= ist ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be = of the following form:

1. If you support H.264 as the mandatory to i= mplement codec or are
willing to live with it as the MTI, please raise y= our hand now.

2. If you support VP8 as the mandatory to implement codec or are
wil= ling to live with it as the MTI, please raise your hand now.

You may= indicate support on both questions and we encourage you to do
so if you= can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welc= ome, but must be
submitted as draft and their proponents must notify the= chairs no later
than the 6th of October that they also have a candidate= proposal.

In case the WG fails to reach consensus we chairs propose that we usethe alternative decision process as discussed in RFC3929. The method
a= nd its usage will be discussed on the list should the WG not
establish c= onsensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=A0 Cullen, and Ted
--bcaec519694bc5e53004e646adb0-- From matthew@matthew.at Fri Sep 13 09:59:33 2013 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 A2EFE11E8194 for ; Fri, 13 Sep 2013 09:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UPQ7dF1fUOc for ; Fri, 13 Sep 2013 09:59:29 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C777C11E812F for ; Fri, 13 Sep 2013 09:59:28 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 31CF9148029 for ; Fri, 13 Sep 2013 09:59:17 -0700 (PDT) Message-ID: <52334462.608@matthew.at> Date: Fri, 13 Sep 2013 09:59:14 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030600080309060108030304" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 16:59:33 -0000 This is a multi-part message in MIME format. --------------030600080309060108030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 1. Please explain why this decision is an IETF decision and not a W3C decision, given that it is a choice about what to mandate in the presentation layer as codec, NOT what to mandate for the on-the-wire transport format (which has already been selected as DTLS-SRTP with an appropriate IETF payload based on the application) 2. Should I expect "room-packing" for this "show of hands" (which I don't believe is the typical "hum" process for the IETF, either) as happened during the SDES discussion last time, and therefore need to bring as many people who've not participated in RTCWEB previously but who want my codec to succeed as I can afford to fly to Vancouver? Matthew Kaufman On 9/13/2013 9:52 AM, Ted Hardie wrote: > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030600080309060108030304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
1. Please explain why this decision is an IETF decision and not a W3C decision, given that it is a choice about what to mandate in the presentation layer as codec, NOT what to mandate for the on-the-wire transport format (which has already been selected as DTLS-SRTP with an appropriate IETF payload based on the application)

2. Should I expect "room-packing" for this "show of hands" (which I don't believe is the typical "hum" process for the IETF, either) as happened during the SDES discussion last time, and therefore need to bring as many people who've not participated in RTCWEB previously but who want my codec to succeed as I can afford to fly to Vancouver?

Matthew Kaufman

On 9/13/2013 9:52 AM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin,
so please review now.  Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be
verified on the mailing list for anyone who can't participate. The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their
presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,  Cullen, and Ted


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

--------------030600080309060108030304-- From martin.thomson@gmail.com Fri Sep 13 10:10:24 2013 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 DE85611E8171 for ; Fri, 13 Sep 2013 10:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2N7wX8DvG-Z for ; Fri, 13 Sep 2013 10:10:23 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E56A911E812F for ; Fri, 13 Sep 2013 10:10:22 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so1092430wib.7 for ; Fri, 13 Sep 2013 10:10:21 -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=meQf1RiNDcyQ0sQiFUQUqX+qqkoZ3mDIRSzxGyZUQC4=; b=oC2W+zlL3O+7z3Zmn6c1YkEi8sVZJx9E1MHkZN6XKcsZXuZwZvuP+UT7qf5ShSQjae +gy3KS1oQPvVFSpaHGDtRrJQN6WJKFlnTdkL/xsEeHPtp55nva73g3OXC1eTsFrgyEad aQw5O0YthDxG5xsWCKwiEcofgJMa0cxzd/JKDw1sZTcrqZ7I1xgxq4EPW5pO7mR59Smp SYiQpW9b7eJ/7NN+DO+FzuL2cRDnLT/yY9xxX3uh7o6VoTSoAA4fE1xpGO6iMwQmvpgQ dxbO5jbp9zlAd6/YX/zF2zLZru0ZZEwfugixb/b9kr+hSDFrRaL3Q5m1qNADxl82IvFg neGA== MIME-Version: 1.0 X-Received: by 10.194.93.3 with SMTP id cq3mr11958991wjb.26.1379092221456; Fri, 13 Sep 2013 10:10:21 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 13 Sep 2013 10:10:21 -0700 (PDT) In-Reply-To: <066.72974763150f699b699079e791c67107@trac.tools.ietf.org> References: <066.72974763150f699b699079e791c67107@trac.tools.ietf.org> Date: Fri, 13 Sep 2013 10:10:21 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Cc: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] #31: Miscellaneous 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, 13 Sep 2013 17:10:24 -0000 On 12 September 2013 17:18, rtcweb issue tracker wrote: > [BA] This text suggests a requirement for the browser to ask user > consent, which seems different from what is in F39: I don't know what question I would ask in this case. Well, at least as far as being able to be understood goes, that is. I'd recommend avoiding this sort of formulation, and would prefer that it simply be possible to avoid exposing IP addresses. From bernard_aboba@hotmail.com Fri Sep 13 10:11:53 2013 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 4B58011E8167 for ; Fri, 13 Sep 2013 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDJljDGajN2x for ; Fri, 13 Sep 2013 10:11:48 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id 640A111E812F for ; Fri, 13 Sep 2013 10:11:48 -0700 (PDT) Received: from BLU169-W111 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Sep 2013 10:11:47 -0700 X-TMN: [IfI0J7O9r8rvGoGlM/D8ZXgNtf77/T0B] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d6f7ac9e-4613-4859-b50b-033764841a88_" From: Bernard Aboba To: Ted Hardie , "rtcweb@ietf.org" Date: Fri, 13 Sep 2013 10:11:47 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2013 17:11:47.0669 (UTC) FILETIME=[545AE050:01CEB0A4] Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 17:11:53 -0000 --_d6f7ac9e-4613-4859-b50b-033764841a88_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted -- The H.264 vs. VP8 discussion has at this point been "overtaken by events"= =2C so that the proposed plan below would be a waste of everybody's time=2C= about as relevant as debating the fashion merits of bell bottoms versus ne= hru jackets. =20 With Google having announced plans to implement VP9 (potentially with SVC)= =2C and with the recent ratification of H.265=2C the industry has moved on= =2C and so should RTCWEB.=20 Date: Fri=2C 13 Sep 2013 09:52:24 -0700 From: ted.ietf@gmail.com To: rtcweb@ietf.org=3B fluffy@cisco.com=3B magnus.westerlund@ericsson.com Subject: [rtcweb] Video Codec Selection Plan WG=2C The chairs have created a plan for how to perform the Video Codec selection in our WG. The chairs are asking for review of our plan on how to undertake the mandatory-to-implement video codec selection. =0A= We'd much prefer to have comments on the mechanics before they begin=2C so please review now. Proponents of a particular proposal should note both the actions required and the timelines proposed. The main goal of this plan is to hold a consensus call on which of =0A= the proposed alternatives we as a WG should select at one of the WG sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate. The chairs will recuse themselves from judging this particular =0A= consensus. In the WG session each codec proposal will be allowed an equal amount of time to highlight the arguments for their proposal. After that a there will be a slot for discussion and clarifying questions. =0A= To enable the WG participants to get answers to any questions=2C the proposals in draft form and any supporting material MUST be made available by 6th of October. This is to ensure that the WG participants can verify or object to any claims or statements in =0A= the proposal material prior to the WG session. We chairs would really not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any arguments on the list ahead of time to enable the proponents to =0A= respond to such arguments. The proposed consensus questions will be of the following form: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI=2C please raise your hand now. =0A= 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI=2C please raise your hand now. You may indicate support on both questions and we encourage you to do so if you can live with either=2C even if you have a preference for one =0A= over the other. Additional proposals than the previous ones are welcome=2C but must be submitted as draft and their proponents must notify the chairs no later than the 6th of October that they also have a candidate proposal. =0A= In case the WG fails to reach consensus we chairs propose that we use the alternative decision process as discussed in RFC3929. The method and its usage will be discussed on the list should the WG not establish consensus on a proposal for mandatory to implement video codec. =0A= regards=2C Magnus=2C Cullen=2C and Ted =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb = --_d6f7ac9e-4613-4859-b50b-033764841a88_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ted --

The H.= 264 vs. VP8 discussion has at this point been "overtaken by events"=2C so t= hat the proposed plan below would be a waste of everybody's time=2C about a= s relevant as debating the fashion merits of bell bottoms versus nehru jack= ets.  =3B

With Google having announced plans t= o implement VP9 (potentially with SVC)=2C and with the recent ratification = of H.265=2C the industry has moved on=2C and so should RTCWEB. =3B

Date: Fri=2C 13 Sep 2013 09:52:24 -0= 700
From: ted.ietf@gmail.com
To: rtcweb@ietf.org=3B fluffy@cisco.com= =3B magnus.westerlund@ericsson.com
Subject: [rtcweb] Video Codec Selecti= on Plan

WG=2C

The chairs have created a= plan for how to perform the Video Codec
selection in our WG. The chairs= are asking for review of our plan on
how to undertake the mandatory-to-= implement video codec selection.
=0A= We'd much prefer to have comments on the mechanics before they begin=2C
= so please review now. =3B Proponents of a particular proposal shouldnote both the actions required and the timelines proposed.

The main= goal of this plan is to hold a consensus call on which of
=0A= the proposed alternatives we as a WG should select at one of the WG
sess= ions in Vancouver. Such a consensus call will of course be
verified on t= he mailing list for anyone who can't participate. The
chairs will recuse= themselves from judging this particular
=0A= consensus.

In the WG session each codec proposal will be allowed an = equal amount
of time to highlight the arguments for their proposal. Afte= r that a
there will be a slot for discussion and clarifying questions.=0A=
To enable the WG participants to get answers to any questions=2C theproposals in draft form and any supporting material MUST be made
availa= ble by 6th of October. This is to ensure that the WG
participants can ve= rify or object to any claims or statements in
=0A= the proposal material prior to the WG session. We chairs would really
no= t like to see the proponents bring up new arguments at their
presentatio= n. Also the WG participants are expected to raise any
arguments on the l= ist ahead of time to enable the proponents to
=0A= respond to such arguments.

The proposed consensus questions will be = of the following form:

1. If you support H.264 as the mandatory to i= mplement codec or are
willing to live with it as the MTI=2C please raise= your hand now.
=0A=
2. If you support VP8 as the mandatory to implement codec or are
wil= ling to live with it as the MTI=2C please raise your hand now.

You m= ay indicate support on both questions and we encourage you to do
so if y= ou can live with either=2C even if you have a preference for one
=0A= over the other.

Additional proposals than the previous ones are welc= ome=2C but must be
submitted as draft and their proponents must notify t= he chairs no later
than the 6th of October that they also have a candida= te proposal.
=0A=
In case the WG fails to reach consensus we chairs propose that we usethe alternative decision process as discussed in RFC3929. The method
a= nd its usage will be discussed on the list should the WG not
establish c= onsensus on a proposal for mandatory to implement video codec.
=0A=
regards=2C

Magnus=2C =3B Cullen=2C and Ted<= br>
=0A=
_______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb
<= /body> = --_d6f7ac9e-4613-4859-b50b-033764841a88_-- From bernard_aboba@hotmail.com Fri Sep 13 10:12:47 2013 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 56A8411E8171 for ; Fri, 13 Sep 2013 10:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAdB0jVVSxSL for ; Fri, 13 Sep 2013 10:12:41 -0700 (PDT) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA9911E8167 for ; Fri, 13 Sep 2013 10:12:41 -0700 (PDT) Received: from BLU169-W111 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Sep 2013 10:12:40 -0700 X-TMN: [ljSSSNMlcCwGceqAmjzrkAnUmu7snsUc] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bbd9b21e-c2a7-4b50-bb2b-dc0265c0c622_" From: Bernard Aboba To: Martin Thomson , "rtcweb@ietf.org" Date: Fri, 13 Sep 2013 10:12:40 -0700 Importance: Normal In-Reply-To: References: <066.72974763150f699b699079e791c67107@trac.tools.ietf.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2013 17:12:40.0865 (UTC) FILETIME=[740FF110:01CEB0A4] Cc: "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" Subject: Re: [rtcweb] #31: Miscellaneous 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, 13 Sep 2013 17:12:47 -0000 --_bbd9b21e-c2a7-4b50-bb2b-dc0265c0c622_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said:=20 > I don't know what question I would ask in this case. Well=2C at least > as far as being able to be understood goes=2C that is. I'd recommend > avoiding this sort of formulation=2C and would prefer that it simply be > possible to avoid exposing IP addresses. [BA] That is my conclusion as well. = --_bbd9b21e-c2a7-4b50-bb2b-dc0265c0c622_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said: =3B
<= div>
>=3B I don't know what question I would ask in this case. Well= =2C at least
>=3B as far as being able to be understood goes=2C that i= s. I'd recommend
>=3B avoiding this sort of formulation=2C and would = prefer that it simply be
>=3B possible to avoid exposing IP addresses.=

[BA] That is my conclusion as well. =3B
= --_bbd9b21e-c2a7-4b50-bb2b-dc0265c0c622_-- From ibc@aliax.net Fri Sep 13 10:21:45 2013 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 A301711E80FC for ; Fri, 13 Sep 2013 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KARUQt7K68IK for ; Fri, 13 Sep 2013 10:21:41 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 49F3E21F9FC6 for ; Fri, 13 Sep 2013 10:21:41 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so1050634qcw.2 for ; Fri, 13 Sep 2013 10:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W4X/UCSG/SRnOZjUSO56h69fd4euA3+QTac6DY1SnpQ=; b=GtPzEnG3pt7Kv55M5TcQl07c8kTSiQirrsC9kv9VfY98cqkTqZ6toqf5SKPfY49OPH SqYQWKTRp5AuoANtwh4sC9hjBqFNd2cL0QuY5LvHzU0wJe/40k0EVDgrLPr0N9BtuVNQ O0A5fxs+9RDI8xONXQCwIUPXlUCuqi6FoQ1tsDtlYdLHYt1M+bXNcfhLy1rJaIq3Chq8 TzSNa0PYzz2rOwTb5NzKEQcB0GBZKtrWsc/mTSeZLuSRWqGGh+DDtpKDSKfKKMQZ8+Hh YHhFfXDq9J2Ucx98jh7HNzIGPJDJnBuGtEhY1KES5hlIAGF8v+G1hPio+H4UCTuuQgD7 uw5A== X-Gm-Message-State: ALoCoQn3opsjkJIIgO0b0EM2UwraT0/YHw0O+wGe1n25hOaB0SFyXbieMqaM7Xhu/OtMtR39BM6a MIME-Version: 1.0 X-Received: by 10.49.99.98 with SMTP id ep2mr27248967qeb.9.1379092899454; Fri, 13 Sep 2013 10:21:39 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Fri, 13 Sep 2013 10:21:39 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Fri, 13 Sep 2013 10:21:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 19:21:39 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7bd76bb462972304e64716fe Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 17:21:45 -0000 --047d7bd76bb462972304e64716fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do not take me wrong, but IMHO this decision should be taken by the W3C WebRTC group. -- I=C3=B1aki Baz Castillo El 13/09/2013 18:52, "Ted Hardie" escribi=C3=B3: > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd76bb462972304e64716fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Do not take me wrong, but IMHO this decision should be taken= by the W3C WebRTC group.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 13/09/2013 18:52, "Ted Hardie" <= ted.ietf@gmail.com> escribi=C3= =B3:
WG,

The chairs have created a plan for how to = perform the Video Codec
selection in our WG. The chairs are asking for r= eview of our plan on
how to undertake the mandatory-to-implement video c= odec selection.
We'd much prefer to have comments on the mechanics before they begin,so please review now.=C2=A0 Proponents of a particular proposal shouldnote both the actions required and the timelines proposed.

The main= goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sess= ions in Vancouver. Such a consensus call will of course be
verified on t= he mailing list for anyone who can't participate. The
chairs will re= cuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an = equal amount
of time to highlight the arguments for their proposal. Afte= r that a
there will be a slot for discussion and clarifying questions.
To enable the WG participants to get answers to any questions, the
p= roposals in draft form and any supporting material MUST be made
availabl= e by 6th of October. This is to ensure that the WG
participants can veri= fy or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
no= t like to see the proponents bring up new arguments at their
presentatio= n. Also the WG participants are expected to raise any
arguments on the l= ist ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be = of the following form:

1. If you support H.264 as the mandatory to i= mplement codec or are
willing to live with it as the MTI, please raise y= our hand now.

2. If you support VP8 as the mandatory to implement codec or are
wil= ling to live with it as the MTI, please raise your hand now.

You may= indicate support on both questions and we encourage you to do
so if you= can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welc= ome, but must be
submitted as draft and their proponents must notify the= chairs no later
than the 6th of October that they also have a candidate= proposal.

In case the WG fails to reach consensus we chairs propose that we usethe alternative decision process as discussed in RFC3929. The method
a= nd its usage will be discussed on the list should the WG not
establish c= onsensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=C2=A0 Cullen, and Ted

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

--047d7bd76bb462972304e64716fe-- From giles@thaumas.net Fri Sep 13 10:41:37 2013 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 C7D1211E81B6 for ; Fri, 13 Sep 2013 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk-RI12-2xPn for ; Fri, 13 Sep 2013 10:41:31 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6E11E81AB for ; Fri, 13 Sep 2013 10:41:31 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so1521072pdj.8 for ; Fri, 13 Sep 2013 10:41:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z0wcGcrf65BuQyA4xldLD8xaRpVvcc6DtsUcPxoUzFQ=; b=kb2Qi1tny2C33ZPC0A3wMXRO9pAnZDxs0mhd+vgYeeCgDXZ2zYzLAlB0mivPNp7xDt 969CjeBhWXkYbk6Cdau/tjLWLR2YQPWCRl42CNj2pNKcOVYsT3uN86UIl3OPr2Kdloo0 Ue2+qZq0vK0ZOk1HTpfDBeeADtm5M3i3BJ1aMHeN1ZDWs0uvEhunsxquvzXXGs6MNjM0 mmOy5IiK9QuGYB0ZS0yIKUYkmKZBoPd6ruv/pq4UuWBs0CnmXzq5xwayUdPfo6nwCOab Op/8h2yPNvjSW8XTlQdwvFdCD3vZ7h+M6h4CZ3qTG9koIkCi+ulVyTKeWGZC2Bzsi0l5 C1XQ== X-Gm-Message-State: ALoCoQnRR9PrCABG+ootJg86YM2MyEWgOR3gnhU8OMjJqfDkrGQJfGJJlZoSlJj1x5d6kn9MRQak X-Received: by 10.68.137.1 with SMTP id qe1mr14898740pbb.25.1379094085367; Fri, 13 Sep 2013 10:41:25 -0700 (PDT) Received: from Glaucomys.local (static-68-179-67-77.ptr.terago.net. [68.179.67.77]) by mx.google.com with ESMTPSA id in2sm13054752pbc.37.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 10:41:25 -0700 (PDT) Message-ID: <52334E48.8040703@thaumas.net> Date: Fri, 13 Sep 2013 10:41:28 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52334462.608@matthew.at> In-Reply-To: <52334462.608@matthew.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 17:41:37 -0000 On 13-09-13 9:59 AM, Matthew Kaufman wrote: > 1. Please explain why this decision is an IETF decision and not a W3C > decision, given that it is a choice about what to mandate in the > presentation layer as codec, NOT what to mandate for the on-the-wire > transport format (which has already been selected as DTLS-SRTP with an > appropriate IETF payload based on the application) This working group selected OPUS and G711 as MTI audio codecs to avoid session negotiation failure. Session negotiation being part of the WebRTC protocol suite being specified within the IETF. The same arguments apply to a video codec. If we can find rough consensus to specify one it is useful to do so. -r From ted.ietf@gmail.com Fri Sep 13 10:48:24 2013 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 8C67F21F9C76 for ; Fri, 13 Sep 2013 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5UtUxgWHJDQ for ; Fri, 13 Sep 2013 10:48:13 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4D321E8115 for ; Fri, 13 Sep 2013 10:47:58 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so3133743iet.5 for ; Fri, 13 Sep 2013 10:47:51 -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=r+SR8NPfS56FfTTm/JeyhxBg+Zhovr8gSUUi8cUWiNU=; b=Deak2C+/WSM/YHrUzch2c0O04SaFDmf2DJlzURd8UhlntOvj3EWhbI152BrVQIR/Wp DZZPo4QVib+HzY6EgkbjrVj4OPoDl0OCb39KZktEC0EM9VZbFXbfaDuTh20lfMaS3NPY xL6xcV/7RJrO19QWRmqxEGVASkG2D8u2upvrJX2p/gK84VuP5zSbdqqrDToGTu7P3i1G jUf9s+yofwHAISPFL9f7fV+2II3OR4+wrwuhJzoBNSNGcN+pa/XtyqVW6HJMaiyNDEhO n1HiCxkWylFvahoxiq7yYHbeAlRoiBGXii5ZEfmayB9vThig4vwvIKKdZaXyRqrDd/J9 KUfg== MIME-Version: 1.0 X-Received: by 10.50.111.197 with SMTP id ik5mr1776447igb.19.1379094471598; Fri, 13 Sep 2013 10:47:51 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 13 Sep 2013 10:47:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 10:47:51 -0700 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b4142d6178d5e04e6477451 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 17:48:25 -0000 --047d7b4142d6178d5e04e6477451 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 13, 2013 at 10:11 AM, Bernard Aboba wrote: > Ted -- > > The H.264 vs. VP8 discussion has at this point been "overtaken by events", > so that the proposed plan below would be a waste of everybody's time, about > as relevant as debating the fashion merits of bell bottoms versus nehru > jackets. > > With Google having announced plans to implement VP9 (potentially with > SVC), and with the recent ratification of H.265, the industry has moved on, > and so should RTCWEB. > > Hi Bernard, The agreement to specify a mandatory-to-implement video codec to avoid negotiation failure is a very long standing one. If you believe the MTI should be VP9 or H.265, you are welcome to propose either; please do so, however, in the form of a draft by October 6th so we can move forward knowing that it is your proposal. regards, Ted Hardie > ------------------------------ > Date: Fri, 13 Sep 2013 09:52:24 -0700 > From: ted.ietf@gmail.com > To: rtcweb@ietf.org; fluffy@cisco.com; magnus.westerlund@ericsson.com > Subject: [rtcweb] Video Codec Selection Plan > > > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b4142d6178d5e04e6477451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 10:11 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Ted --

The H.264 vs. VP8 discussio= n has at this point been "overtaken by events", so that the propo= sed plan below would be a waste of everybody's time, about as relevant = as debating the fashion merits of bell bottoms versus nehru jackets. =A0

With Google having announced plans to implement VP9 (po= tentially with SVC), and with the recent ratification of H.265, the industr= y has moved on, and so should RTCWEB.=A0


Hi Bernard,

The agreement to specif= y a mandatory-to-implement video codec to avoid negotiation failure is a ve= ry long standing one.=A0 If you believe the MTI should be VP9 or H.265, you= are welcome to propose either; please do so, however, in the form of a dra= ft by October 6th so we can move forward knowing that it is your proposal.<= br>
regards,

Ted Hardie

=A0
Date: Fri, 13 Sep 2013 09= :52:24 -0700
From: ted.ietf@gmai= l.com
To: rtcwe= b@ietf.org; fluff= y@cisco.com; magnus.westerlund@ericsson.com
Subject: [rtcweb] Video Codec Selection Plan


=
WG,

The chairs have created a plan for how to = perform the Video Codec
selection in our WG. The chairs are asking for r= eview of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin,so please review now.=A0 Proponents of a particular proposal should
no= te both the actions required and the timelines proposed.

The main go= al of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sess= ions in Vancouver. Such a consensus call will of course be
verified on t= he mailing list for anyone who can't participate. The
chairs will re= cuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an = equal amount
of time to highlight the arguments for their proposal. Afte= r that a
there will be a slot for discussion and clarifying questions.
To enable the WG participants to get answers to any questions, the
p= roposals in draft form and any supporting material MUST be made
availabl= e by 6th of October. This is to ensure that the WG
participants can veri= fy or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
no= t like to see the proponents bring up new arguments at their
presentatio= n. Also the WG participants are expected to raise any
arguments on the l= ist ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be = of the following form:

1. If you support H.264 as the mandatory to i= mplement codec or are
willing to live with it as the MTI, please raise y= our hand now.

2. If you support VP8 as the mandatory to implement codec or are
wil= ling to live with it as the MTI, please raise your hand now.

You may= indicate support on both questions and we encourage you to do
so if you= can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welc= ome, but must be
submitted as draft and their proponents must notify the= chairs no later
than the 6th of October that they also have a candidate= proposal.

In case the WG fails to reach consensus we chairs propose that we usethe alternative decision process as discussed in RFC3929. The method
a= nd its usage will be discussed on the list should the WG not
establish c= onsensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=A0 Cullen, and Ted

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

--047d7b4142d6178d5e04e6477451-- From ibc@aliax.net Fri Sep 13 11:01:02 2013 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 0E2B421E811A for ; Fri, 13 Sep 2013 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUCY8rfZ8jqY for ; Fri, 13 Sep 2013 11:00:55 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0772021E80D8 for ; Fri, 13 Sep 2013 11:00:13 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id cy11so1276433qeb.13 for ; Fri, 13 Sep 2013 11:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tzvl/xfgaTYyOpx7zJyjhpJQUCcchloPGCPTNS6URrg=; b=dYt93ZtwjSEDObCB/SDpMYlQ+30mIunnq6n6XT4yvs67fwCSRSQ5uX2iFhQfn+gXb3 JI/OOj9ojvJ7h4rSMJtUIuJHNN95igMYf1AjpRshKAyDk4wTVDacwIZvvESJg5rc6PPT qSPJvveP87dWZLkC5gAPT7dgiXy98ZLjiLfqwZZkWxrv8o/s6TdRQyXqobH3qgloEX6S Ynq+bd6sZsxbSksE7HqVB3g+tR2O6YY6koRhKjdUMSHkYcDkPXFmAyw0BgNvFEJO/MDe 7i8XBM4LKjUUISalPtW8BUJBLoGqrd3g/CzQjFbWh/MfOhT5s7RIpKkw2YJNxX7mXPer CiFw== X-Gm-Message-State: ALoCoQlpSafAD1g+jHUGjzEDu6Tg7PVDzs8j5GZYGUekgxqON2JwRd/C8Pi+ZCyFYUYJUQxoNI0V MIME-Version: 1.0 X-Received: by 10.229.24.130 with SMTP id v2mr27301537qcb.15.1379095205516; Fri, 13 Sep 2013 11:00:05 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Fri, 13 Sep 2013 11:00:05 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Fri, 13 Sep 2013 11:00:05 -0700 (PDT) In-Reply-To: <52334E48.8040703@thaumas.net> References: <52334462.608@matthew.at> <52334E48.8040703@thaumas.net> Date: Fri, 13 Sep 2013 20:00:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ralph Giles Content-Type: multipart/alternative; boundary=001a1133b8fcd652e404e6479fdd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 18:01:02 -0000 --001a1133b8fcd652e404e6479fdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 13/09/2013 19:41, "Ralph Giles" escribi=C3=B3: > > On 13-09-13 9:59 AM, Matthew Kaufman wrote: > > 1. Please explain why this decision is an IETF decision and not a W3C > > decision, given that it is a choice about what to mandate in the > > presentation layer as codec, NOT what to mandate for the on-the-wire > > transport format (which has already been selected as DTLS-SRTP with an > > appropriate IETF payload based on the application) > > This working group selected OPUS and G711 as MTI audio codecs to avoid > session negotiation failure. Session negotiation being part of the > WebRTC protocol suite being specified within the IETF. > > The same arguments apply to a video codec. If we can find rough > consensus to specify one it is useful to do so. One error does not justify another one. --001a1133b8fcd652e404e6479fdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 13/09/2013 19:41, "Ralph Giles" <giles@thaumas.net> escribi=C3=B3:
>
> On 13-09-13 9:59 AM, Matthew Kaufman wrote:
> > 1. Please explain why this decision is an IETF decision and not a= W3C
> > decision, given that it is a choice about what to mandate in the<= br> > > presentation layer as codec, NOT what to mandate for the on-the-w= ire
> > transport format (which has already been selected as DTLS-SRTP wi= th an
> > appropriate IETF payload based on the application)
>
> This working group selected OPUS and G711 as MTI audio codecs to avoid=
> session negotiation failure. Session negotiation being part of the
> WebRTC protocol suite being specified within the IETF.
>
> The same arguments apply to a video codec. If we can find rough
> consensus to specify one it is useful to do so.

One error does not justify another one.

--001a1133b8fcd652e404e6479fdd-- From bernard_aboba@hotmail.com Fri Sep 13 11:07:01 2013 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 DB20D11E812F for ; Fri, 13 Sep 2013 11:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5+mK2uDx+wv for ; Fri, 13 Sep 2013 11:06:53 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9948B21F9AED for ; Fri, 13 Sep 2013 11:06:52 -0700 (PDT) Received: from BLU169-W76 ([65.55.111.73]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Sep 2013 11:06:41 -0700 X-TMN: [T7hbGN8jLNSRFL1B7AnzegHr0d1qmIiA] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_dc46c097-d47f-4247-8a06-92140ae640a3_" From: Bernard Aboba To: Ted Hardie Date: Fri, 13 Sep 2013 11:06:40 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2013 18:06:41.0276 (UTC) FILETIME=[FF7F6BC0:01CEB0AB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 18:07:01 -0000 --_dc46c097-d47f-4247-8a06-92140ae640a3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted said: "If you believe the MTI should be VP9 or H.265=2C you are welcome to propos= e either=3B please do so" [BA] I am not prepared to argue for (or against) either VP9 or H.265 at thi= s time=2C and I believe that many industry colleagues would say the same. = In a way=2C that is the point -- minds have not yet been made up=2C as in (= many cases) they have been on the topic of VP8 vs. H.264. =20 "It's not only generals who fight the last war" -- Dan Gardner = --_dc46c097-d47f-4247-8a06-92140ae640a3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ted said:

"If you believe the MTI should b= e VP9 or H.265=2C you are welcome to propose either=3B please do so"=

[BA] I am not prepared to argue for (or against) = either VP9 or H.265 at this time=2C and I believe that many industry collea= gues would say the same.  =3BIn a way=2C that is the point -- minds hav= e not yet been made up=2C as in (many cases) they have been on the topic of= VP8 vs. H.264.  =3B

"It's not only generals w= ho fight the last war" -- Dan Gardner
= --_dc46c097-d47f-4247-8a06-92140ae640a3_-- From adam@nostrum.com Fri Sep 13 11:07:14 2013 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 9E8A721E811F for ; Fri, 13 Sep 2013 11:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xlkG367i341 for ; Fri, 13 Sep 2013 11:07:13 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 629DE21E811C for ; Fri, 13 Sep 2013 11:07:13 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8DI76wc056251 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 13:07:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52335445.90907@nostrum.com> Date: Fri, 13 Sep 2013 13:07:01 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030706050809060502040705" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 18:07:15 -0000 This is a multi-part message in MIME format. --------------030706050809060502040705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/13/13 12:11, Bernard Aboba wrote: > With Google having announced plans to implement VP9 (potentially with > SVC), and with the recent ratification of H.265, the industry has > moved on... At which point we need to ask whether we're trying to pick "the best possible codec" or "a suitable codec." If the former, then your point is relevant. But I don't think there's consensus (rough or otherwise) around "best possible codec" being the goal. /a --------------030706050809060502040705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 9/13/13 12:11, Bernard Aboba wrote:
With Google having announced plans to implement VP9 (potentially with SVC), and with the recent ratification of H.265, the industry has moved on...

At which point we need to ask whether we're trying to pick "the best possible codec" or "a suitable codec." If the former, then your point is relevant. But I don't think there's consensus (rough or otherwise) around "best possible codec" being the goal.

/a

--------------030706050809060502040705-- From fluffy@cisco.com Fri Sep 13 12:03:55 2013 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 9464121F8488 for ; Fri, 13 Sep 2013 12:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPFeOtPoaF7i for ; Fri, 13 Sep 2013 12:03:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9E21F8423 for ; Fri, 13 Sep 2013 12:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=448; q=dns/txt; s=iport; t=1379099005; x=1380308605; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/b5/Adr0C6wiDOok1yleJv6t7wAY9JE3dJdjAagkQ7I=; b=MqdwEqBPxIjxNx/PXcIAw8kv4wNQskRcbBBrYMCwQNJOXJPIvZwFqLsQ 5Gle2Ezb/262fyw7d2Rw0GWNfk0ZmHQYvVymuCe3nOr0fOCyDU4p3Hg7D iuACkzvbecUH9xxj8ThUoGoKeZ0/xkLwe8Garr15NpGfUuoJnjVAir0og c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAPZgM1KtJV2Z/2dsb2JhbABbgweBCoJjvhiBHBZ0giUBAQEDAXkFCwIBCCIkMiUCBA4FCId1BrlHjz4CMQeDHoEAA4kAoG6DJIIq X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208";a="259299543" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 13 Sep 2013 19:03:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8DJ3PA8007678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 19:03:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 14:03:24 -0500 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Video Codec Selection Plan Thread-Index: AQHOsLPruYV95TlmRkqxvkC4jw2kPg== Date: Fri, 13 Sep 2013 19:03:24 +0000 Message-ID: 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.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <678266118F29544B8023D2A71CE45B0A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 19:03:55 -0000 That topic was discussed between W3C and IETF when forming the two WG and v= ery clear decisions was made that the W3C would not make that decision. Par= t of the reasons had to do with the history of a very similar argument at W= 3C around the video tag.=20 On Sep 13, 2013, at 11:21 AM, I=F1aki Baz Castillo wrote: > Do not take me wrong, but IMHO this decision should be taken by the W3C W= ebRTC group. >=20 >=20 From matthew.kaufman@skype.net Fri Sep 13 12:43:20 2013 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 C3AA221E80F1 for ; Fri, 13 Sep 2013 12:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61uqWpiwbI9C for ; Fri, 13 Sep 2013 12:43:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id CB93B21E80DD for ; Fri, 13 Sep 2013 12:43:15 -0700 (PDT) Received: from BY2PR03CA035.namprd03.prod.outlook.com (10.242.234.156) by BY2PR03MB141.namprd03.prod.outlook.com (10.242.35.143) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 13 Sep 2013 19:43:12 +0000 Received: from BN1BFFO11FD022.protection.gbl (2a01:111:f400:7c10::143) by BY2PR03CA035.outlook.office365.com (2a01:111:e400:2c2c::28) with Microsoft SMTP Server (TLS) id 15.0.775.9 via Frontend Transport; Fri, 13 Sep 2013 19:43:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.53.82) with Microsoft SMTP Server (TLS) id 15.0.755.13 via Frontend Transport; Fri, 13 Sep 2013 19:43:11 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.222]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Fri, 13 Sep 2013 19:42:45 +0000 From: "Matthew Kaufman (SKYPE)" To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Video Codec Selection Plan Thread-Index: AQHOsKGn1VGs8vczk0uUtIwsFTEk4JnD6iaAgAAcbgCAAAr+bg== Date: Fri, 13 Sep 2013 19:42:44 +0000 Message-ID: <01D307B1-60B9-4580-8A40-8B755BFB5586@skype.net> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454002)(189002)(199002)(51704005)(377454003)(51856001)(79102001)(56816003)(56776001)(83072001)(59766001)(77982001)(54316002)(19580395003)(83322001)(19580405001)(53806001)(77096001)(76482001)(54356001)(44976005)(6806004)(76796001)(81686001)(15975445006)(80022001)(76786001)(36756003)(50466002)(33656001)(81816001)(82746002)(65816001)(69226001)(80976001)(23756003)(74706001)(74876001)(47776003)(47736001)(20776003)(46102001)(63696002)(81542001)(74662001)(31966008)(49866001)(47976001)(50986001)(4396001)(81342001)(74366001)(47446002)(74502001)(83716001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB141; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0968D37274 X-OriginatorOrg: DuplicateDomain-9e79206f-3253-44e7-9aa6-8e1280886b67.skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 19:43:20 -0000 The W3C was the right venue for the video tag codec discussion, just like i= t is for this video codec discussion. I'll note that the chairs have repeatedly pointed out that the scope is exp= licitly "browsers" Matthew Kaufman (Sent from my iPhone) On Sep 13, 2013, at 12:05 PM, "Cullen Jennings (fluffy)" = wrote: >=20 > That topic was discussed between W3C and IETF when forming the two WG and= very clear decisions was made that the W3C would not make that decision. P= art of the reasons had to do with the history of a very similar argument at= W3C around the video tag.=20 >=20 > On Sep 13, 2013, at 11:21 AM, I=F1aki Baz Castillo wrote: >=20 >> Do not take me wrong, but IMHO this decision should be taken by the W3C = WebRTC group. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From presnick@qti.qualcomm.com Fri Sep 13 11:50:44 2013 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 B0A3021E80DD for ; Fri, 13 Sep 2013 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.247 X-Spam-Level: X-Spam-Status: No, score=-106.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+9Fa-962kfd for ; Fri, 13 Sep 2013 11:50:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7F21E80D8 for ; Fri, 13 Sep 2013 11:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1379098238; x=1410634238; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=DDVQSRsJe9FiV0wU93VXcJG7xCWY1YL8C9MWbQxFSCE=; b=F+qpHFOD/IbiwCR975PwZIBtAcgYNbyeLWDIlb7wDvm1bLfixWep3JGH TaUuKjcvvaliW5Vv9QEbgHn5MjMCqat7NKejyOvI3hNmXiP8aGtOw9TPm flD4F1pN7qNdEL5BnW6F1HmvxXCroR7SGt1YnKYuwzI21bH7L/bPFfDFn w=; X-IronPort-AV: E=McAfee;i="5400,1158,7197"; a="74449410" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 13 Sep 2013 11:50:34 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7197"; a="511525173" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Sep 2013 11:50:34 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 13 Sep 2013 11:50:34 -0700 Message-ID: <52335E78.2080406@qti.qualcomm.com> Date: Fri, 13 Sep 2013 13:50:32 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <52334462.608@matthew.at> In-Reply-To: <52334462.608@matthew.at> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Fri, 13 Sep 2013 13:19:48 -0700 Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 18:50:44 -0000 Big caveat as I post this: I am speaking strictly as an IETF participant. In particular: - I am not speaking as an AD. I am not the responsible AD for this WG, and the chairs can go ahead with their proposed path forward consulting with the WG's responsible AD, whatever they think of what I say below. No implication of any authority should be taken here. - Though my comments here are clearly informed by the draft some of you know that I'm working on regarding consensus, that draft does not represent accepted theory in the IETF, so I'm not appealing to it as some sort of "given truth" on this. I'm just another participant in the room. All that said, I am concerned about the path being proposed, and I agree with Matthew's concern (though I feel somewhat less defeatist than his assessment sounds): On 9/13/13 11:59 AM, Matthew Kaufman wrote: > 2. Should I expect "room-packing" for this "show of hands" (which I > don't believe is the typical "hum" process for the IETF, either) as > happened during the SDES discussion last time, and therefore need to > bring as many people who've not participated in RTCWEB previously but > who want my codec to succeed as I can afford to fly to Vancouver? I think this is a valid concern. Asking "who wants or can live with VP8?" and "who wants or can live with H.264?" might be a good start to the discussion, but at that point, I'm going to want to hear *why* people *can't* live with one or the other. What I would *not* be interested in is yet another presentation from the proponents of either of these to tell me why one is better; I want to hear from *opponents* of the proposal to hear why the proposal would fail. Only then would I want to hear from proponents responding to those objections. And then I'd like to see a summary of those objections and those responses by the chairs. With that summary, the chairs can make a call of whether there is any hope of consensus. I think much of that work can and should take place on the mailing list *before* the face-to-face meeting. But asking for a show of hands in the room for people who "can live with" one or the other and deciding whether or not consensus exists based on that show of hands is simply taking a vote, it's not judging consensus. You cannot know from that result whether the reason that some people could not "live with" a proposal was simply because "my Aunt Gertrude told me that I should say that I can't live with it." To ask for the show of hands and then not find out what it means is not calling the consensus. And I think moving to a 3929 alternative on the basis of that show of hands would be improper. Put me down as one voice who objects to the proposed procedure. pr > On 9/13/2013 9:52 AM, Ted Hardie wrote: >> WG, >> >> The chairs have created a plan for how to perform the Video Codec >> selection in our WG. The chairs are asking for review of our plan on >> how to undertake the mandatory-to-implement video codec selection. >> We'd much prefer to have comments on the mechanics before they begin, >> so please review now. Proponents of a particular proposal should >> note both the actions required and the timelines proposed. >> >> The main goal of this plan is to hold a consensus call on which of >> the proposed alternatives we as a WG should select at one of the WG >> sessions in Vancouver. Such a consensus call will of course be >> verified on the mailing list for anyone who can't participate. The >> chairs will recuse themselves from judging this particular >> consensus. >> >> In the WG session each codec proposal will be allowed an equal amount >> of time to highlight the arguments for their proposal. After that a >> there will be a slot for discussion and clarifying questions. >> >> To enable the WG participants to get answers to any questions, the >> proposals in draft form and any supporting material MUST be made >> available by 6th of October. This is to ensure that the WG >> participants can verify or object to any claims or statements in >> the proposal material prior to the WG session. We chairs would really >> not like to see the proponents bring up new arguments at their >> presentation. Also the WG participants are expected to raise any >> arguments on the list ahead of time to enable the proponents to >> respond to such arguments. >> >> The proposed consensus questions will be of the following form: >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> You may indicate support on both questions and we encourage you to do >> so if you can live with either, even if you have a preference for one >> over the other. >> >> Additional proposals than the previous ones are welcome, but must be >> submitted as draft and their proponents must notify the chairs no later >> than the 6th of October that they also have a candidate proposal. >> >> In case the WG fails to reach consensus we chairs propose that we use >> the alternative decision process as discussed in RFC3929. The method >> and its usage will be discussed on the list should the WG not >> establish consensus on a proposal for mandatory to implement video codec. >> >> regards, >> >> Magnus, Cullen, and Ted -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sergio.garcia.murillo@gmail.com Fri Sep 13 13:26:48 2013 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 94ABC21E80AA; Fri, 13 Sep 2013 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFkq1zmm4Vyr; Fri, 13 Sep 2013 13:26:48 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB511E80D3; Fri, 13 Sep 2013 13:26:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cb5so1493469wib.5 for ; Fri, 13 Sep 2013 13:26:46 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zEAFsAknO6Ny6IEJMIFaHrzOSyYDIfQx3frVMqUYlaU=; b=nin+xzPGu/jYGn2zHrQkpvrIdbvNVjSYBFOXbWPJCIR173mSWurqGeKF1L5A6B8TzC 3TKZvreDZCFbFDowrfsvbe3lWnuzHtcXrtA/dAzr8L8ofiXNv6m6j5rfETNEbzS7TC3J epqhBICkTSDC13NpUF/VaFiEAkVeJb01hw+NJdlk2IgkvZqBuoWAPAES9P7ookg21JqI oqwDiCLFOmbSdVkSYi5iGx0d5BdBRe0Gsh5gnuhz6Azl3Hy4pIu7vki88rhFzQuQe5OV XBEf2zidPII/86HQqNrR3Yy4xu03yNFqQFvAjS5cMnp5KHE5n6Ds7svo+5IopyMg8EQn VVJQ== X-Received: by 10.180.206.180 with SMTP id lp20mr3986899wic.48.1379104006702; Fri, 13 Sep 2013 13:26:46 -0700 (PDT) Received: from [192.168.1.55] (76.Red-88-6-196.staticIP.rima-tde.net. [88.6.196.76]) by mx.google.com with ESMTPSA id gp9sm5887800wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 13:26:46 -0700 (PDT) Message-ID: <52337505.9000109@gmail.com> Date: Fri, 13 Sep 2013 22:26:45 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> In-Reply-To: <5232D9A2.8050800@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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, 13 Sep 2013 20:26:48 -0000 El 13/09/2013 11:23, Simon Perreault escribió: > Le 2013-09-13 10:58, Chenxin (Xin) a écrit : >> We have been working on a new version of the TURN over Websocket >> draft, which is now available at: >> >> http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt > > There are two major things missing in this draft: > > - How are TURN UDP "channels" supported? (See RFC 5766 section 2.5.) > > - How are TURN TCP "data connections" supported? (See RFC 6062 section > 3.) > > I think the answers to these questions will greatly affect the overall > design of TURN-over-WebSocket. > > Hi Simon, As per RFC 5766: For some applications (e.g., Voice over IP), the 36 bytes of overhead that a Send indication or Data indication adds to the application data can substantially increase the bandwidth required between the client and the server. To remedy this, TURN offers a second way for the client and server to associate data with a specific peer. This second way uses an alternate packet format known as the ChannelData message. The ChannelData message does not use the STUN header used by other TURN messages, but instead has a 4-byte header that includes a number known as a channel number. So, at the end, the ChannelData message is just another TURN message, so it will be encapsulated inside a websocket frame. If you feel it is not clear, we can add more details about it in next draft. Regarding RFC 6062, we had some internal discussion regarding if we should add websocket support at all to it or not. Mainly, because AFAIK, webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am wrong. I agree with you that this has not been well covered in the draft. In order to make the minimun changes possible, and align it with the general view of changing just the turn client to turn server encapsulation protocol, I would propose to extend websockets usage only for the turn control connection in RFC 6062 but keep turn data connections on TCP. That, or drop RFC 6062 extension altogether and just focus on 5766. What do you feel it would be best? Best regards Sergio From ted.ietf@gmail.com Fri Sep 13 13:45:52 2013 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 1884311E80D7 for ; Fri, 13 Sep 2013 13:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufv4wO4n2By8 for ; Fri, 13 Sep 2013 13:45:38 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92411E80D5 for ; Fri, 13 Sep 2013 13:45:38 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so3586750iet.19 for ; Fri, 13 Sep 2013 13:45:36 -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=wVdcCa7P++1cXgtyse/sQHTXUvnCeTZlNKvrNzja3NA=; b=p1pJgT+AYiDJmFGSxTT/4VoggGt+BbDCTDn8xGDHW0RXdMSkk+KizGaeA4pP5RVPiB Vc1U6NkmE5nNBQYTqpc9rPKRhR6ZZ3agnsDk2MguMiLVzuhTUi5MVQe90mcFPfSNM/Ga 3dPQ2GriOz4NJjjmembAFXfJ04krEhylgGVIb0uD8v25upSwIdy9TTz7XtF9FtzAy6Yx kovS1C/63zw7SpvxU/wtfuh9XpimtZiBAeVBe3ZxRgraFV1OU/9wGt51hcwIiDTCjnYZ 6HkIQRbetfsEmGpgjaRo0JgsXD6opc+FCYBHcRW0ZJPngX3oGgobWJiECIxpJUMHhJk5 FDwg== MIME-Version: 1.0 X-Received: by 10.50.111.197 with SMTP id ik5mr2028628igb.19.1379105136748; Fri, 13 Sep 2013 13:45:36 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 13 Sep 2013 13:45:36 -0700 (PDT) In-Reply-To: <52335E78.2080406@qti.qualcomm.com> References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> Date: Fri, 13 Sep 2013 13:45:36 -0700 Message-ID: From: Ted Hardie To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b4142d6c8b0c704e649ef1b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 20:45:52 -0000 --047d7b4142d6c8b0c704e649ef1b Content-Type: text/plain; charset=ISO-8859-1 Howdy, I've now had lunch and nice coffee, and I take electrons in hand to answer your missive, sent earlier today. On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick wrote: > Big caveat as I post this: I am speaking strictly as an IETF participant. > In particular: > > > All that said, I am concerned about the path being proposed, and I agree > with Matthew's concern (though I feel somewhat less defeatist than his > assessment sounds): > > > On 9/13/13 11:59 AM, Matthew Kaufman wrote: > >> 2. Should I expect "room-packing" for this "show of hands" (which I don't >> believe is the typical "hum" process for the IETF, either) as happened >> during the SDES discussion last time, and therefore need to bring as many >> people who've not participated in RTCWEB previously but who want my codec >> to succeed as I can afford to fly to Vancouver? >> > > I think this is a valid concern. Asking "who wants or can live with VP8?" > and "who wants or can live with H.264?" might be a good start to the > discussion, but at that point, I'm going to want to hear *why* people > *can't* live with one or the other. That discussion is supposed to happen before this, not after, so that if there are issues which might be resolved, they can be. During the course of the effort to find a solution here, there have been several such resolutions (Cisco, for example, graciously agreed to provide an open source H.264 implementation should it be selected, in order to handle objections that none were available). If there are issues which cannot be resolved, having a second discussion on what they are amounts to re-hashing and doesn't do anything to move things forward. > What I would *not* be interested in is yet another presentation from the > proponents of either of these to tell me why one is better; One might surmise that this is because you do not intend to actually build, deploy, or operate a service that relates to this. If someone puts forward a codec that is better (in human assessment, lines of code, or operating requirements) and meets the other criteria for deployment, why wouldn't you want to hear about it? > I want to hear from *opponents* of the proposal to hear why the proposal > would fail. Only then would I want to hear from proponents responding to > those objections. And then I'd like to see a summary of those objections > and those responses by the chairs Pete, my dear mangel-wurzel and apple of my eye, that's the most process wonky thing you've said in a long while, which is saying something. The working group is trying to identify a common codec that can be used to avoid negotiation failure. If there is no common video codec, the network effect of this system is much less. If there are people who have stated *they cannot live with this*, they are not going to build, deploy, or operate services which use the common codec. The actual system we are trying to build will suffer. Judging consensus is not here an end in itself, it's a way of working out whether or not the system we're building does or does not have a way to avoid the negotiation failure. We would not have spent the amount of time we have unless that were important, and we would not be considering using RFC 3929 unless we thought it was worth getting to a resolution. I implore you to stop treating this as an academic exercise in consensus theory, and remind yourself that we're trying to do some engineering here. > > With that summary, the chairs can make a call of whether there is any hope > of consensus. I think much of that work can and should take place on the > mailing list *before* the face-to-face meeting. > > But asking for a show of hands in the room for people who "can live with" > one or the other and deciding whether or not consensus exists based on that > show of hands is simply taking a vote, it's not judging consensus. That rather presumes you know the count. In several of our recent calls, we have had unanimity, which is generally held to be a strong indicator of consensus. The last time we had a straw poll which used similar language, we also had absolutely no question that we had not achieved consensus. Sometimes signals are strong. > You cannot know from that result whether the reason that some people could > not "live with" a proposal was simply because "my Aunt Gertrude told me > that I should say that I can't live with it." To ask for the show of hands > and then not find out what it means is not calling the consensus. And I > think moving to a 3929 alternative on the basis of that show of hands would > be improper. > > If you re-read RFC 3929, you will discover that it requires that you make an explicit call for its use; the consensus to use it standing in for the consent on the technical matter. The working group chairs have no intention of skipping that step, should RFC 3929 be used. > Put me down as one voice who objects to the proposed procedure. > > So noted. fondly, Ted > pr > > > On 9/13/2013 9:52 AM, Ted Hardie wrote: >> >>> WG, >>> >>> The chairs have created a plan for how to perform the Video Codec >>> selection in our WG. The chairs are asking for review of our plan on >>> how to undertake the mandatory-to-implement video codec selection. >>> We'd much prefer to have comments on the mechanics before they begin, >>> so please review now. Proponents of a particular proposal should >>> note both the actions required and the timelines proposed. >>> >>> The main goal of this plan is to hold a consensus call on which of >>> the proposed alternatives we as a WG should select at one of the WG >>> sessions in Vancouver. Such a consensus call will of course be >>> verified on the mailing list for anyone who can't participate. The >>> chairs will recuse themselves from judging this particular >>> consensus. >>> >>> In the WG session each codec proposal will be allowed an equal amount >>> of time to highlight the arguments for their proposal. After that a >>> there will be a slot for discussion and clarifying questions. >>> >>> To enable the WG participants to get answers to any questions, the >>> proposals in draft form and any supporting material MUST be made >>> available by 6th of October. This is to ensure that the WG >>> participants can verify or object to any claims or statements in >>> the proposal material prior to the WG session. We chairs would really >>> not like to see the proponents bring up new arguments at their >>> presentation. Also the WG participants are expected to raise any >>> arguments on the list ahead of time to enable the proponents to >>> respond to such arguments. >>> >>> The proposed consensus questions will be of the following form: >>> >>> 1. If you support H.264 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> 2. If you support VP8 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> You may indicate support on both questions and we encourage you to do >>> so if you can live with either, even if you have a preference for one >>> over the other. >>> >>> Additional proposals than the previous ones are welcome, but must be >>> submitted as draft and their proponents must notify the chairs no later >>> than the 6th of October that they also have a candidate proposal. >>> >>> In case the WG fails to reach consensus we chairs propose that we use >>> the alternative decision process as discussed in RFC3929. The method >>> and its usage will be discussed on the list should the WG not >>> establish consensus on a proposal for mandatory to implement video codec. >>> >>> regards, >>> >>> Magnus, Cullen, and Ted >>> >> > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7b4142d6c8b0c704e649ef1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Howdy,

I've now had lunch and nice coffee, and = I take electrons in hand to answer your missive, sent earlier today.

On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick <= presnick@qti= .qualcomm.com> wrote:
Big caveat as I post this: I am speaking stric= tly as an IETF participant. In particular:


<SNIP>
=A0
All that said, I am concerned about the path being proposed, and I agree wi= th Matthew's concern (though I feel somewhat less defeatist than his as= sessment sounds):


On 9/13/13 11:59 AM, Matthew Kaufman wrote:
2. Should I expect "room-packing" for this "show of hands&qu= ot; (which I don't believe is the typical "hum" process for t= he IETF, either) as happened during the SDES discussion last time, and ther= efore need to bring as many people who've not participated in RTCWEB pr= eviously but who want my codec to succeed as I can afford to fly to Vancouv= er?

I think this is a valid concern. Asking "who wants or can live with VP= 8?" and "who wants or can live with H.264?" might be a good = start to the discussion, but at that point, I'm going to want to hear *= why* people *can't* live with one or the other.

That discussion is supposed to happen before this, not = after, so that if there are issues which might be resolved, they can be.=A0= During the course of the effort to find a solution here, there have been s= everal such resolutions (Cisco, for example, graciously agreed to provide a= n open source H.264 implementation should it be selected, in order to handl= e objections that none were available).=A0 If there are issues which cannot= be resolved, having a second discussion on what they are amounts to re-has= hing and doesn't do anything to move things forward.
=A0
What = I would *not* be interested in is yet another presentation from the propone= nts of either of these to tell me why one is better;

One might surmise that this is because you do not inten= d to actually build, deploy, or operate a service that relates to this.=A0 = If someone puts forward a codec that is better (in human assessment, lines = of code, or operating requirements) and meets the other criteria for deploy= ment, why wouldn't you want to hear about it?
=A0
I wa= nt to hear from *opponents* of the proposal to hear why the proposal would = fail.=A0 Only then would I want to hear from proponents responding to those= objections. And then I'd like to see a summary of those objections and= those responses by the chairs
=A0
Pete, my dear mangel-wurzel and apple of my eye, that's the= most process wonky thing you've said in a long while, which is=20 saying something.=A0 The working group is trying to identify a common=20 codec that can be used to avoid negotiation failure.=A0 If there is no=20 common video codec, the network effect of this system is much less.=A0
=
If there are people who have stated *they cannot live with this*= , they are not going to build, deploy, or operate services which use the co= mmon codec.=A0 The actual system we are trying to build will suffer.=A0 Jud= ging consensus is not here an end in itself, it's a way of working out = whether or not the system we're building does or does not have a way to= avoid the negotiation failure.

We=20 would not have spent the amount of time we have unless that were=20 important, and we would not be considering using RFC 3929 unless we thought= it was worth getting to a resolution.=A0 I implore you to stop treating th= is as an academic exercise in consensus theory, and remind yourself that we= 're trying to do some engineering here.

=A0
With that summary, the chairs can make a call of whether there is any hope=20 of consensus. I think much of that work can and should take place on the mailing list *before* the face-to-face meeting.


You cannot know from that result whether t= he reason that some people could not "live with" a proposal was s= imply because "my Aunt Gertrude told me that I should say that I can&#= 39;t live with it." To ask for the show of hands and then not find out= what it means is not calling the consensus. And I think moving to a 3929 a= lternative on the basis of that show of hands would be improper.

If you re-read RFC 3929, you will discover that it re= quires that you make an explicit call for its use; the consensus to use it = standing in for the consent on the technical matter.=A0 The working group c= hairs have no intention of skipping that step, should RFC 3929 be used.
=A0
Put me down as one voice who objects to the proposed procedure.


So noted.

fondly,
Ted

=A0
pr


On 9/13/2013 9:52 AM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin, so please review now. =A0Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be
verified on the mailing list for anyone who can't participate. The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their
presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.
regards,

Magnus, =A0Cullen, and Ted

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


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

--047d7b4142d6c8b0c704e649ef1b-- From presnick@qti.qualcomm.com Fri Sep 13 14:34:53 2013 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 66A9621F9D0F for ; Fri, 13 Sep 2013 14:34:53 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAbfRbMBa5qg for ; Fri, 13 Sep 2013 14:34:49 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id CC3DC11E80AD for ; Fri, 13 Sep 2013 14:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1379108088; x=1410644088; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OQ+L7AGsD77ci348+AGDHVnMH/DcX/Bup9LiOB5s2ps=; b=QA52c40SjvERu3aG8E9hiMl5MupFQWj2yI5ulM4PrXT0lysQxKe/y7n+ 1cCh0wisaDdxtxE/yH0YdkuqQ8U5c94QbFNser3w0PUhOLqB5sDPxaiZp dboc0gzh4ctknAyULwpBKT+ZJlt+QCAQR7nT+FwnIu/txunTo59bTR4z/ 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7197"; a="51521455" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 13 Sep 2013 14:34:48 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7197"; a="511597844" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Sep 2013 14:34:47 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 13 Sep 2013 14:34:47 -0700 Message-ID: <523384F6.9010401@qti.qualcomm.com> Date: Fri, 13 Sep 2013 16:34:46 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Hardie References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020202050100020401090904" X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Fri, 13 Sep 2013 14:44:24 -0700 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 21:34:53 -0000 --------------020202050100020401090904 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 9/13/13 3:45 PM, Ted Hardie wrote: > I've now had lunch and nice coffee, and I take electrons in hand to > answer your missive, sent earlier today. Erst kommt das Fressen, dann kommt die Standards. > On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick > > wrote: > > Asking "who wants or can live with VP8?" and "who wants or can > live with H.264?" might be a good start to the discussion, but at > that point, I'm going to want to hear *why* people *can't* live > with one or the other. > > > That discussion is supposed to happen before this, not after... That's good to hear, but at least your present "plan" message, and none that I can find elsewhere, makes it apparent that you are now soliciting the list of outstanding issues and their purported answers, nor that a summary of that list and the closed issues would be available before the face-to-face. I'm all for that. > ...so that if there are issues which might be resolved, they can be. Or, for that matter, if there are issues which are showstoppers that can't possibly be resolved, they are noted, because that might leave us with only 1 solution anyway. > If there are issues which cannot be resolved, having a second > discussion on what they are amounts to re-hashing and doesn't do > anything to move things forward. Absolutely agree, no second discussion is desirable. Having the list of unresolvable issues with the chair's calls on those, would be handy. > > What I would *not* be interested in is yet another presentation > from the proponents of either of these to tell me why one is better; > > > One might surmise that this is because you do not intend to actually > build, deploy, or operate a service that relates to this. If someone > puts forward a codec that is better (in human assessment, lines of > code, or operating requirements) and meets the other criteria for > deployment, why wouldn't you want to hear about it? Ah, you misunderstand my comment. I presume that the cases *for* the codecs have all been made quite well already. No doubt, if there is something that proponents believe has not been said or understood yet, out on the table with it. > > I want to hear from *opponents* of the proposal to hear why the > proposal would fail. Only then would I want to hear from > proponents responding to those objections. And then I'd like to > see a summary of those objections and those responses by the chairs > > > Pete, my dear mangel-wurzel and apple of my eye, that's the most > process wonky thing you've said in a long while, which is saying > something. Exchange of hugs, kisses, and root vegetables deferred until Vancouver. > The working group is trying to identify a common codec that can be > used to avoid negotiation failure. If there is no common video codec, > the network effect of this system is much less. Of course. > If there are people who have stated *they cannot live with this*, they > are not going to build, deploy, or operate services which use the > common codec. I call "horse-pucky". And this is exactly why looking at skyward-pointing-appendages is a lousy tool in this particular case. You don't know that if they state "they cannot live with this" that they are not going to deploy. You would only know that if you knew their reasons. Because my friend mentioned below who is raising his arm because his Aunt Gertrude told him to do so is not affecting deployment one little bit. At some point, you have to trust people to be honest, but you need to ask the right question. In this case, if I say, "I can't implement this in my little open source release (that my employer would never sanction) if you use the FOOBAR codec for such-and-so reasons", it's reasonable to ask, "Who's in the same boat with Pete?", perhaps even following up with "Is the WG really OK with the idea the that folks in Pete's circumstances (open-source developers, 1-coder shops, holdover Macintosh developers, coders for devices with less than 1K of available memory, etc.) are not going to be able to implement this?" Maybe the WG will say, "Poor Pete. He's in the rough. We're chartered to make this work on a wide-scale, and Pete's sort of implementation is just not realistically a part of what we're doing." But then you're asking about whether the WG is willing to punt a particular kind of deployment, not counting heads (hands, souls, auras, or otherwise). > The actual system we are trying to build will suffer. Judging > consensus is not here an end in itself, it's a way of working out > whether or not the system we're building does or does not have a way > to avoid the negotiation failure. We agree on the goal. We disagree on the methodology. > We would not have spent the amount of time we have unless that were > important, and we would not be considering using RFC 3929 unless we > thought it was worth getting to a resolution. I implore you to stop > treating this as an academic exercise in consensus theory, and remind > yourself that we're trying to do some engineering here. Let's avoid questioning each others' motives, shall we? No good down that road. > But asking for a show of hands in the room for people who "can > live with" one or the other and deciding whether or not consensus > exists based on that show of hands is simply taking a vote, it's > not judging consensus. > > > That rather presumes you know the count. Not at all. > In several of our recent calls, we have had unanimity, which is > generally held to be a strong indicator of consensus. Unanimity is, I concede. Other counts have more or less interesting indications. > The last time we had a straw poll which used similar language, we also > had absolutely no question that we had not achieved consensus. You certainly had the appearance of non-consensus. But I'm not convinced the work was done to determine what the showstoppers were for the people who "couldn't live with" one choice or the other. (I will put aside the fact that some chap -- with a blue dot on his badge, no less -- sitting down the row from me during that straw poll, exclaimed upon conclusion of it, "Well, it's pretty obvious we have consensus for 'A'". I was.....disappointed.) > Sometimes signals are strong. Strong signal of something. I'm not always totally sure what. > > You cannot know from that result whether the reason that some > people could not "live with" a proposal was simply because "my > Aunt Gertrude told me that I should say that I can't live with > it." To ask for the show of hands and then not find out what it > means is not calling the consensus. And I think moving to a 3929 > alternative on the basis of that show of hands would be improper. > > > If you re-read RFC 3929, you will discover that it requires that you > make an explicit call for its use; the consensus to use it standing in > for the consent on the technical matter. The working group chairs > have no intention of skipping that step, should RFC 3929 be used. As above, I worry about how the determination is made. Once made, all is well. > fondly, Right back at ya'. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------020202050100020401090904 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 9/13/13 3:45 PM, Ted Hardie wrote:
I've now had lunch and nice coffee, and I take electrons in hand to answer your missive, sent earlier today.

Erst kommt das Fressen, dann kommt die Standards.

On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

Asking "who wants or can live with VP8?" and "who wants or can live with H.264?" might be a good start to the discussion, but at that point, I'm going to want to hear *why* people *can't* live with one or the other.

That discussion is supposed to happen before this, not after...

That's good to hear, but at least your present "plan" message, and none that I can find elsewhere, makes it apparent that you are now soliciting the list of outstanding issues and their purported answers, nor that a summary of that list and the closed issues would be available before the face-to-face. I'm all for that.

...so that if there are issues which might be resolved, they can be.

Or, for that matter, if there are issues which are showstoppers that can't possibly be resolved, they are noted, because that might leave us with only 1 solution anyway.

If there are issues which cannot be resolved, having a second discussion on what they are amounts to re-hashing and doesn't do anything to move things forward.

Absolutely agree, no second discussion is desirable. Having the list of unresolvable issues with the chair's calls on those, would be handy.
 
What I would *not* be interested in is yet another presentation from the proponents of either of these to tell me why one is better;

One might surmise that this is because you do not intend to actually build, deploy, or operate a service that relates to this.  If someone puts forward a codec that is better (in human assessment, lines of code, or operating requirements) and meets the other criteria for deployment, why wouldn't you want to hear about it?

Ah, you misunderstand my comment. I presume that the cases *for* the codecs have all been made quite well already. No doubt, if there is something that proponents believe has not been said or understood yet, out on the table with it.
 
I want to hear from *opponents* of the proposal to hear why the proposal would fail.  Only then would I want to hear from proponents responding to those objections. And then I'd like to see a summary of those objections and those responses by the chairs
 
Pete, my dear mangel-wurzel and apple of my eye, that's the most process wonky thing you've said in a long while, which is saying something.

Exchange of hugs, kisses, and root vegetables deferred until Vancouver.

The working group is trying to identify a common codec that can be used to avoid negotiation failure.  If there is no common video codec, the network effect of this system is much less.

Of course.

If there are people who have stated *they cannot live with this*, they are not going to build, deploy, or operate services which use the common codec.

I call "horse-pucky". And this is exactly why looking at skyward-pointing-appendages is a lousy tool in this particular case. You don't know that if they state "they cannot live with this" that they are not going to deploy. You would only know that if you knew their reasons. Because my friend mentioned below who is raising his arm because his Aunt Gertrude told him to do so is not affecting deployment one little bit. At some point, you have to trust people to be honest, but you need to ask the right question. In this case, if I say, "I can't implement this in my little open source release (that my employer would never sanction) if you use the FOOBAR codec for such-and-so reasons", it's reasonable to ask, "Who's in the same boat with Pete?", perhaps even following up with "Is the WG really OK with the idea the that folks in Pete's circumstances (open-source developers, 1-coder shops, holdover Macintosh developers, coders for devices with less than 1K of available memory, etc.) are not going to be able to implement this?" Maybe the WG will say, "Poor Pete. He's in the rough. We're chartered to make this work on a wide-scale, and Pete's sort of implementation is just not realistically a part of what we're doing." But then you're asking about whether the WG is willing to punt a particular kind of deployment, not counting heads (hands, souls, auras, or otherwise).

The actual system we are trying to build will suffer.  Judging consensus is not here an end in itself, it's a way of working out whether or not the system we're building does or does not have a way to avoid the negotiation failure.

We agree on the goal. We disagree on the methodology.

We would not have spent the amount of time we have unless that were important, and we would not be considering using RFC 3929 unless we thought it was worth getting to a resolution.  I implore you to stop treating this as an academic exercise in consensus theory, and remind yourself that we're trying to do some engineering here.

Let's avoid questioning each others' motives, shall we? No good down that road.

But asking for a show of hands in the room for people who "can live with" one or the other and deciding whether or not consensus exists based on that show of hands is simply taking a vote, it's not judging consensus.

That rather presumes you know the count.

Not at all.

In several of our recent calls, we have had unanimity, which is generally held to be a strong indicator of consensus.

Unanimity is, I concede. Other counts have more or less interesting indications.

The last time we had a straw poll which used similar language, we also had absolutely no question that we had not achieved consensus.

You certainly had the appearance of non-consensus. But I'm not convinced the work was done to determine what the showstoppers were for the people who "couldn't live with" one choice or the other. (I will put aside the fact that some chap -- with a blue dot on his badge, no less -- sitting down the row from me during that straw poll, exclaimed upon conclusion of it, "Well, it's pretty obvious we have consensus for 'A'". I was.....disappointed.)

Sometimes signals are strong.

Strong signal of something. I'm not always totally sure what.
 
You cannot know from that result whether the reason that some people could not "live with" a proposal was simply because "my Aunt Gertrude told me that I should say that I can't live with it." To ask for the show of hands and then not find out what it means is not calling the consensus. And I think moving to a 3929 alternative on the basis of that show of hands would be improper.

If you re-read RFC 3929, you will discover that it requires that you make an explicit call for its use; the consensus to use it standing in for the consent on the technical matter.  The working group chairs have no intention of skipping that step, should RFC 3929 be used.

As above, I worry about how the determination is made. Once made, all is well.

fondly,

Right back at ya'.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------020202050100020401090904-- From ted.ietf@gmail.com Fri Sep 13 15:05:27 2013 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 7C24611E80F9 for ; Fri, 13 Sep 2013 15:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yCmcnVW3GWA for ; Fri, 13 Sep 2013 15:05:24 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 10DA611E80AD for ; Fri, 13 Sep 2013 15:05:22 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so3825183iec.18 for ; Fri, 13 Sep 2013 15:05:22 -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=P9EVpPZbtAwIKtyT91Fd0Til8WHT0tSZmUyKRvCY/lA=; b=hlLSi845oA4OENMhiyv5tKZFbAjW4KrOk1nDVygohHV0YNIfbNt18UnJqz6vaGtRYH c5UNGqMX/hyZQS+y7XsUwZfAsGGqy4Gjy9SF7DWLLMGRaMR3lU5clXamklP78D3kTzjh gN5Oazdm6FgCuqIkrg3ho7wEKaqGMspNz42kUgIipcFdaXfwChX7paAmAVi0ILBrZkzp GFfToM1ijNdsLCFCYKfUH4p5o9PNN9xtiAmtdcLD61JaLk4GBQGss9rmZjpKWBn2g6Ci Y0cAzdwDrSFEPhJKQ/IwpuGglfIg0cSRvzxPYb+fQI/Ike2eaJO/9qpWX49dAk/FFydl Bhdg== MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr2215404igb.22.1379109922536; Fri, 13 Sep 2013 15:05:22 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 13 Sep 2013 15:05:22 -0700 (PDT) In-Reply-To: <523384F6.9010401@qti.qualcomm.com> References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> <523384F6.9010401@qti.qualcomm.com> Date: Fri, 13 Sep 2013 15:05:22 -0700 Message-ID: From: Ted Hardie To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7bd76bb20a055e04e64b0daf Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 22:05:27 -0000 --047d7bd76bb20a055e04e64b0daf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 13, 2013 at 2:34 PM, Pete Resnick wrote: > ** > On 9/13/13 3:45 PM, Ted Hardie wrote: > > I've now had lunch and nice coffee, and I take electrons in hand to answer > your missive, sent earlier today. > > > Erst kommt das Fressen, dann kommt die Standards. > > Trust me, the food was too good to guzzle. On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick wrote: > > Asking "who wants or can live with VP8?" and "who wants or can live with >> H.264?" might be a good start to the discussion, but at that point, I'm >> going to want to hear *why* people *can't* live with one or the other. > > > That discussion is supposed to happen before this, not after... > > > That's good to hear, but at least your present "plan" message, and none > that I can find elsewhere, makes it apparent that you are now soliciting > the list of outstanding issues and their purported answers, nor that a > summary of that list and the closed issues would be available before the > face-to-face. I'm all for that. > > Um, did you miss the part where folks were supposed to have their proposals in by the 6th of October so that objections and discussions could happen in advance of the meeting? "To enable the WG participants to get answers to any questions, the proposals in draft form and any supporting material MUST be made available by 6th of October. This is to ensure that the WG participants can verify or object to any claims or statements in the proposal material prior to the WG session" > I call "horse-pucky". And this is exactly why looking at > skyward-pointing-appendages is a lousy tool in this particular case. You > don't know that if they state "they cannot live with this" that they are > not going to deploy. You would only know that if you knew their reasons. > Because my friend mentioned below who is raising his arm because his Aunt > Gertrude told him to do so is not affecting deployment one little bit. > We disagree. A set of working group participants will not use a codec because they have financial reasons, technical reasons, or a personal promise to their aunts comes down to the same thing: they will not implement or deploy. The impact to the network effect is the same if the reasoning is philosophical, financial, or personal. > At some point, you have to trust people to be honest > Exactly. Or, perhaps more to the point, if you cannot trust their statements on their future course of action, why would you trust their statement on their reasons? but you need to ask the right question. In this case, if I say, "I can't > implement this in my little open source release (that my employer would > never sanction) if you use the FOOBAR codec for such-and-so reasons", it's > reasonable to ask, "Who's in the same boat with Pete?", perhaps even > following up with "Is the WG really OK with the idea the that folks in > Pete's circumstances (open-source developers, 1-coder shops, holdover > Macintosh developers, coders for devices with less than 1K of available > memory, etc.) are not going to be able to implement this?" Maybe the WG > will say, "Poor Pete. He's in the rough. We're chartered to make this work > on a wide-scale, and Pete's sort of implementation is just not > realistically a part of what we're doing." > Actually, what we're doing is set out elsewhere, in the charter and the use case document. As you consulted the archives on this topic, perhaps you saw the WGLC on the latter. > But then you're asking about whether the WG is willing to punt a > particular kind of deployment, not counting heads (hands, souls, auras, or > otherwise). > > > The actual system we are trying to build will suffer. Judging > consensus is not here an end in itself, it's a way of working out whether > or not the system we're building does or does not have a way to avoid the > negotiation failure. > > > We agree on the goal. We disagree on the methodology. > > > We would not have spent the amount of time we have unless that were > important, and we would not be considering using RFC 3929 unless we thought > it was worth getting to a resolution. I implore you to stop treating this > as an academic exercise in consensus theory, and remind yourself that we're > trying to do some engineering here. > > > Let's avoid questioning each others' motives, shall we? No good down that > road. > > Let me implore you, then, to look at the engineering aspects rather than the process aspects. > > But asking for a show of hands in the room for people who "can live >> with" one or the other and deciding whether or not consensus exists based >> on that show of hands is simply taking a vote, it's not judging consensus. > > > That rather presumes you know the count. > > > Not at all. > > > In several of our recent calls, we have had unanimity, which is > generally held to be a strong indicator of consensus. > > > Unanimity is, I concede. Other counts have more or less interesting > indications. > > > The last time we had a straw poll which used similar language, we also > had absolutely no question that we had not achieved consensus. > > > You certainly had the appearance of non-consensus. But I'm not convinced > the work was done to determine what the showstoppers were for the people > who "couldn't live with" one choice or the other. > Had that been the first time we had visited the topic, I would agree with you. But it was not even the first handful. > (I will put aside the fact that some chap -- with a blue dot on his badge, > no less -- sitting down the row from me during that straw poll, exclaimed > upon conclusion of it, "Well, it's pretty obvious we have consensus for > 'A'". I was.....disappointed.) > > The chairs have recused themselves from calling consensus, but had the most recent straw poll resulted in an assertion of consensus, I would have been mightily surprised. > Sometimes signals are strong. > > > Strong signal of something. I'm not always totally sure what. > > Well, starting from the assumption that people are answering the question they were asked seems reasonable to me. > > > If you re-read RFC 3929, you will discover that it requires that you make > an explicit call for its use; the consensus to use it standing in for the > consent on the technical matter. The working group chairs have no > intention of skipping that step, should RFC 3929 be used. > > > As above, I worry about how the determination is made. Once made, all is > well. > > Should it become necessary, I'm sure that any suggestion you have on wording such a question to the working group will be given all due consideration, Ted > fondly, > > > Right back at ya'. > > pr > > -- > Pete Resnick > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --047d7bd76bb20a055e04e64b0daf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 2:34 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
=20
On 9/13/13 3:45 PM, Ted Hardie wrote:
I've now had lunch and nice coffee, and I take electrons in hand to answer your missive, sent earlier today.

Erst kommt das Fressen, dann kommt die Standards.


Trust me, the food was too good = to guzzle.


On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

Asking "who wants or can live with VP8?" and "who wants or can live= with H.264?" might be a good start to the discussion, but at that point, I&= #39;m going to want to hear *why* people *can't* live with one or the other. =

That discussion is supposed to happen before this, not after..= .

That's good to hear, but at least your present "plan" message= , and none that I can find elsewhere, makes it apparent that you are now soliciting the list of outstanding issues and their purported answers, nor that a summary of that list and the closed issues would be available before the face-to-face. I'm all for that.


Um, did you miss the part where = folks were supposed to have their proposals in by the 6th of October so tha= t objections and discussions could happen in advance of the meeting?

"To enable the WG participants to get answers to any qu= estions, the
proposals in draft form and any supporting material MUST be= made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session"
=A0
I call "horse-pucky". And this is exactly why looking at skyward-pointing-appendages is a lousy tool in this particular case. You don't know that if they state "they cannot live with this"= ; that they are not going to deploy. You would only know that if you knew their reasons. Because my friend mentioned below who is raising his arm because his Aunt Gertrude told him to do so is not affecting deployment one little bit.

We disagree. A set of= working group participants will not use a codec because they have financia= l reasons, technical reasons, or a personal promise to their aunts comes do= wn to the same thing:=A0 they will not implement or deploy.=A0 The impact t= o the network effect is the same if the reasoning is philosophical, financi= al, or personal.
=A0
At some point, you have to trust people to be ho= nest

Exactly.=A0 Or, perhaps more to the point,= if you cannot trust their statements on their future course of action, why= would you trust their statement on their reasons?

but you need to ask the right question. In this case, if I say, "I can't implement this in my little open source release (that my employer would never sanction) if you use the FOOBAR codec for such-and-so reasons", it's reasonable to ask, "Who's in the same boat= with Pete?", perhaps even following up with "Is the WG really OK with the idea the that folks in Pete's circumstances (open-source developers, 1-coder shops, holdover Macintosh developers, coders for devices with less than 1K of available memory, etc.) are not going to be able to implement this?" Maybe the WG will say, "Poor Pete. He's in the rough. = We're chartered to make this work on a wide-scale, and Pete's sort of implementation is just not realistically a part of what we're doing.&qu= ot;

Actually, what we're doing is se= t out elsewhere, in the charter and the use case document.=A0 As you consul= ted the archives on this topic, perhaps you saw the WGLC on the latter.
=A0
But then you're asking about whether the WG i= s willing to punt a particular kind of deployment, not counting heads (hands, souls, auras, or otherwise).


The actual system we are trying to build will suffer.=A0 Judging consensus is not here an end in itself, it's a way of working out whether or not the system we're building does or does not have a way to avoid the negotiation failure.

We agree on the goal. We disagree on the methodology.


We would not have spent the amount of time we have unless that were important, and we would not be considering using RFC 3929 unless we thought it was worth getting to a resolution.=A0 I implore you to stop treating this as an academic exercise in consensus theory, and remind yourself that we're trying to do some engineering here.

Let's avoid questioning each others' motives, shall we? No good dow= n that road.


Let me implore you, then, to look at the engineering aspects rather than = the process aspects.
=A0

But asking for a show of hands in the room for people who "can live with&q= uot; one or the other and deciding whether or not consensus exists based on that show of hands is simply taking a vote, it's not judging consensus.

That rather presumes you know the count.

Not at all.


In several of our recent calls, we have had unanimity, which is generally held to be a strong indicator of consensus.

Unanimity is, I concede. Other counts have more or less interesting indications.


The last time we had a straw poll which used similar language, we also had absolutely no question that we had not achieved consensus.

You certainly had the appearance of non-consensus. But I'm not convinced the work was done to determine what the showstoppers were for the people who "couldn't live with" one choice or the other. =

Had that been the first time we had = visited the topic, I would agree with you.=A0 But it was not even the first= handful.

=A0
<= div text=3D"#000000" bgcolor=3D"#ffffff">(I will put aside the fact that some chap -- with a blue dot on his badge, no less -- sitting down the row from me during that straw poll, exclaimed upon conclusion of it, "Well, it's pretty obvious we have consensu= s for 'A'". I was.....disappointed.)


The chairs have recused themselv= es from calling consensus, but had the most recent straw poll resulted in a= n assertion of consensus, I would have been mightily surprised.
=A0
Sometimes signals are strong.

Strong signal of something. I'm not always totally sure what.


Well, starting fro= m the assumption that people are answering the question they were asked see= ms reasonable to me.

=A0

If you re-read RFC 3929, you will discover that it requires that you make an explicit call for its use; the consensus to use it standing in for the consent on the technical matter.=A0 The working group chairs have no intention of skipping that step, should RFC 3929 be used.

As above, I worry about how the determination is made. Once made, all is well.


Should it become necessary, I= 9;m sure that any suggestion you have on wording such a question to the wor= king group will be given all due consideration,

Ted
=A0
fondly,

Right back at ya'.

pr
--=
=20
Pete Resnick <http://www.qualcomm.com/~presnick/>

Qualcomm Technologies, Inc. - +1 (858)651-4478

--047d7bd76bb20a055e04e64b0daf-- From lorenzo@meetecho.com Fri Sep 13 15:26:44 2013 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 8A22921E8133 for ; Fri, 13 Sep 2013 15:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml21QIKEN522 for ; Fri, 13 Sep 2013 15:26:40 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id CC83021E8130 for ; Fri, 13 Sep 2013 15:26:38 -0700 (PDT) Received: from rainpc ([95.246.156.38]) by smtpcmd03.ad.aruba.it with bizsmtp id QmSb1m00U0pzAEv01mSbEw; Sat, 14 Sep 2013 00:26:36 +0200 Date: Sat, 14 Sep 2013 00:26:35 +0200 From: Lorenzo Miniero To: Ted Hardie Message-ID: <20130914002635.3ebddfef@rainpc> In-Reply-To: References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Pete Resnick , "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 22:26:44 -0000 On Fri, 13 Sep 2013 13:45:36 -0700 Ted Hardie wrote: > Howdy, > > I've now had lunch and nice coffee, and I take electrons in hand to answer > your missive, sent earlier today. > > On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick wrote: > > > Big caveat as I post this: I am speaking strictly as an IETF participant. > > In particular: > > > > > > > > > All that said, I am concerned about the path being proposed, and I agree > > with Matthew's concern (though I feel somewhat less defeatist than his > > assessment sounds): > > > > > > On 9/13/13 11:59 AM, Matthew Kaufman wrote: > > > >> 2. Should I expect "room-packing" for this "show of hands" (which I don't > >> believe is the typical "hum" process for the IETF, either) as happened > >> during the SDES discussion last time, and therefore need to bring as many > >> people who've not participated in RTCWEB previously but who want my codec > >> to succeed as I can afford to fly to Vancouver? > >> > > > > I think this is a valid concern. Asking "who wants or can live with VP8?" > > and "who wants or can live with H.264?" might be a good start to the > > discussion, but at that point, I'm going to want to hear *why* people > > *can't* live with one or the other. > > > That discussion is supposed to happen before this, not after, so that if > there are issues which might be resolved, they can be. During the course > of the effort to find a solution here, there have been several such > resolutions (Cisco, for example, graciously agreed to provide an open > source H.264 implementation should it be selected, in order to handle > objections that none were available). If there are issues which cannot be > resolved, having a second discussion on what they are amounts to re-hashing > and doesn't do anything to move things forward. > Open source implementations are not the issue (we have x264 for that), licensing is. Lorenzo > > > What I would *not* be interested in is yet another presentation from the > > proponents of either of these to tell me why one is better; > > > One might surmise that this is because you do not intend to actually build, > deploy, or operate a service that relates to this. If someone puts forward > a codec that is better (in human assessment, lines of code, or operating > requirements) and meets the other criteria for deployment, why wouldn't you > want to hear about it? > > > > I want to hear from *opponents* of the proposal to hear why the proposal > > would fail. Only then would I want to hear from proponents responding to > > those objections. And then I'd like to see a summary of those objections > > and those responses by the chairs > > > Pete, my dear mangel-wurzel and apple of my eye, that's the most process > wonky thing you've said in a long while, which is saying something. The > working group is trying to identify a common codec that can be used to > avoid negotiation failure. If there is no common video codec, the network > effect of this system is much less. > If there are people who have stated *they cannot live with this*, they are > not going to build, deploy, or operate services which use the common > codec. The actual system we are trying to build will suffer. Judging > consensus is not here an end in itself, it's a way of working out whether > or not the system we're building does or does not have a way to avoid the > negotiation failure. > > We would not have spent the amount of time we have unless that were > important, and we would not be considering using RFC 3929 unless we thought > it was worth getting to a resolution. I implore you to stop treating this > as an academic exercise in consensus theory, and remind yourself that we're > trying to do some engineering here. > > > > > > With that summary, the chairs can make a call of whether there is any hope > > of consensus. I think much of that work can and should take place on the > > mailing list *before* the face-to-face meeting. > > > > > But asking for a show of hands in the room for people who "can live with" > > one or the other and deciding whether or not consensus exists based on that > > show of hands is simply taking a vote, it's not judging consensus. > > > That rather presumes you know the count. In several of our recent calls, > we have had unanimity, which is generally held to be a strong indicator of > consensus. > > The last time we had a straw poll which used similar language, we also had > absolutely no question that we had not achieved consensus. > > Sometimes signals are strong. > > > > You cannot know from that result whether the reason that some people could > > not "live with" a proposal was simply because "my Aunt Gertrude told me > > that I should say that I can't live with it." To ask for the show of hands > > and then not find out what it means is not calling the consensus. And I > > think moving to a 3929 alternative on the basis of that show of hands would > > be improper. > > > > If you re-read RFC 3929, you will discover that it requires that you make > an explicit call for its use; the consensus to use it standing in for the > consent on the technical matter. The working group chairs have no > intention of skipping that step, should RFC 3929 be used. > > > > Put me down as one voice who objects to the proposed procedure. > > > > > So noted. > > fondly, > > Ted > > > > > pr > > > > > > On 9/13/2013 9:52 AM, Ted Hardie wrote: > >> > >>> WG, > >>> > >>> The chairs have created a plan for how to perform the Video Codec > >>> selection in our WG. The chairs are asking for review of our plan on > >>> how to undertake the mandatory-to-implement video codec selection. > >>> We'd much prefer to have comments on the mechanics before they begin, > >>> so please review now. Proponents of a particular proposal should > >>> note both the actions required and the timelines proposed. > >>> > >>> The main goal of this plan is to hold a consensus call on which of > >>> the proposed alternatives we as a WG should select at one of the WG > >>> sessions in Vancouver. Such a consensus call will of course be > >>> verified on the mailing list for anyone who can't participate. The > >>> chairs will recuse themselves from judging this particular > >>> consensus. > >>> > >>> In the WG session each codec proposal will be allowed an equal amount > >>> of time to highlight the arguments for their proposal. After that a > >>> there will be a slot for discussion and clarifying questions. > >>> > >>> To enable the WG participants to get answers to any questions, the > >>> proposals in draft form and any supporting material MUST be made > >>> available by 6th of October. This is to ensure that the WG > >>> participants can verify or object to any claims or statements in > >>> the proposal material prior to the WG session. We chairs would really > >>> not like to see the proponents bring up new arguments at their > >>> presentation. Also the WG participants are expected to raise any > >>> arguments on the list ahead of time to enable the proponents to > >>> respond to such arguments. > >>> > >>> The proposed consensus questions will be of the following form: > >>> > >>> 1. If you support H.264 as the mandatory to implement codec or are > >>> willing to live with it as the MTI, please raise your hand now. > >>> > >>> 2. If you support VP8 as the mandatory to implement codec or are > >>> willing to live with it as the MTI, please raise your hand now. > >>> > >>> You may indicate support on both questions and we encourage you to do > >>> so if you can live with either, even if you have a preference for one > >>> over the other. > >>> > >>> Additional proposals than the previous ones are welcome, but must be > >>> submitted as draft and their proponents must notify the chairs no later > >>> than the 6th of October that they also have a candidate proposal. > >>> > >>> In case the WG fails to reach consensus we chairs propose that we use > >>> the alternative decision process as discussed in RFC3929. The method > >>> and its usage will be discussed on the list should the WG not > >>> establish consensus on a proposal for mandatory to implement video codec. > >>> > >>> regards, > >>> > >>> Magnus, Cullen, and Ted > >>> > >> > > -- > > Pete Resnick > > > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > > > > ______________________________**_________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/**listinfo/rtcweb > > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From ron.even.tlv@gmail.com Fri Sep 13 15:38:18 2013 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 BB6D211E81A9 for ; Fri, 13 Sep 2013 15:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IejK3fH7nsS for ; Fri, 13 Sep 2013 15:38:18 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 859F211E81BD for ; Fri, 13 Sep 2013 15:38:17 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w62so1729567wes.32 for ; Fri, 13 Sep 2013 15:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=AW6CV/0iPpLD1Y8VsU/utzEpH322kJrsEaoQIWcev0g=; b=wRFiSWxC8yhXozX3u5WnlEmTz69XTrvl6ooUDTnLzgC++8X+tWUXKKbAvoPHpnav31 TQISG5fCrQ3GgIEjv5NSuiKE8ChS41fwqHijM5pArBeKGeRh4AHQtp3BQzWNiaEMKI6u WcGwke0ljvuOGQfXoCtbWAbC+V8/cb8s+relj9u0yPXCRBQe+EtpLMCChM859HEaRKfO owgJZOptDdy5n7p8ke2qphaBeiZGVucOUsXmbhNImYJ9+NDgw9JWYGbe5v91txEdTDKe 3O4ZMFEqdpuj9V2C+Zhvbwmk1O2D9CKEY+geCXgpZkiCPkX0VTBnW951foaPPwcr8cKj 6TNA== X-Received: by 10.180.89.147 with SMTP id bo19mr4370397wib.3.1379111896643; Fri, 13 Sep 2013 15:38:16 -0700 (PDT) Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id dq11sm6445785wid.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Sep 2013 15:38:16 -0700 (PDT) From: "Roni Even" To: "'Ted Hardie'" , , "'Cullen Jennings'" , "'Magnus Westerlund'" References: In-Reply-To: Date: Sat, 14 Sep 2013 01:35:27 +0300 Message-ID: <00b301ceb0d1$8d4006c0$a7c01440$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01CEB0EA.B28E0210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5xamDVfnnGNElpEJBqju8BUdNg5juFeBA Content-Language: en-us Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 22:38:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B4_01CEB0EA.B28E0210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ted, What is the difference between the proposed questions and the ones that were asked in Orlando, we had documents and presentations and could not reach a decision in Orlando. If nothing changed we can start with the proposal to use alternative decision process. Roni From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: 13 September, 2013 7:52 PM To: rtcweb@ietf.org; Cullen Jennings; Magnus Westerlund Subject: [rtcweb] Video Codec Selection Plan WG, The chairs have created a plan for how to perform the Video Codec selection in our WG. The chairs are asking for review of our plan on how to undertake the mandatory-to-implement video codec selection. We'd much prefer to have comments on the mechanics before they begin, so please review now. Proponents of a particular proposal should note both the actions required and the timelines proposed. The main goal of this plan is to hold a consensus call on which of the proposed alternatives we as a WG should select at one of the WG sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate. The chairs will recuse themselves from judging this particular consensus. In the WG session each codec proposal will be allowed an equal amount of time to highlight the arguments for their proposal. After that a there will be a slot for discussion and clarifying questions. To enable the WG participants to get answers to any questions, the proposals in draft form and any supporting material MUST be made available by 6th of October. This is to ensure that the WG participants can verify or object to any claims or statements in the proposal material prior to the WG session. We chairs would really not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any arguments on the list ahead of time to enable the proponents to respond to such arguments. The proposed consensus questions will be of the following form: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. You may indicate support on both questions and we encourage you to do so if you can live with either, even if you have a preference for one over the other. Additional proposals than the previous ones are welcome, but must be submitted as draft and their proponents must notify the chairs no later than the 6th of October that they also have a candidate proposal. In case the WG fails to reach consensus we chairs propose that we use the alternative decision process as discussed in RFC3929. The method and its usage will be discussed on the list should the WG not establish consensus on a proposal for mandatory to implement video codec. regards, Magnus, Cullen, and Ted ------=_NextPart_000_00B4_01CEB0EA.B28E0210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted,

What is the difference between the proposed questions and the ones = that were asked in Orlando, we had documents and presentations and could = not reach a decision in Orlando.

If nothing changed we can start with the proposal to use alternative = decision process.

Roni

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Ted Hardie
Sent: 13 September, 2013 7:52 PM
To: = rtcweb@ietf.org; Cullen Jennings; Magnus Westerlund
Subject: = [rtcweb] Video Codec Selection Plan

 

WG,

The chairs have created a plan = for how to perform the Video Codec
selection in our WG. The chairs = are asking for review of our plan on
how to undertake the = mandatory-to-implement video codec selection.
We'd much prefer to = have comments on the mechanics before they begin,
so please review = now.  Proponents of a particular proposal should
note both the = actions required and the timelines proposed.

The main goal of = this plan is to hold a consensus call on which of
the proposed = alternatives we as a WG should select at one of the WG
sessions in = Vancouver. Such a consensus call will of course be
verified on the = mailing list for anyone who can't participate. The
chairs will recuse = themselves from judging this particular
consensus.

In the WG = session each codec proposal will be allowed an equal amount
of time = to highlight the arguments for their proposal. After that a
there = will be a slot for discussion and clarifying questions.

To enable = the WG participants to get answers to any questions, the
proposals in = draft form and any supporting material MUST be made
available by 6th = of October. This is to ensure that the WG
participants can verify or = object to any claims or statements in
the proposal material prior to = the WG session. We chairs would really
not like to see the proponents = bring up new arguments at their
presentation. Also the WG = participants are expected to raise any
arguments on the list ahead of = time to enable the proponents to
respond to such = arguments.

The proposed consensus questions will be of the = following form:

1. If you support H.264 as the mandatory to = implement codec or are
willing to live with it as the MTI, please = raise your hand now.

2. If you support VP8 as the mandatory to = implement codec or are
willing to live with it as the MTI, please = raise your hand now.

You may indicate support on both questions = and we encourage you to do
so if you can live with either, even if = you have a preference for one
over the other.

Additional = proposals than the previous ones are welcome, but must be
submitted = as draft and their proponents must notify the chairs no later
than = the 6th of October that they also have a candidate proposal.

In = case the WG fails to reach consensus we chairs propose that we = use
the alternative decision process as discussed in RFC3929. The = method
and its usage will be discussed on the list should the WG = not
establish consensus on a proposal for mandatory to implement = video codec.

regards,

Magnus,  Cullen, and = Ted

------=_NextPart_000_00B4_01CEB0EA.B28E0210-- From bossiel@yahoo.fr Fri Sep 13 16:19:55 2013 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 DE99411E81EB for ; Fri, 13 Sep 2013 16:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWzSY2tNf2oO for ; Fri, 13 Sep 2013 16:19:51 -0700 (PDT) Received: from nm7-vm1.bullet.mail.ird.yahoo.com (nm7-vm1.bullet.mail.ird.yahoo.com [77.238.189.223]) by ietfa.amsl.com (Postfix) with SMTP id 20A9511E80A2 for ; Fri, 13 Sep 2013 16:19:50 -0700 (PDT) Received: from [77.238.189.55] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 13 Sep 2013 23:19:50 -0000 Received: from [46.228.39.76] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 13 Sep 2013 23:19:50 -0000 Received: from [127.0.0.1] by smtp113.mail.ir2.yahoo.com with NNFMP; 13 Sep 2013 23:19:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1379114390; bh=iGslQGgkuTK+JhaLLRc8UXZrQC6MJPlbJHjyyw66UCA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=VHJQY6M+7Ku8oS8s4AqC3mg2/J6rn0woiUV6QaxLsbx+I0Y1lbA/ycH4dDlqxC2iiou5Q9JwTmYDINxcRpYQ3rYd83WsCPCfRQdB7W3DN2EnDosAY7S/faDbZ9sOiIbgBEN6SxA//DyTtTR7qbYZvw6m6p1OIgph5nDk/twMgc4= X-Yahoo-Newman-Id: 93339.15905.bm@smtp113.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: XfB0KvAVM1nS4wO0Aa5hBJsCCtE11OTcyxHMePyiokBu18A o9XwDl6AtepV.iQY.AS6vJqnB8m_BxSI2xPTIM_93qh_OOXGs.pvElzNbk3k keRaHMfyjlrwi9As8nPyRq40x7pPtAjfq7cFanv2kQsT4w751PXTSnER7T_l 6f0JzPEX6YTeLi0JiezyHSubmVrTRn80T.WzUPauqQK4p3J8TMhdp5d6cs1v rhurv6d3LzSvxRk_VwjSVAiYd19Z5w1YCPVN4XQV3kStfwJyj1GnVRb31gev kKX5OXuDRTtSxh1wIFpEKNXw0kB4.R08YIxjo6yUnjDnxQLj1h5lsmNR._4V Wih_lTwpBsoOOZbcF6sFWhjqeF9k4KLWVJ3QhpyS1rE0Cb3e5o0qOLf0Nx3L m3rq4SnN4vN_jsbBQuF7JNLV_AKLbvwYHnjXQ5cL.6EYKampTfzV1L2Dd5y4 GmXwQJ3.TacQMW7mF9xDJS4aErgLCMLtPIIWLy1Oo0ElWbYcijs40Mz6eLZi NVdCOIMKHXZyYaHZPPPWCl5hsKyQmBCV9Xhp6vfFDhRqxjLZ__BmpHzDx.Hc brghDSkLCadKIiZrXbe7X1SR5tQ-- X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp113.mail.ir2.yahoo.com with SMTP; 13 Sep 2013 23:19:49 +0000 UTC References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> <20130914002635.3ebddfef@rainpc> Mime-Version: 1.0 (1.0) In-Reply-To: <20130914002635.3ebddfef@rainpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Bossiel Date: Sat, 14 Sep 2013 01:19:48 +0200 To: Lorenzo Miniero Cc: "rtcweb@ietf.org" , Pete Resnick Subject: Re: [rtcweb] Video Codec Selection Plan 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, 13 Sep 2013 23:19:56 -0000 Sent from my iPhone On Sep 14, 2013, at 0:26, Lorenzo Miniero wrote: > On Fri, 13 Sep 2013 13:45:36 -0700 > Ted Hardie wrote: >=20 >> Howdy, >>=20 >> I've now had lunch and nice coffee, and I take electrons in hand to answe= r >> your missive, sent earlier today. >>=20 >> On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick wrote: >>=20 >>> Big caveat as I post this: I am speaking strictly as an IETF participant= . >>> In particular: >> >>=20 >>=20 >>> All that said, I am concerned about the path being proposed, and I agree= >>> with Matthew's concern (though I feel somewhat less defeatist than his >>> assessment sounds): >>>=20 >>>=20 >>> On 9/13/13 11:59 AM, Matthew Kaufman wrote: >>>=20 >>>> 2. Should I expect "room-packing" for this "show of hands" (which I don= 't >>>> believe is the typical "hum" process for the IETF, either) as happened >>>> during the SDES discussion last time, and therefore need to bring as ma= ny >>>> people who've not participated in RTCWEB previously but who want my cod= ec >>>> to succeed as I can afford to fly to Vancouver? >>>=20 >>> I think this is a valid concern. Asking "who wants or can live with VP8?= " >>> and "who wants or can live with H.264?" might be a good start to the >>> discussion, but at that point, I'm going to want to hear *why* people >>> *can't* live with one or the other. >>=20 >>=20 >> That discussion is supposed to happen before this, not after, so that if >> there are issues which might be resolved, they can be. During the course= >> of the effort to find a solution here, there have been several such >> resolutions (Cisco, for example, graciously agreed to provide an open >> source H.264 implementation should it be selected, in order to handle >> objections that none were available). If there are issues which cannot b= e >> resolved, having a second discussion on what they are amounts to re-hashi= ng >> and doesn't do anything to move things forward. >=20 >=20 > Open source implementations are not the issue (we have x264 for that), lic= ensing is. x264 is GPL. I guess we're talking about an open source implementation with p= ermissive license (e.g BSD) Mamadou, >=20 > Lorenzo >=20 >=20 >>=20 >>> What I would *not* be interested in is yet another presentation from the= >>> proponents of either of these to tell me why one is better; >>=20 >>=20 >> One might surmise that this is because you do not intend to actually buil= d, >> deploy, or operate a service that relates to this. If someone puts forwa= rd >> a codec that is better (in human assessment, lines of code, or operating >> requirements) and meets the other criteria for deployment, why wouldn't y= ou >> want to hear about it? >>=20 >>=20 >>> I want to hear from *opponents* of the proposal to hear why the proposal= >>> would fail. Only then would I want to hear from proponents responding t= o >>> those objections. And then I'd like to see a summary of those objections= >>> and those responses by the chairs >>=20 >>=20 >> Pete, my dear mangel-wurzel and apple of my eye, that's the most process >> wonky thing you've said in a long while, which is saying something. The >> working group is trying to identify a common codec that can be used to >> avoid negotiation failure. If there is no common video codec, the networ= k >> effect of this system is much less. >> If there are people who have stated *they cannot live with this*, they ar= e >> not going to build, deploy, or operate services which use the common >> codec. The actual system we are trying to build will suffer. Judging >> consensus is not here an end in itself, it's a way of working out whether= >> or not the system we're building does or does not have a way to avoid the= >> negotiation failure. >>=20 >> We would not have spent the amount of time we have unless that were >> important, and we would not be considering using RFC 3929 unless we thoug= ht >> it was worth getting to a resolution. I implore you to stop treating thi= s >> as an academic exercise in consensus theory, and remind yourself that we'= re >> trying to do some engineering here. >>=20 >>=20 >>>=20 >>> With that summary, the chairs can make a call of whether there is any ho= pe >>> of consensus. I think much of that work can and should take place on the= >>> mailing list *before* the face-to-face meeting. >> But asking for a show of hands in the room for people who "can live with"= >>> one or the other and deciding whether or not consensus exists based on t= hat >>> show of hands is simply taking a vote, it's not judging consensus. >>=20 >>=20 >> That rather presumes you know the count. In several of our recent calls,= >> we have had unanimity, which is generally held to be a strong indicator o= f >> consensus. >>=20 >> The last time we had a straw poll which used similar language, we also ha= d >> absolutely no question that we had not achieved consensus. >>=20 >> Sometimes signals are strong. >>=20 >>=20 >>> You cannot know from that result whether the reason that some people cou= ld >>> not "live with" a proposal was simply because "my Aunt Gertrude told me >>> that I should say that I can't live with it." To ask for the show of han= ds >>> and then not find out what it means is not calling the consensus. And I >>> think moving to a 3929 alternative on the basis of that show of hands wo= uld >>> be improper. >>>=20 >>> If you re-read RFC 3929, you will discover that it requires that you mak= e >> an explicit call for its use; the consensus to use it standing in for the= >> consent on the technical matter. The working group chairs have no >> intention of skipping that step, should RFC 3929 be used. >>=20 >>=20 >>> Put me down as one voice who objects to the proposed procedure. >> So noted. >>=20 >> fondly, >>=20 >> Ted >>=20 >>=20 >>=20 >>> pr >>>=20 >>>=20 >>> On 9/13/2013 9:52 AM, Ted Hardie wrote: >>>>=20 >>>>> WG, >>>>>=20 >>>>> The chairs have created a plan for how to perform the Video Codec >>>>> selection in our WG. The chairs are asking for review of our plan on >>>>> how to undertake the mandatory-to-implement video codec selection. >>>>> We'd much prefer to have comments on the mechanics before they begin, >>>>> so please review now. Proponents of a particular proposal should >>>>> note both the actions required and the timelines proposed. >>>>>=20 >>>>> The main goal of this plan is to hold a consensus call on which of >>>>> the proposed alternatives we as a WG should select at one of the WG >>>>> sessions in Vancouver. Such a consensus call will of course be >>>>> verified on the mailing list for anyone who can't participate. The >>>>> chairs will recuse themselves from judging this particular >>>>> consensus. >>>>>=20 >>>>> In the WG session each codec proposal will be allowed an equal amount >>>>> of time to highlight the arguments for their proposal. After that a >>>>> there will be a slot for discussion and clarifying questions. >>>>>=20 >>>>> To enable the WG participants to get answers to any questions, the >>>>> proposals in draft form and any supporting material MUST be made >>>>> available by 6th of October. This is to ensure that the WG >>>>> participants can verify or object to any claims or statements in >>>>> the proposal material prior to the WG session. We chairs would really >>>>> not like to see the proponents bring up new arguments at their >>>>> presentation. Also the WG participants are expected to raise any >>>>> arguments on the list ahead of time to enable the proponents to >>>>> respond to such arguments. >>>>>=20 >>>>> The proposed consensus questions will be of the following form: >>>>>=20 >>>>> 1. If you support H.264 as the mandatory to implement codec or are >>>>> willing to live with it as the MTI, please raise your hand now. >>>>>=20 >>>>> 2. If you support VP8 as the mandatory to implement codec or are >>>>> willing to live with it as the MTI, please raise your hand now. >>>>>=20 >>>>> You may indicate support on both questions and we encourage you to do >>>>> so if you can live with either, even if you have a preference for one >>>>> over the other. >>>>>=20 >>>>> Additional proposals than the previous ones are welcome, but must be >>>>> submitted as draft and their proponents must notify the chairs no late= r >>>>> than the 6th of October that they also have a candidate proposal. >>>>>=20 >>>>> In case the WG fails to reach consensus we chairs propose that we use >>>>> the alternative decision process as discussed in RFC3929. The method >>>>> and its usage will be discussed on the list should the WG not >>>>> establish consensus on a proposal for mandatory to implement video cod= ec. >>>>>=20 >>>>> regards, >>>>>=20 >>>>> Magnus, Cullen, and Ted >>> -- >>> Pete Resnick >>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>>=20 >>>=20 >>> ______________________________**_________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/**listinfo/rtcweb >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From simon.perreault@viagenie.ca Fri Sep 13 23:02:48 2013 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 91F7C11E80E8; Fri, 13 Sep 2013 23:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcOIhkooFT1I; Fri, 13 Sep 2013 23:02:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E140611E80D1; Fri, 13 Sep 2013 23:02:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D43924149F; Sat, 14 Sep 2013 02:02:44 -0400 (EDT) Message-ID: <5233FC04.7040509@viagenie.ca> Date: Sat, 14 Sep 2013 08:02:44 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sergio Garcia Murillo References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> In-Reply-To: <52337505.9000109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sat, 14 Sep 2013 06:02:48 -0000 Le 2013-09-13 22:26, Sergio Garcia Murillo a écrit : > So, at the end, the ChannelData message is just another TURN message, so > it will be encapsulated inside a websocket frame. If you feel it is not > clear, we can add more details about it in next draft. You're right, I was mistaken about this. Thanks for the detailed explanation. No need for more details. > Regarding RFC 6062, we had some internal discussion regarding if we > should add websocket support at all to it or not. Mainly, because AFAIK, > webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am > wrong. I think a better justification would be "because WebRTC data channel will use SCTP over DTLS". > I agree with you that this has not been well covered in the draft. In > order to make the minimun changes possible, and align it with the > general view of changing just the turn client to turn server > encapsulation protocol, I would propose to extend websockets usage only > for the turn control connection in RFC 6062 but keep turn data > connections on TCP. So with an HTTP proxy the control would be over websockets and the data would be through the CONNECT method? Yuck... > That, or drop RFC 6062 extension altogether and just > focus on 5766. What do you feel it would be best? I say focus on 5766. I have a new question: what does the TURN server put in the XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's address? Can TURN over WebSockets be used to gather server-reflexive candidates? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hangzhou.chenxin@huawei.com Sat Sep 14 01:53:44 2013 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 9269321F9DDE; Sat, 14 Sep 2013 01:53:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVPLBMFQ8-Tj; Sat, 14 Sep 2013 01:53:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DC21F9DDB; Sat, 14 Sep 2013 01:53:39 -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.7-GA FastPath queued) with ESMTP id AXU05003; Sat, 14 Sep 2013 08:53:33 +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.3.146.0; Sat, 14 Sep 2013 09:53:13 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 09:53:29 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0146.000; Sat, 14 Sep 2013 16:53:22 +0800 From: "Chenxin (Xin)" To: Simon Perreault , Sergio Garcia Murillo Thread-Topic: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt Thread-Index: AQHOsL+XhyORzIvU1ESsGxOV4IuYl5nEOHMAgACbzYA= Date: Sat, 14 Sep 2013 08:53:21 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> In-Reply-To: <5233FC04.7040509@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sat, 14 Sep 2013 08:53:44 -0000 Hi Simon, >> I agree with you that this has not been well covered in the draft. In >> order to make the minimun changes possible, and align it with the >> general view of changing just the turn client to turn server >> encapsulation protocol, I would propose to extend websockets usage only >> for the turn control connection in RFC 6062 but keep turn data >> connections on TCP. > >So with an HTTP proxy the control would be over websockets and the data >would be through the CONNECT method? Yuck... Or using websocket multiplexing http://tools.ietf.org/html/draft-ietf-hybi-= websocket-multiplexing-11 .=20 > >> That, or drop RFC 6062 extension altogether and just >> focus on 5766. What do you feel it would be best? > >I say focus on 5766. > >I have a new question: what does the TURN server put in the >XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >address?=20 The proxy's address. I do not think this attribute will help ICE process.=20 Can TURN over WebSockets be used to gather server-reflexive >candidates? Yes, It could do as UDP and TCP. But when there is a http proxy. I think th= e server reflexive candidates will be the address of proxy, which means not= hing for the peer. But if there is only NAT, the server reflexive candidate= s is possible to work in the ICE. Best Regard, Xin > >Simon >-- >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From simon.perreault@viagenie.ca Sat Sep 14 02:14:11 2013 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 B5F0521E812C; Sat, 14 Sep 2013 02:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE+k8t+uSHIT; Sat, 14 Sep 2013 02:14:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90BE311E8147; Sat, 14 Sep 2013 02:14:10 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2C2C1403CF; Sat, 14 Sep 2013 05:13:56 -0400 (EDT) Message-ID: <523428D2.8050505@viagenie.ca> Date: Sat, 14 Sep 2013 11:13:54 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Chenxin (Xin)" References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sat, 14 Sep 2013 09:14:11 -0000 Le 2013-09-14 10:53, Chenxin (Xin) a écrit : >> I have a new question: what does the TURN server put in the >> XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >> address? > > The proxy's address. I do not think this attribute will help ICE process. > > Can TURN over WebSockets be used to gather server-reflexive >> candidates? > > Yes, It could do as UDP and TCP. But when there is a http proxy. I think the server reflexive candidates will be the address of proxy, which means nothing for the peer. Isn't this a big problem? I mean, if the client cannot trust the value of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and everything else? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Sat Sep 14 03:01:41 2013 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 5C55921E8195 for ; Sat, 14 Sep 2013 03:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gPbvF1nh9NH for ; Sat, 14 Sep 2013 03:01:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4E21E8194 for ; Sat, 14 Sep 2013 03:01:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66E46403CF for ; Sat, 14 Sep 2013 06:01:37 -0400 (EDT) Message-ID: <52343400.3090408@viagenie.ca> Date: Sat, 14 Sep 2013 12:01:36 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> <20130914002635.3ebddfef@rainpc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Video Codec Selection Plan 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, 14 Sep 2013 10:01:41 -0000 Le 2013-09-14 01:19, Bossiel a écrit : >>> Cisco, for example, graciously agreed to provide an open >>> source H.264 implementation should it be selected, in order to handle >>> objections that none were available >> >> Open source implementations are not the issue (we have x264 for that), licensing is. > x264 is GPL. I guess we're talking about an open source implementation with permissive license (e.g BSD) I understand that the issue is the licensing of the IPR, not of the code. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hangzhou.chenxin@huawei.com Sat Sep 14 03:25:49 2013 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 6E55921E81B6; Sat, 14 Sep 2013 03:25:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMjOLv3iGZts; Sat, 14 Sep 2013 03:25:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 240A221E81AD; Sat, 14 Sep 2013 03:25:43 -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 AVK01983; Sat, 14 Sep 2013 10:25:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 11:23:32 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 11:23:49 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Sat, 14 Sep 2013 18:23:44 +0800 From: "Chenxin (Xin)" To: Simon Perreault Thread-Topic: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt Thread-Index: AQHOsSrDIYEbSyC+fUOCPacmrLHxDJnE/cCw Date: Sat, 14 Sep 2013 10:23:43 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F3C1@SZXEMA504-MBX.china.huawei.com> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> In-Reply-To: <523428D2.8050505@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sat, 14 Sep 2013 10:25:49 -0000 Hi Simon, >>> I have a new question: what does the TURN server put in the >>> XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >>> address? >> >> The proxy's address. I do not think this attribute will help ICE process= . >> >> Can TURN over WebSockets be used to gather server-reflexive >>> candidates? >> >> Yes, It could do as UDP and TCP. But when there is a http proxy. I think= the >server reflexive candidates will be the address of proxy, which means noth= ing for >the peer. > >Isn't this a big problem? I mean, if the client cannot trust the value >of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE >and everything else? > Thanks for your question. You are right about it. We should consider more a= bout gathering the server reflexive candidates in turn over websocket. I have checked the RFC 5766 again: Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the mapped address allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR- MAPPED-ADDRESS) in STUN responses. Which restricts that the "Reflexive Transport Address" should be obtained f= rom NAT. It will be semantic problem if this address is from proxy. In ICE, I have not found out the harmful scenario yet. It will be possible = to make ICE Connectivity Checks failed, but it will be possible to be usefu= l.=20 I am still thinking about how to handle it. Should we just leave it to for = the usage of gathering candidate from NAT? OR totally forbid it in the turn= over websocket? What is your suggestion? >Simon >-- >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From bossiel@yahoo.fr Sat Sep 14 04:00:50 2013 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 A02E711E8159 for ; Sat, 14 Sep 2013 04:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2gkzEy0Yl0T for ; Sat, 14 Sep 2013 04:00:46 -0700 (PDT) Received: from nm2-vm1.bullet.mail.ird.yahoo.com (nm2-vm1.bullet.mail.ird.yahoo.com [77.238.189.200]) by ietfa.amsl.com (Postfix) with SMTP id D21F611E8156 for ; Sat, 14 Sep 2013 04:00:45 -0700 (PDT) Received: from [77.238.189.236] by nm2.bullet.mail.ird.yahoo.com with NNFMP; 14 Sep 2013 11:00:44 -0000 Received: from [46.228.39.93] by tm17.bullet.mail.ird.yahoo.com with NNFMP; 14 Sep 2013 11:00:43 -0000 Received: from [127.0.0.1] by smtp130.mail.ir2.yahoo.com with NNFMP; 14 Sep 2013 11:00:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1379156443; bh=35j0Bp0R6i9XimpD8u/IaqH9b4swsQ8/qze38kE0D40=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=XpEeS0A8naldrFZ6vS/tMeiWTEllN+wShPi90JBZFTyU7F0fV1auukjkyfNwaCMzjioo8HxEJ5bVxLsmhIID0/bIdcYZqdT+d737fnoUamBHIzGHB1fzoX8BaEiu+sSRt0OFzq/G6+OeQ5Ab7c2QydVPyZt/uj+CcJBX1FU8LKk= X-Yahoo-Newman-Id: 930069.56922.bm@smtp130.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: W00hnYEVM1lfU99Eu4YYavCF9jySYELMzE4c50vkunrKYzo DwZgEYUkS6IAt4S1yzfYv0LFrA1B0wtWk8.bCHhWkBT.NqsKqZ0FaXMvRWCf SJXmmHpAV9Z4V6dVpUp9TeZpwncBO0UhtI_MQ5vUl3UtNgzcnNV1JS5Pf8D7 TWa32oBtw417Hhv9kzLiAf71NCz24Jujj_JQuxosB1e8AxVeOWj4fVod1rRe XaXMAOT0hYlVpzLzrVXp2jRK_8IxQfN4EKxKz1N0mg5QJS7wXnZwxkNlZPk5 UGAnpWJSwG_RlAkYop4Pz04E9BZ55i26VNyPpX1sJseJe_0W1pXuW3XIjUB6 dHrTVetngicQD.0nRij2D41zeHUuSv4o.Dmv7ZjH754rdZVDkwBxLw2ibFSx eUHhxRSuQ6x8gd75Jt.6EQdk3ao5mvX56MjQxZQp5NuMCd3qr6UDDtdIBBQr NSVE2EKDC3zAkoo3lmlmOimtXpacyl3IdAnDiViiSkVjdIyFrxh9Jg94DuPh ZSk0zS6e.YTD.FAnVfY71PhknKk8dwC..R.qgOx9yYTsfwgKP2rFuXeADm32 c_q3GEaZlWHLYSYJvQFkGJGg- X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp130.mail.ir2.yahoo.com with SMTP; 14 Sep 2013 11:00:43 +0000 UTC References: <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> <20130914002635.3ebddfef@rainpc> <52343400.3090408@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <52343400.3090408@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Bossiel Date: Sat, 14 Sep 2013 13:00:43 +0200 To: Simon Perreault Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 14 Sep 2013 11:00:50 -0000 Sent from my iPhone On Sep 14, 2013, at 12:01, Simon Perreault wro= te: > Le 2013-09-14 01:19, Bossiel a =C3=A9crit : >>>> Cisco, for example, graciously agreed to provide an open >>>> source H.264 implementation should it be selected, in order to handle >>>> objections that none were available >>>=20 >>> Open source implementations are not the issue (we have x264 for that), l= icensing is. >> x264 is GPL. I guess we're talking about an open source implementation wi= th permissive license (e.g BSD) >=20 > I understand that the issue is the licensing of the IPR, not of the code. Both >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From sergio.garcia.murillo@gmail.com Sat Sep 14 13:30:36 2013 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 1543921E80C8; Sat, 14 Sep 2013 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNMNejYtxm-a; Sat, 14 Sep 2013 13:30:35 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1421E80B1; Sat, 14 Sep 2013 13:30:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so2040532wib.1 for ; Sat, 14 Sep 2013 13:30:34 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BDm1u7UZbTOoNyP6lLXlswSqTnYyzx0KPUInCFFCEtk=; b=K/Vr+CjAdm9WUUHMrq15eZDwkteMsGlm/fGY7hf/B6p6mpd3SunR+hXjcrn6s2CDm/ iV1vdl4noqBZEf2Hjix4Qx4dYsLwt2R8PYqIlyjgqFp/jz85Q6B1LjZSx5DfaBJYHCYx zlqSPgRuaY6At6+HuZJCM4ca6fy7UFVjol4TTd4t4OpxEaYr+zigqG4Mj+GGx1LjOoQO LFpNroDoNyM+VWi9PhsSuXynJ8UGTd/HX0GQuzUqIqzM26gZ/3aIxZwCrY/Jubfv4Sjr +ig/KkEagNXuUJ+2ajdDk2NvHynElwXGe65GvEi2WBdApyfZFqht2FU5wG2qV0w5qb8s mUlQ== X-Received: by 10.180.77.68 with SMTP id q4mr7506580wiw.4.1379190634453; Sat, 14 Sep 2013 13:30:34 -0700 (PDT) Received: from [192.168.1.55] (76.Red-88-6-196.staticIP.rima-tde.net. [88.6.196.76]) by mx.google.com with ESMTPSA id gp9sm12285932wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 13:30:33 -0700 (PDT) Message-ID: <5234C773.3090409@gmail.com> Date: Sat, 14 Sep 2013 22:30:43 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> In-Reply-To: <5233FC04.7040509@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sat, 14 Sep 2013 20:30:36 -0000 El 14/09/2013 8:02, Simon Perreault escribió: > > I have a new question: what does the TURN server put in the > XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's > address? Can TURN over WebSockets be used to gather server-reflexive > candidates? > > From my point of view, the value of the XOR-MAPPED-ADDRESS should be the same as when using TURN over TLS on the same scenario (if it happens to work), that would be either the HTTP proxy address or any NAT happening after it. Best regards Sergio From martin.thomson@gmail.com Sat Sep 14 23:43:00 2013 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 6B9B921E809D; Sat, 14 Sep 2013 23:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKpDo3mGib-r; Sat, 14 Sep 2013 23:42:59 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5A21E809C; Sat, 14 Sep 2013 23:42:59 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so2463077wgh.26 for ; Sat, 14 Sep 2013 23:42: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=7/9TB6OL/vXpa1XH+bR24FP2pnuHjjJICdgkq6PTpW4=; b=qHvZmxuu+V8adTSMYCm8pQ+eDNoYODTUUrdjUWw3xahYE1PbX7FHAeYJrvL6UwWGYq qDuyXALWOfw+Nf+Y0Q8KgkpCraklM6cuUCxeQUgTFpkSskaf6JY+4ldrzuD7KuEVQ8Vj 0wofE80Zu3LerRr3PdSMi2u4L5GqXSzSHGtMEhAdxk9NFueNGmyQMKGNYGWm3sfCdDUx gVloLQZRmeE0U4PydWSZ8EYiyJ7gsd3A+/BSzohQ0hufrnmCHE1Sjo7CNoVR1UZ5N00e c8/zuGi0E/0I77xz3gpBywJc+taGssBFC4SG2Yzz1wQtVDUSjM1ShwjXDuRJ6xLcX9Y8 ljCA== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr8710174wic.14.1379227378249; Sat, 14 Sep 2013 23:42:58 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Sat, 14 Sep 2013 23:42:58 -0700 (PDT) In-Reply-To: <523428D2.8050505@viagenie.ca> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> Date: Sat, 14 Sep 2013 23:42:58 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sun, 15 Sep 2013 06:43:00 -0000 On 14 September 2013 02:13, Simon Perreault wrote: > Isn't this a big problem? I mean, if the client cannot trust the value of > the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and > everything else? Hardly. You just lose that option. It might suck if you needed it, but given that you are using a relay, it's probably not that bad. The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with TURN over TCP. Same upside. From simon.perreault@viagenie.ca Sun Sep 15 00:24:31 2013 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 8B9AA11E80ED; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R-57pGAGzdH; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 099CA11E80E8; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 10A2240413; Sun, 15 Sep 2013 03:24:29 -0400 (EDT) Message-ID: <523560AD.8070109@viagenie.ca> Date: Sun, 15 Sep 2013 09:24:29 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Martin Thomson References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Sun, 15 Sep 2013 07:24:31 -0000 Le 2013-09-15 08:42, Martin Thomson a écrit : > On 14 September 2013 02:13, Simon Perreault wrote: >> Isn't this a big problem? I mean, if the client cannot trust the value of >> the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and >> everything else? > > Hardly. You just lose that option. It might suck if you needed it, > but given that you are using a relay, it's probably not that bad. > > The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with > TURN over TCP. Same upside. True. Then shouldn't server-reflexive candidates always be gathered using plain STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would be ignored (or even not sent) for TURN-over-anything-but-UDP. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From magnus.westerlund@ericsson.com Sun Sep 15 23:04:33 2013 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 222C611E8200 for ; Sun, 15 Sep 2013 23:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.542 X-Spam-Level: X-Spam-Status: No, score=-105.542 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWFLqJHekC0s for ; Sun, 15 Sep 2013 23:04:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6098511E81C3 for ; Sun, 15 Sep 2013 23:04:25 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-54-52369f68214b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 33.8B.22048.86F96325; Mon, 16 Sep 2013 08:04:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Mon, 16 Sep 2013 08:04:23 +0200 Message-ID: <52369FA7.1010209@ericsson.com> Date: Mon, 16 Sep 2013 08:05:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roni Even References: <00b301ceb0d1$8d4006c0$a7c01440$@gmail.com> In-Reply-To: <00b301ceb0d1$8d4006c0$a7c01440$@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvjW7mfLMgg+WfOCw6JrNZ/G1ntlj7 r53donGunQOLx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6M/8t+sRa85aqYvOkN YwPjXY4uRk4OCQETifen5rNA2GISF+6tZ+ti5OIQEjjMKDF712pWCGc5o8SWlmmsIFW8AtoS vw+vZwexWQRUJXa83MgGYrMJWEjc/NEIZosKBEu0b//KBlEvKHFy5hOwDSICahKv134GizML JEisnPyCEcQWFjCQeNl4gxnEFhKokbi15jrYfE6gmWeO3Ia6TlJi26Jj7BC9ehJTrrYwQtjy Es1bZ0P1aks0NHWwTmAUmoVk9SwkLbOQtCxgZF7FyJ6bmJmTXm6+iREYxAe3/DbYwbjpvtgh RmkOFiVx3s16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MGYtPvUgJDz5ZNRthsUvK7+l /169Qk6tNf50tc36o7WTfYpip7WZ1HhNm15ec6zYXceW5/C604nClyf5FDDuWxDn87fe/N2f FU5TeXrajl3j2VNRvU10ifSHmBcCh/wWKgVLLEk80px69tHi/RvK132ef9fuq4jnsq0vdt5j PN0zYX15tbDn+nNKLMUZiYZazEXFiQA3oZNaMAIAAA== Cc: 'Cullen Jennings' , rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Plan 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, 16 Sep 2013 06:04:33 -0000 On 2013-09-14 00:35, Roni Even wrote: > Ted, > > What is the difference between the proposed questions and the ones that > were asked in Orlando, we had documents and presentations and could not > reach a decision in Orlando. > > If nothing changed we can start with the proposal to use alternative > decision process. > Roni, In Orlando we took only a straw poll as it was clear to the chairs that people would have objected against a consensus call. Reasons for that include the lack of licensing terms related to the IPR that Google from other IPR right holders. We like to avoid be in the same situation and be unable to hold a formal consensus call. Thus, we have set an early dead line for any proposals to enable all WG participants to review the proposals and raise any issues on the mailing list. Thus enabling such issues to be responded to and possibly resolved. Cheers Magnus Westerlund WG chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From chris-ietf@chriswendt.net Mon Sep 16 06:20:17 2013 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 8A48311E8266 for ; Mon, 16 Sep 2013 06:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufzM78I-op94 for ; Mon, 16 Sep 2013 06:20:12 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7263B11E826A for ; Mon, 16 Sep 2013 06:20:12 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so1053930qaq.3 for ; Mon, 16 Sep 2013 06:20:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8jI3fClY/U6PYDZtwZp4lWeBw/6+uDIt6nktU7SQ3BE=; b=ZpJRnkk205cV6d/1mGevn9zOPm79jb6p5YeTYI+pzDXYjEwTPPdAWrMkvqSWb7tUUI BUvbt7krzER5blLMaUQlhXajD8tu6RchzmGNBNQdk5sQRaWTIme/kcj5a2aYHm27507I jF9h9gZnoQDLH3+MptcKPSadb5zA/OSyqjmofe7zKd8P0jKvXdMByZIbphIFEtJe1WkZ kOie+nBfsGolb5Qzk2d2gM1YOa7T/UBqUKqb319C2tIa1iOTh6KBnnAVZhA8BXMU49pb I3wKKwb8SGmOJyXgrA6A4g2jLnsdu6WAeOv0jSvIppC1WjDCoV9UhJhmabBFCd8ap2Kn PWCw== X-Gm-Message-State: ALoCoQmPiGrFWyDEnKIOxUfq5D5qi6ZuwP2zIFH56zl2vYwZuaTGJ3dvwxOjiGxVMmmnM8cySF8l X-Received: by 10.224.5.199 with SMTP id 7mr15976764qaw.16.1379337611667; Mon, 16 Sep 2013 06:20:11 -0700 (PDT) Received: from [10.36.87.157] ([69.241.19.12]) by mx.google.com with ESMTPSA id f14sm47842246qej.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 06:20:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BF6239A8-1C5E-463D-BFC1-F071D33E5387" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1805\)) From: Chris Wendt In-Reply-To: Date: Mon, 16 Sep 2013 09:20:10 -0400 Message-Id: <059B913C-278A-4116-B8FC-B65072CF874F@chriswendt.net> References: To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1805) Subject: Re: [rtcweb] Video Codec Selection Plan 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, 16 Sep 2013 13:20:17 -0000 --Apple-Mail=_BF6239A8-1C5E-463D-BFC1-F071D33E5387 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I would argue that because we have selected Opus and G.711, we have = already satisfied the charter requirements. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. Can we move on and focus time on more relevant issues? -Chris On Sep 13, 2013, at 1:11 PM, Bernard Aboba = wrote: > Ted -- >=20 > The H.264 vs. VP8 discussion has at this point been "overtaken by = events", so that the proposed plan below would be a waste of everybody's = time, about as relevant as debating the fashion merits of bell bottoms = versus nehru jackets. =20 >=20 > With Google having announced plans to implement VP9 (potentially with = SVC), and with the recent ratification of H.265, the industry has moved = on, and so should RTCWEB.=20 >=20 > Date: Fri, 13 Sep 2013 09:52:24 -0700 > From: ted.ietf@gmail.com > To: rtcweb@ietf.org; fluffy@cisco.com; magnus.westerlund@ericsson.com > Subject: [rtcweb] Video Codec Selection Plan >=20 > WG, >=20 > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. >=20 > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. >=20 > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. >=20 > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. >=20 > The proposed consensus questions will be of the following form: >=20 > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. >=20 > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. >=20 > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. >=20 > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no = later > than the 6th of October that they also have a candidate proposal. >=20 > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video = codec. >=20 > regards, >=20 > Magnus, Cullen, and Ted >=20 > _______________________________________________ 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 --Apple-Mail=_BF6239A8-1C5E-463D-BFC1-F071D33E5387 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

I would argue that because we = have selected Opus and G.711, we have already satisfied the charter = requirements.

  6.  Define a set of media formats that must or = should be supported by
        a client to improve = interoperability.

Can we move on and = focus time on more relevant = issues?

-Chris


= On Sep 13, 2013, at 1:11 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

Ted = --

The H.264 vs. VP8 discussion has at this point = been "overtaken by events", so that the proposed plan below would be a = waste of everybody's time, about as relevant as debating the fashion = merits of bell bottoms versus nehru jackets. =  

With Google having announced plans to = implement VP9 (potentially with SVC), and with the recent ratification = of H.265, the industry has moved on, and so should = RTCWEB. 

Date: Fri, 13 = Sep 2013 09:52:24 -0700
From: ted.ietf@gmail.com
To: rtcweb@ietf.org; fluffy@cisco.com; magnus.westerlund@ericsson.= com
Subject: [rtcweb] Video Codec Selection Plan

WG,

The chairs have created a plan for how to = perform the Video Codec
selection in our WG. The chairs are asking = for review of our plan on
how to undertake the mandatory-to-implement = video codec selection.
We'd much prefer to have comments on the = mechanics before they begin,
so please review now.  Proponents = of a particular proposal should
note both the actions required and = the timelines proposed.

The main goal of this plan is to hold a = consensus call on which of
the proposed alternatives we as a WG = should select at one of the WG
sessions in Vancouver. Such a = consensus call will of course be
verified on the mailing list for = anyone who can't participate. The
chairs will recuse themselves from = judging this particular
consensus.

In the WG session each = codec proposal will be allowed an equal amount
of time to highlight = the arguments for their proposal. After that a
there will be a slot = for discussion and clarifying questions.

To enable the WG = participants to get answers to any questions, the
proposals in draft = form and any supporting material MUST be made
available by 6th of = October. This is to ensure that the WG
participants can verify or = object to any claims or statements in
the proposal material prior to = the WG session. We chairs would really
not like to see the proponents = bring up new arguments at their
presentation. Also the WG = participants are expected to raise any
arguments on the list ahead of = time to enable the proponents to
respond to such = arguments.

The proposed consensus questions will be of the = following form:

1. If you support H.264 as the mandatory to = implement codec or are
willing to live with it as the MTI, please = raise your hand now.

2. If you support VP8 as the mandatory to = implement codec or are
willing to live with it as the MTI, please = raise your hand now.

You may indicate support on both questions = and we encourage you to do
so if you can live with either, even if = you have a preference for one
over the other.

Additional = proposals than the previous ones are welcome, but must be
submitted = as draft and their proponents must notify the chairs no later
than = the 6th of October that they also have a candidate proposal.

In = case the WG fails to reach consensus we chairs propose that we = use
the alternative decision process as discussed in RFC3929. The = method
and its usage will be discussed on the list should the WG = not
establish consensus on a proposal for mandatory to implement = video codec.

regards,

Magnus,  = Cullen, and = Ted

_______________________________________________ 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

= --Apple-Mail=_BF6239A8-1C5E-463D-BFC1-F071D33E5387-- From cb.list6@gmail.com Mon Sep 16 10:38:01 2013 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 B33AC11E82B2 for ; Mon, 16 Sep 2013 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA3980gfQcIg for ; Mon, 16 Sep 2013 10:38:00 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D8BE111E8108 for ; Mon, 16 Sep 2013 10:37:59 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so3957076wes.35 for ; Mon, 16 Sep 2013 10:37:59 -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=U9ChPSQOa0TxiOQx5XxGBa84syK6yRzGSdDqz/TIzd4=; b=zjN3FixCdN9uY4hxYcuhxoI0uWKzB3Z+8oFgeNESo1Qh8yrsj0HZBthL84jdmzmg67 9ywDvCUMxeBVrZcT/LO8WgBdWcfIW4eIoMP3oojLOv8eXNDFqy8No5ZCXLW0ujnH53hf BuoMvTSZjHIewFfRow2UqbGaSnAWXzpEdG4Jb2Blk35gOXpaX0CRVwcUxffHuZpN4jZn uJ8WysMq6y1PM/FTFVu7uGxYlry2z3w4A7FO22dE79dHPMU6CyHagHwV5kOOHa1qLeLM NEgk02ynD/4ZhdkQFmt8sZa0fQwXoKoqJEeUC1xgvfIsrWGjkT/jjO1hxFqsARmauVCV TjfA== MIME-Version: 1.0 X-Received: by 10.181.12.75 with SMTP id eo11mr14348379wid.24.1379353078987; Mon, 16 Sep 2013 10:37:58 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Mon, 16 Sep 2013 10:37:58 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Mon, 16 Sep 2013 10:37:58 -0700 (PDT) In-Reply-To: <059B913C-278A-4116-B8FC-B65072CF874F@chriswendt.net> References: <059B913C-278A-4116-B8FC-B65072CF874F@chriswendt.net> Date: Mon, 16 Sep 2013 10:37:58 -0700 Message-ID: From: "cb.list6" To: Chris Wendt Content-Type: multipart/alternative; boundary=f46d043c7c564b02f804e683aa86 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Plan 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, 16 Sep 2013 17:38:01 -0000 --f46d043c7c564b02f804e683aa86 Content-Type: text/plain; charset=ISO-8859-1 On Sep 16, 2013 6:22 AM, "Chris Wendt" wrote: > > > I would argue that because we have selected Opus and G.711, we have already satisfied the charter requirements. > > 6. Define a set of media formats that must or should be supported by > a client to improve interoperability. > > Can we move on and focus time on more relevant issues? > +1, the mti video is the already agreed audio-only. If your video does not work, you and the calling/called party can discuss about the ipr issues and politics that limit your communications CB > -Chris > > > On Sep 13, 2013, at 1:11 PM, Bernard Aboba wrote: > >> Ted -- >> >> The H.264 vs. VP8 discussion has at this point been "overtaken by events", so that the proposed plan below would be a waste of everybody's time, about as relevant as debating the fashion merits of bell bottoms versus nehru jackets. >> >> With Google having announced plans to implement VP9 (potentially with SVC), and with the recent ratification of H.265, the industry has moved on, and so should RTCWEB. >> >> ________________________________ >> Date: Fri, 13 Sep 2013 09:52:24 -0700 >> From: ted.ietf@gmail.com >> To: rtcweb@ietf.org; fluffy@cisco.com; magnus.westerlund@ericsson.com >> Subject: [rtcweb] Video Codec Selection Plan >> >> WG, >> >> The chairs have created a plan for how to perform the Video Codec >> selection in our WG. The chairs are asking for review of our plan on >> how to undertake the mandatory-to-implement video codec selection. >> We'd much prefer to have comments on the mechanics before they begin, >> so please review now. Proponents of a particular proposal should >> note both the actions required and the timelines proposed. >> >> The main goal of this plan is to hold a consensus call on which of >> the proposed alternatives we as a WG should select at one of the WG >> sessions in Vancouver. Such a consensus call will of course be >> verified on the mailing list for anyone who can't participate. The >> chairs will recuse themselves from judging this particular >> consensus. >> >> In the WG session each codec proposal will be allowed an equal amount >> of time to highlight the arguments for their proposal. After that a >> there will be a slot for discussion and clarifying questions. >> >> To enable the WG participants to get answers to any questions, the >> proposals in draft form and any supporting material MUST be made >> available by 6th of October. This is to ensure that the WG >> participants can verify or object to any claims or statements in >> the proposal material prior to the WG session. We chairs would really >> not like to see the proponents bring up new arguments at their >> presentation. Also the WG participants are expected to raise any >> arguments on the list ahead of time to enable the proponents to >> respond to such arguments. >> >> The proposed consensus questions will be of the following form: >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> You may indicate support on both questions and we encourage you to do >> so if you can live with either, even if you have a preference for one >> over the other. >> >> Additional proposals than the previous ones are welcome, but must be >> submitted as draft and their proponents must notify the chairs no later >> than the 6th of October that they also have a candidate proposal. >> >> In case the WG fails to reach consensus we chairs propose that we use >> the alternative decision process as discussed in RFC3929. The method >> and its usage will be discussed on the list should the WG not >> establish consensus on a proposal for mandatory to implement video codec. >> >> regards, >> >> Magnus, Cullen, and Ted >> >> _______________________________________________ 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 > --f46d043c7c564b02f804e683aa86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 16, 2013 6:22 AM, "Chris Wendt" <chris-ietf@chriswendt.net> wrote:
>
>
> I would argue that because we have selected Opus and G.711, we have al= ready satisfied the charter requirements.
>
> =A0 6.=A0 Define a set of media formats that must or should be support= ed by
> =A0=A0=A0=A0=A0=A0=A0 a client to improve interoperability.
>
> Can we move on and focus time on more relevant issues?
>

+1, the mti video is the already agreed audio-only.

If your video does not work, you and the calling/called part= y can discuss about the ipr issues and politics that limit your communicati= ons

CB
> -Chris
>
>
> On Sep 13, 2013, at 1:11 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
>
>> Ted --
>>
>> The H.264 vs. VP8 discussion has at this point been "overtake= n by events", so that the proposed plan below would be a waste of ever= ybody's time, about as relevant as debating the fashion merits of bell = bottoms versus nehru jackets. =A0
>>
>> With Google having announced plans to implement VP9 (potentially w= ith SVC), and with the recent ratification of H.265, the industry has moved= on, and so should RTCWEB.=A0
>>
>> ________________________________
>> Date: Fri, 13 Sep 2013 09:52:24 -0700
>> From: ted.ietf@gmail.com=
>> To: rtcweb@ietf.org; fluffy@cisco.com; magnus.westerlund@ericsson.com
>> Subject: [rtcweb] Video Codec Selection Plan
>>
>> WG,
>>
>> The chairs have created a plan for how to perform the Video Codec<= br> >> selection in our WG. The chairs are asking for review of our plan = on
>> how to undertake the mandatory-to-implement video codec selection.=
>> We'd much prefer to have comments on the mechanics before they= begin,
>> so please review now.=A0 Proponents of a particular proposal shoul= d
>> note both the actions required and the timelines proposed.
>>
>> The main goal of this plan is to hold a consensus call on which of=
>> the proposed alternatives we as a WG should select at one of the W= G
>> sessions in Vancouver. Such a consensus call will of course be
>> verified on the mailing list for anyone who can't participate.= The
>> chairs will recuse themselves from judging this particular
>> consensus.
>>
>> In the WG session each codec proposal will be allowed an equal amo= unt
>> of time to highlight the arguments for their proposal. After that = a
>> there will be a slot for discussion and clarifying questions.
>>
>> To enable the WG participants to get answers to any questions, the=
>> proposals in draft form and any supporting material MUST be made >> available by 6th of October. This is to ensure that the WG
>> participants can verify or object to any claims or statements in >> the proposal material prior to the WG session. We chairs would rea= lly
>> not like to see the proponents bring up new arguments at their
>> presentation. Also the WG participants are expected to raise any >> arguments on the list ahead of time to enable the proponents to >> respond to such arguments.
>>
>> The proposed consensus questions will be of the following form: >>
>> 1. If you support H.264 as the mandatory to implement codec or are=
>> willing to live with it as the MTI, please raise your hand now. >>
>> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >>
>> You may indicate support on both questions and we encourage you to= do
>> so if you can live with either, even if you have a preference for = one
>> over the other.
>>
>> Additional proposals than the previous ones are welcome, but must = be
>> submitted as draft and their proponents must notify the chairs no = later
>> than the 6th of October that they also have a candidate proposal.<= br> >>
>> In case the WG fails to reach consensus we chairs propose that we = use
>> the alternative decision process as discussed in RFC3929. The meth= od
>> and its usage will be discussed on the list should the WG not
>> establish consensus on a proposal for mandatory to implement video= codec.
>>
>> regards,
>>
>> Magnus,=A0 Cullen, and Ted
>>
>> _______________________________________________ rtcweb mailing lis= t rtcweb@ietf.org https://www.ietf.org/mailman/listinf= o/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--f46d043c7c564b02f804e683aa86-- From creslin@digium.com Mon Sep 16 12:39:43 2013 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 7923D11E8322 for ; Mon, 16 Sep 2013 12:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj8zqCZNkvfY for ; Mon, 16 Sep 2013 12:39:38 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 790E411E830D for ; Mon, 16 Sep 2013 12:39:35 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so4518738lbh.5 for ; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RCBLuwYdHdsFtkewwTZmLx3aQqeqppEstb59nWLRVKE=; b=Cd1wGUQ4UPLjrGbAD+G5p6VN09gBBL/FlKs2z5vIrn5drJgdQkDSejLcgRRbD5TTpH +464k6mJ4t1kitGn/CPF3I8eSjlYNFDZu5T6nJjzSYZasnU2QeqZsYsiUsTVlzcDmhDP DfyzOnh69oTBkaI/BToJ+QcgL+wvwvlI/0aG7/8j8XfyJKn5/0virzj/w4I03n0nM9Bv mypa9kkQ87KKUZAcm3FC8hWwMq+oj//q5MZvaLGx6HujiVR/rC0Nijitqc6wwZvu09d6 fFKC+4BxCYAjf1S0UdVjRmQYh5pKVS37+jwnU+Cf48b4LpFylLfqXQLC0u5020XZVoqm 78jw== X-Gm-Message-State: ALoCoQnxFLBk2N9tkMPfx4ftgfp/ZTb82kIRYlb+BWO/psKw2atg9du0gkDEKS7EQT0N7cLAiK0K MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr7534343lbc.24.1379360374221; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) Received: by 10.112.132.102 with HTTP; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) In-Reply-To: <523560AD.8070109@viagenie.ca> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> <523560AD.8070109@viagenie.ca> Date: Mon, 16 Sep 2013 14:39:34 -0500 Message-ID: From: Matt Fredrickson To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c233ea1f7fa404e6855d84 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-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: Mon, 16 Sep 2013 19:39:43 -0000 --001a11c233ea1f7fa404e6855d84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2013 at 2:24 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2013-09-15 08:42, Martin Thomson a =E9crit : > > On 14 September 2013 02:13, Simon Perreault >> wrote: >> >>> Isn't this a big problem? I mean, if the client cannot trust the value = of >>> the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and >>> everything else? >>> >> >> Hardly. You just lose that option. It might suck if you needed it, >> but given that you are using a relay, it's probably not that bad. >> >> The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with >> TURN over TCP. Same upside. >> > > True. > > Then shouldn't server-reflexive candidates always be gathered using plain > STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would be > ignored (or even not sent) for TURN-over-anything-but-UDP. That's what I was beginning to think as well... Is there any utility to be gained by advertising XOR-MAPPED-ADDRESS on transport types that (at least it would so seem to me) preclude its usage? Matthew Fredrickson --001a11c233ea1f7fa404e6855d84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 15, 2013 at 2:24 AM, Simon Perreault <= simon.perr= eault@viagenie.ca> wrote:
Le 2013-09-15 08:42, Martin Thomson a =E9cri= t :

On 14 September 2013 02:13, Simon Perreault <simon.perreault@viagenie.ca> w= rote:
Isn't this a big problem? I mean, if the client cannot trust the value = of
the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and<= br> everything else?

Hardly. =A0You just lose that option. =A0It might suck if you needed it, but given that you are using a relay, it's probably not that bad.

The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with
TURN over TCP. =A0Same upside.

True.

Then shouldn't server-reflexive candidates always be gathered using pla= in STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would b= e ignored (or even not sent) for TURN-over-anything-but-UDP.

That's what I was beginning to think as well... =A0= Is there any utility to be gained by advertising XOR-MAPPED-ADDRESS on tran= sport types that (at least it would so seem to me) preclude its usage?

Matthew Fredrickson
--001a11c233ea1f7fa404e6855d84-- From rmohanr@cisco.com Mon Sep 16 22:10:31 2013 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 A1C6411E81BF for ; Mon, 16 Sep 2013 22:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w-BMeAhY5m5 for ; Mon, 16 Sep 2013 22:10:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2E11E81DF for ; Mon, 16 Sep 2013 22:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3647; q=dns/txt; s=iport; t=1379394626; x=1380604226; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Ofsl8Tae2BfZdKLw1PTjeohi2DuBVlV1PfLH3LsHKZ8=; b=UJwbLFYDKOy6RLqV4CS6K090glvw/yuZoSL7tKxSEIqmXdlPXuGyqAEL XavDq5hsYLbvZzYboIfVLHg3irWWR6bwQ0eKkLd1EpePnX82i8dCVZNtS Zjce76/Qo3XtwOlqhWJVjybhDo9aWiTYlPp7ymx9z6dZeDvk0gIqHFupl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAEnjN1KtJXG8/2dsb2JhbABagwc4UsBBSoEhFnSCJQEBAQQBAQEJEVEXAgQBCBEDAQEBCw4PIgwLFAgBCAIEARIIE4doDLsCBASPMgYyBhKDBoEAA4kAoG+DJIIq X-IronPort-AV: E=Sophos;i="4.90,920,1371081600"; d="scan'208";a="260639406" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 17 Sep 2013 05:10:23 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8H5ANYx029265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 05:10:23 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.38]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 00:10:23 -0500 From: "Ram Mohan R (rmohanr)" To: "Lijing (Jessie, Huawei)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? Thread-Index: AQHOs2Q1yYNS07R65kCG9gwOaDmHyA== Date: Tue, 17 Sep 2013 05:10:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7CCD343A771C294EABFC4AB6A10DA180@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? 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, 17 Sep 2013 05:10:31 -0000 Hi Please see inline -----Original Message----- From: Jessie , "Huawei)" Date: Thursday, 12 September 2013 1:27 PM To: "rtcweb@ietf.org" Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? >Hi all, > >As a newcomer to RTCWEB, I have some doubts after I have read the draft. > >1. in "4. Solution Overview", may be it would be better to clarify when >to send a STUN Binding Request(in the middle of a media session or before >sending traffic, during sending traffic or only during silence periods) >and which side to send the request(controlling agent or both sides)? The introduction section explains when consent is needed. During the initial call setup ICE connectivity checks are used. This mechanism described in this document is for periodic consent after initial sessions is setup. > >2. in " 7. Security Considerations", there are the following words. As >when one agent receives STUN Binding Request, unlike the processing of >indication message, it have to do more processes to send the Response >message, I am not sure whether it is appreciate not to authenticate the >source and respond directly. Is it more open to malicious attacks? I am not clear on what you asking here. The below text just tells that there is no need to re-asserting the username/password that was sent initially during ICE checks. Are you saying this can lead to attacks ? If yes can you explain on what you meant in detail ? Ram > > "Once that connection to the remote > peer has been established with ICE, the consent to continue sending > traffic does not benefit from re-asserting that same username and > password, so long as the senders and receiver's IP addresses remain > the same (as they usually do)." > >Neglect my words, if my understandings are wrong. > >Best regards, > >Jessie > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Magnus Westerlund >Sent: Monday, September 09, 2013 4:37 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? > >WG, > >This is a call for WG adoption of STUN Usage for Consent Freshness >(draft-muthu-behave-consent-freshness-04). This document defines a STUN >usage for consent freshness. As this requires no protocol extensions we >as intended users can define this usage in our WG. Such work also >matches our charter. The draft-ietf-rtcweb-security-arch-07 is >normatively dependent on this STUN usage. > >Document: >https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > >WG, please indicate your support or issues with adopting this document >as WG item with a proposed milestone: > >Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication >as proposed standard. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >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 harald@alvestrand.no Tue Sep 17 01:34:19 2013 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 9F92011E83AD for ; Tue, 17 Sep 2013 01:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Ws1-O29Atz for ; Tue, 17 Sep 2013 01:34:15 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2F511E83AC for ; Tue, 17 Sep 2013 01:34:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D27CE39E3E4 for ; Tue, 17 Sep 2013 10:34:12 +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 05Fue+p2gsP4 for ; Tue, 17 Sep 2013 10:34:11 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2D59239E246 for ; Tue, 17 Sep 2013 10:34:11 +0200 (CEST) Message-ID: <52381402.8070400@alvestrand.no> Date: Tue, 17 Sep 2013 10:34:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 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: 8bit Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) 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, 17 Sep 2013 08:34:19 -0000 Changing subject line in order to make life easier for those who try to review comments on the original subject.... On 09/17/2013 07:10 AM, Ram Mohan R (rmohanr) wrote: > Hi Please see inline > > -----Original Message----- > From: Jessie , "Huawei)" > Date: Thursday, 12 September 2013 1:27 PM > To: "rtcweb@ietf.org" > Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? > >> Hi all, >> >> As a newcomer to RTCWEB, I have some doubts after I have read the draft. >> >> 1. in "4. Solution Overview", may be it would be better to clarify when >> to send a STUN Binding Request(in the middle of a media session or before >> sending traffic, during sending traffic or only during silence periods) >> and which side to send the request(controlling agent or both sides)? > The introduction section explains when consent is needed. During the > initial call setup ICE connectivity checks are used. This mechanism > described in this document is for periodic consent after initial sessions > is setup. > >> 2. in " 7. Security Considerations", there are the following words. As >> when one agent receives STUN Binding Request, unlike the processing of >> indication message, it have to do more processes to send the Response >> message, I am not sure whether it is appreciate not to authenticate the >> source and respond directly. Is it more open to malicious attacks? > I am not clear on what you asking here. The below text just tells that > there is no need to re-asserting the username/password that was sent > initially during ICE checks. Are you saying this can lead to attacks ? If > yes can you explain on what you meant in detail ? The text below is wrong. If, as is commonly the case, an attacker has the ability to inject packets on the wire with the same IP address as the victim, the attacker can forge ICE packets. If the victim's correspondent checks MESSAGE-INTEGRITY (which implicitly checks username and password), he will detect that these packets don't have the correct authorization, and throw them away. If the victim's correspondent does not check MESSAGE-INTEGRITY, the attacker can keep renewing any consent to receive as long as he wants, even though the victim wanted to stop consenting. Since the whole purpose of consent-freshness is to allow the potential victim to stop consenting to receiving traffic, checking MESSAGE-INTEGRITY (which implictily checks username and password) is necessary. This whole paragraph should be deleted from the "Security Considerations" section and replaced with text properly describing the situation. > > Ram > >> "Once that connection to the remote >> peer has been established with ICE, the consent to continue sending >> traffic does not benefit from re-asserting that same username and >> password, so long as the senders and receiver's IP addresses remain >> the same (as they usually do)." >> >> Neglect my words, if my understandings are wrong. >> >> Best regards, >> >> Jessie >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Magnus Westerlund >> Sent: Monday, September 09, 2013 4:37 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? >> >> WG, >> >> This is a call for WG adoption of STUN Usage for Consent Freshness >> (draft-muthu-behave-consent-freshness-04). This document defines a STUN >> usage for consent freshness. As this requires no protocol extensions we >> as intended users can define this usage in our WG. Such work also >> matches our charter. The draft-ietf-rtcweb-security-arch-07 is >> normatively dependent on this STUN usage. >> >> Document: >> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ >> >> WG, please indicate your support or issues with adopting this document >> as WG item with a proposed milestone: >> >> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication >> as proposed standard. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 magnus.westerlund@ericsson.com Tue Sep 17 01:37:43 2013 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 4BE0911E83A5 for ; Tue, 17 Sep 2013 01:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.636 X-Spam-Level: X-Spam-Status: No, score=-105.636 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRV-gbD2MiDj for ; Tue, 17 Sep 2013 01:37:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1429F11E83B8 for ; Tue, 17 Sep 2013 01:36:57 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-9a-523814a812fc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.56.03802.8A418325; Tue, 17 Sep 2013 10:36:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Tue, 17 Sep 2013 10:36:56 +0200 Message-ID: <523814EE.2080205@ericsson.com> Date: Tue, 17 Sep 2013 10:38:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <523006A3.4020907@ericsson.com> In-Reply-To: <523006A3.4020907@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvje4KEYsggwVrdC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtnZ1xkLPshXrDj5l7GB8Z9kFyMnh4SAicSvz+tYIWwxiQv3 1rN1MXJxCAkcZpS4/G81lLOcUeLS1T+MIFW8AtoSv9efZQaxWQRUJf5OmwJmswlYSNz80cgG YosKBEu0b//KBlEvKHFy5hMWEFtEQF3i8sML7CC2sECqxML9P8BmCgHNXLqxC+wKTgEdiXX/ 1rFAXCQpsW3RMbB6ZgEDiSOL5rBC2PISzVtnM8P0NjR1sE5gFJyFZN0sJC2zkLQsYGRexcie m5iZk15utIkRGIAHt/xW3cF455zIIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTDq/5P48rBO9GC1TNWn/lcCfrPet/MaqijyH1f6/NzLLkj57qpDnKLFopZZG03W3LP5 pm0p9t5hRw5XYMLcgHNmPySv/OGUvmX8StHteMw7E7N4hUuh63rUjYrEfuefvdXGOuGFxo8t KeImzf7vZ1zeVsSfNzXtDkck53IJt7l+fj8eFNgoz1JiKc5INNRiLipOBADQaZicDgIAAA== Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 17 Sep 2013 08:37:43 -0000 WG, I know that the new JSEP Draft is not yet submitted. I am hoping that it will show up during the morning hours for the US based people. That way everyone gets at least some few hours to look at the draft prior to the call. If it hasn't we will postpone the call, but I really hope we can avoid this. I will send a notice to the WG if we have to postpone it. Cheers Magnus On 2013-09-11 07:58, Magnus Westerlund wrote: > WG, > > There will be a new version of JSEP draft coming out Monday. As a follow > up to get as much progress on this topic as possible. The chairs and > authors are offering a informal walk through session on Wednesday the > 18th. People will be strongly recommended to have reviewed the new draft. > > The intention of the session is enable the authors to inform you about > the latest changes, any issues to consider and what needs further > discussion. The will also enable you as participant after your review of > the document to ask clarifying questions or for motivations behind > choices, and raise issues you have spotted. > > The session is not intended to solve issues or judge consensus on part > of the draft. Discussions of what is the best solution etc, will to be > cut off. > > This will be a webex conference per details below. > > Cheers > > Magnus Westerlund > > Topic: RTCWeb - JSEP > Date: Wednesday, September 18, 2013 > Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 302 061 238 > Meeting Password: ietf > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0 > > 2. Enter your name and email address. > 3. Enter the meeting password: ietf > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0 > > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > > ---------------------------------------------------------------- > ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE > (408) OR (919) AREA CODES > ---------------------------------------------------------------- > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > Dialing the WebEx toll free numbers from within 408 or 919 area codes is > not enabled (non-Cisco phones). “ If you dial the toll-free numbers > within the 408 or 919 area codes you will be instructed to hang up and > dial the local access number.” Please use the call-back option whenever > possible and otherwise dial local numbers only. The affected toll free > numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) > 349-3520 for the RTP area. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Sep 17 01:45:16 2013 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 A743E11E83B9 for ; Tue, 17 Sep 2013 01:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.674 X-Spam-Level: X-Spam-Status: No, score=-105.674 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M78npC8Z1ZfA for ; Tue, 17 Sep 2013 01:45:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEA511E83B0 for ; Tue, 17 Sep 2013 01:45:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-f9-52381693ab36 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 89.99.22048.39618325; Tue, 17 Sep 2013 10:45:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Tue, 17 Sep 2013 10:45:06 +0200 Message-ID: <523816DA.9090802@ericsson.com> Date: Tue, 17 Sep 2013 10:46:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <522D88A8.3010209@ericsson.com> In-Reply-To: <522D88A8.3010209@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje5kMYsgg+mr9SzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRm/LBuaCXUIVHYe/sjQw9vJ3MXJySAiYSDTP+8cEYYtJXLi3 nq2LkYtDSOAwo8T/Lw+ZIJzljBILr+5iBKniFdCWWHR5FVgHi4CqxO7171lAbDYBC4mbPxrZ QGxRgWCJ9u1f2SDqBSVOznwCViMiICrx+vE01i5GDg5hAReJ7mfMIGEhoJG3ZkxiB7E5BXQk Nkz4wQZxkKTEtkXHwOLMAnoSU662MELY8hLNW2fD9TY0dbBOYBSchWTbLCQts5C0LGBkXsXI npuYmZNebr6JERh+B7f8NtjBuOm+2CFGaQ4WJXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUwdvdcPyRcPWnefOdSnWnyQY1qJ06rPvIpdw2UXXWxudYucvH62BMya+5snmBxIuBa b+PTSWsizy59I8G2cpbg270HdqkKRu0/+ZYzO8qyOrP/ZlPfIQb3DyV6jpfb/BdNENS9F/d0 96MIuZtPnRmY/tw6sOz7/39tEZI3jz5Wsfmx8Lzl2x3KH5RYijMSDbWYi4oTAfIRfJoNAgAA Subject: Re: [rtcweb] Adopting draft-muthu-behave-consent-freshness? 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, 17 Sep 2013 08:45:16 -0000 WG, More than a week since this call was issued has passed. There has been strong support for adopting this WG item and the draft as a starting point. I will therefore request approval for the milestone from the AD. As pointed out there is clearly some issues in the draft that needs to be addressed. These will now be the WG concern. So please continue review and provide proposals for improving the document. Cheers Magnus Westerlund WG Chair On 2013-09-09 10:36, Magnus Westerlund wrote: > WG, > > This is a call for WG adoption of STUN Usage for Consent Freshness > (draft-muthu-behave-consent-freshness-04). This document defines a STUN > usage for consent freshness. As this requires no protocol extensions we > as intended users can define this usage in our WG. Such work also > matches our charter. The draft-ietf-rtcweb-security-arch-07 is > normatively dependent on this STUN usage. > > Document: > https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > > WG, please indicate your support or issues with adopting this document > as WG item with a proposed milestone: > > Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication > as proposed standard. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- 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 harald@alvestrand.no Tue Sep 17 01:47:58 2013 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 CAFE511E83B0 for ; Tue, 17 Sep 2013 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxZOjJxrThgy for ; Tue, 17 Sep 2013 01:47:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 889D711E83A7 for ; Tue, 17 Sep 2013 01:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1B2839E3E4; Tue, 17 Sep 2013 10:47: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 hCAp3snIDkq0; Tue, 17 Sep 2013 10:47:51 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9E4FC39E246; Tue, 17 Sep 2013 10:47:51 +0200 (CEST) Message-ID: <52381736.5000709@alvestrand.no> Date: Tue, 17 Sep 2013 10:47:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Magnus Westerlund References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> In-Reply-To: <523814EE.2080205@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 17 Sep 2013 08:47:59 -0000 Magnus, what is the expected duration of the call? On 09/17/2013 10:38 AM, Magnus Westerlund wrote: > WG, > > I know that the new JSEP Draft is not yet submitted. I am hoping that it > will show up during the morning hours for the US based people. That way > everyone gets at least some few hours to look at the draft prior to the > call. If it hasn't we will postpone the call, but I really hope we can > avoid this. I will send a notice to the WG if we have to postpone it. > > Cheers > > Magnus > > On 2013-09-11 07:58, Magnus Westerlund wrote: >> WG, >> >> There will be a new version of JSEP draft coming out Monday. As a follow >> up to get as much progress on this topic as possible. The chairs and >> authors are offering a informal walk through session on Wednesday the >> 18th. People will be strongly recommended to have reviewed the new draft. >> >> The intention of the session is enable the authors to inform you about >> the latest changes, any issues to consider and what needs further >> discussion. The will also enable you as participant after your review of >> the document to ask clarifying questions or for motivations behind >> choices, and raise issues you have spotted. >> >> The session is not intended to solve issues or judge consensus on part >> of the draft. Discussions of what is the best solution etc, will to be >> cut off. >> >> This will be a webex conference per details below. >> >> Cheers >> >> Magnus Westerlund >> >> Topic: RTCWeb - JSEP >> Date: Wednesday, September 18, 2013 >> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >> Meeting Number: 302 061 238 >> Meeting Password: ietf >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0 >> >> 2. Enter your name and email address. >> 3. Enter the meeting password: ietf >> 4. Click "Join Now". >> >> To view in other time zones or languages, please click the link: >> https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0 >> >> >> ------------------------------------------------------- >> To join the teleconference only >> ------------------------------------------------------- >> 1. Dial into Cisco WebEx (view all Global Access Numbers at >> http://cisco.com/en/US/about/doing_business/conferencing/index.html >> 2. Follow the prompts to enter the Meeting Number (listed above) or >> Access Code followed by the # sign. >> >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >> >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >> >> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >> >> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >> >> >> ---------------------------------------------------------------- >> ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE >> (408) OR (919) AREA CODES >> ---------------------------------------------------------------- >> Please dial the local access number for your area from the list below: >> - San Jose/Milpitas (408) area: 525-6800 >> - RTP (919) area: 392-3330 >> >> Dialing the WebEx toll free numbers from within 408 or 919 area codes is >> not enabled (non-Cisco phones). “ If you dial the toll-free numbers >> within the 408 or 919 area codes you will be instructed to hang up and >> dial the local access number.” Please use the call-back option whenever >> possible and otherwise dial local numbers only. The affected toll free >> numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) >> 349-3520 for the RTP area. >> > From magnus.westerlund@ericsson.com Tue Sep 17 01:50:05 2013 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 4C0A411E83AE for ; Tue, 17 Sep 2013 01:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.883 X-Spam-Level: X-Spam-Status: No, score=-103.883 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzGnliXAqLjJ for ; Tue, 17 Sep 2013 01:50:00 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E9FFA11E83AA for ; Tue, 17 Sep 2013 01:49:59 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-de-523817b5c7eb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E1.D3.25272.5B718325; Tue, 17 Sep 2013 10:49:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Tue, 17 Sep 2013 10:49:57 +0200 Message-ID: <523817FC.80406@ericsson.com> Date: Tue, 17 Sep 2013 10:51:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Harald Alvestrand References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> In-Reply-To: <52381736.5000709@alvestrand.no> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvje42cYsggwtfuCyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGV8aV/JUvBDqWL1/PfMDYwXZboYOTkkBEwk bs6dwgJhi0lcuLeerYuRi0NI4CijxKwFR5kgnGWMEq3P/7GDVPEKaEqs+9wB1sEioCqx5uIq sDibgIXEzR+NbCC2qECwRPv2r2wQ9YISJ2c+AasXEdCReLi/gQnEZhZQl7iz+BxYr7BAqsTC /T8YQWwhgRyJ8w3rWUFsTgFdiZbG62wQ10lKbFt0jB2i10DiyKI5rBC2vETz1tnMEL3aEg1N HawTGIVmIVk9C0nLLCQtCxiZVzFyFKcWJ+WmGxlsYgSG68Etvy12MF7+a3OIUZqDRUmcd4ve mUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPfsuj9ucT8bZ24avnyrqJYXy4pLLbF/+u0K 9itcn1zL7/OsMsjj/KrXnksmv5v7qcfkcc2v728nshf/nVQbeTxDwLjpxaSwbdvaf9cecbur sPhKucKjQ21nzv/+n5T90pjxzKeJiz98K5DmUbt45tdFzk1L2iwag7OexL66w8jXbi668tfn 9bVKLMUZiYZazEXFiQAAV72wJQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 17 Sep 2013 08:50:05 -0000 On 2013-09-17 10:47, Harald Alvestrand wrote: > Magnus, > > what is the expected duration of the call? 2 hour maximum Magnus > > On 09/17/2013 10:38 AM, Magnus Westerlund wrote: >> WG, >> >> I know that the new JSEP Draft is not yet submitted. I am hoping that it >> will show up during the morning hours for the US based people. That way >> everyone gets at least some few hours to look at the draft prior to the >> call. If it hasn't we will postpone the call, but I really hope we can >> avoid this. I will send a notice to the WG if we have to postpone it. >> >> Cheers >> >> Magnus >> >> On 2013-09-11 07:58, Magnus Westerlund wrote: >>> WG, >>> >>> There will be a new version of JSEP draft coming out Monday. As a follow >>> up to get as much progress on this topic as possible. The chairs and >>> authors are offering a informal walk through session on Wednesday the >>> 18th. People will be strongly recommended to have reviewed the new >>> draft. >>> >>> The intention of the session is enable the authors to inform you about >>> the latest changes, any issues to consider and what needs further >>> discussion. The will also enable you as participant after your review of >>> the document to ask clarifying questions or for motivations behind >>> choices, and raise issues you have spotted. >>> >>> The session is not intended to solve issues or judge consensus on part >>> of the draft. Discussions of what is the best solution etc, will to be >>> cut off. >>> >>> This will be a webex conference per details below. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> Topic: RTCWeb - JSEP >>> Date: Wednesday, September 18, 2013 >>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >>> Meeting Number: 302 061 238 >>> Meeting Password: ietf >>> >>> ------------------------------------------------------- >>> To join the online meeting (Now from mobile devices!) >>> ------------------------------------------------------- >>> 1. Go to >>> https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0 >>> >>> >>> 2. Enter your name and email address. >>> 3. Enter the meeting password: ietf >>> 4. Click "Join Now". >>> >>> To view in other time zones or languages, please click the link: >>> https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0 >>> >>> >>> >>> ------------------------------------------------------- >>> To join the teleconference only >>> ------------------------------------------------------- >>> 1. Dial into Cisco WebEx (view all Global Access Numbers at >>> http://cisco.com/en/US/about/doing_business/conferencing/index.html >>> 2. Follow the prompts to enter the Meeting Number (listed above) or >>> Access Code followed by the # sign. >>> >>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >>> >>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >>> >>> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >>> >>> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >>> >>> >>> ---------------------------------------------------------------- >>> ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE >>> (408) OR (919) AREA CODES >>> ---------------------------------------------------------------- >>> Please dial the local access number for your area from the list below: >>> - San Jose/Milpitas (408) area: 525-6800 >>> - RTP (919) area: 392-3330 >>> >>> Dialing the WebEx toll free numbers from within 408 or 919 area codes is >>> not enabled (non-Cisco phones). “ If you dial the toll-free numbers >>> within the 408 or 919 area codes you will be instructed to hang up and >>> dial the local access number.” Please use the call-back option whenever >>> possible and otherwise dial local numbers only. The affected toll free >>> numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) >>> 349-3520 for the RTP area. >>> >> > > > -- 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 ietf-secretariat-reply@ietf.org Tue Sep 17 01:49:07 2013 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 77BE111E83AE for ; Tue, 17 Sep 2013 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+do4nM0Am0o for ; Tue, 17 Sep 2013 01:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D53CE11E83B0 for ; Tue, 17 Sep 2013 01:49:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917084906.27981.10545.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 01:49:06 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 17 Sep 2013 02:43:28 -0700 Subject: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 08:49:07 -0000 Changed milestone "Send Use Cases document (draft-ietf-rtcweb-use-cases-and- requirements) to IESG for publication as Informational", added draft-ietf-rtcweb-use-cases-and-requirements to milestone. Changed milestone "Complete Overview (and hold for dependency resolution) (draft-ietf-rtcweb-overview)", added draft-ietf-rtcweb-overview to milestone. Changed milestone "Send Security and Privacy Problem Statement (draft-ietf- rtcweb-security) to IESG for publication as Informational", added draft-ietf-rtcweb-security to milestone. Changed milestone "Send Signalling Negotiation and NAT Traversal (draft-ietf- rtcweb-jsep) to IESG for publication as Proposed Standard", added draft-ietf-rtcweb-jsep to milestone. Changed milestone "Send Security Solution (draft-ietf-rtcweb-security-arch) to IESG for publication as Proposed Standard", added draft-ietf-rtcweb-security-arch to milestone. Changed milestone "Send Media Transport (draft-ietf-rtcweb-rtp-usage) to IESG for publication as Proposed Standard", added draft-ietf-rtcweb-rtp-usage to milestone. Changed milestone "Audio Processing and Audio Codecs (draft-ietf-rtcweb-audio) to IESG for publication as Proposed Standard", added draft-ietf-rtcweb-audio to milestone. Changed milestone "Send Data Stream Transport for non-media data (draft-ietf- rtcweb-data-channel) to IESG for publication as Proposed Standard", added draft-ietf-rtcweb-data-channel, draft-ietf-rtcweb-data-protocol to milestone. URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From magnus.westerlund@ericsson.com Tue Sep 17 02:45:51 2013 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 7FC8511E83D7 for ; Tue, 17 Sep 2013 02:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.637 X-Spam-Level: X-Spam-Status: No, score=-105.637 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17xncYsJ9X1y for ; Tue, 17 Sep 2013 02:45:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7328F11E83CF for ; Tue, 17 Sep 2013 02:45:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-34-523824c8829e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.F0.16099.8C428325; Tue, 17 Sep 2013 11:45:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Tue, 17 Sep 2013 11:45:44 +0200 Message-ID: <5238250F.90606@ericsson.com> Date: Tue, 17 Sep 2013 11:46:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20130917084906.27981.10545.idtracker@ietfa.amsl.com> In-Reply-To: <20130917084906.27981.10545.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvje4JFYsgg1+t4hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+W504wFS0UqZv0Mb2CcKNjFyMkhIWAicbttCTOELSZx4d56 ti5GLg4hgcOMEv+2nWeHcJYxSrzY1svYxcjBwSugKbF1gSyIySKgKvF7TyJIL5uAhcTNH41s ILaoQLBE+/avYDavgKDEyZlPWEBsEQFRidePp7GC2MICZhKrnz8FqxEScJR4feQ/C8hITgEn ie8NXBDnSEpsW3SMHcRmFtCTmHK1hRHClpdo3jqbGaJVW6KhqYN1AqPgLCTbZiFpmYWkZQEj 8ypG9tzEzJz0csNNjMDAO7jlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qB0ay0e8eFYxxZvxbqGy/fF/WuyNNB2VLlz8v3t+7qvz/xr8Q5Mr9exWivtHtc xSXfIoXqlwqFH75Mm1gk5uny8JzKhZ1it21i68JD7xZNM1/FPPHD/PpVv48/51x+MnWakNgU nT0ZO4v+am/82c1eG6Y2acn0A/0c05syDefHGL258PTGsmPtvEosxRmJhlrMRcWJAL62I2gK AgAA Subject: Re: [rtcweb] Milestones changed for rtcweb WG 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, 17 Sep 2013 09:45:51 -0000 WG, These changes are the just adding the drafts to their corresponding milestones using the data tracker tool. That way you get clickable links to the drafts. An additional message will show up when our AD approves the milestone for consent freshness that I have requested. Cheers Magnus On 2013-09-17 10:49, IETF Secretariat wrote: > Changed milestone "Send Use Cases document > (draft-ietf-rtcweb-use-cases-and- requirements) to IESG for > publication as Informational", added > draft-ietf-rtcweb-use-cases-and-requirements to milestone. > > Changed milestone "Complete Overview (and hold for dependency > resolution) (draft-ietf-rtcweb-overview)", added > draft-ietf-rtcweb-overview to milestone. > > Changed milestone "Send Security and Privacy Problem Statement > (draft-ietf- rtcweb-security) to IESG for publication as > Informational", added draft-ietf-rtcweb-security to milestone. > > Changed milestone "Send Signalling Negotiation and NAT Traversal > (draft-ietf- rtcweb-jsep) to IESG for publication as Proposed > Standard", added draft-ietf-rtcweb-jsep to milestone. > > Changed milestone "Send Security Solution > (draft-ietf-rtcweb-security-arch) to IESG for publication as Proposed > Standard", added draft-ietf-rtcweb-security-arch to milestone. > > Changed milestone "Send Media Transport (draft-ietf-rtcweb-rtp-usage) > to IESG for publication as Proposed Standard", added > draft-ietf-rtcweb-rtp-usage to milestone. > > Changed milestone "Audio Processing and Audio Codecs > (draft-ietf-rtcweb-audio) to IESG for publication as Proposed > Standard", added draft-ietf-rtcweb-audio to milestone. > > Changed milestone "Send Data Stream Transport for non-media data > (draft-ietf- rtcweb-data-channel) to IESG for publication as Proposed > Standard", added draft-ietf-rtcweb-data-channel, > draft-ietf-rtcweb-data-protocol to milestone. > > URL: http://datatracker.ietf.org/wg/rtcweb/charter/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- 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 tireddy@cisco.com Tue Sep 17 03:05:31 2013 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 44B8C11E83CF for ; Tue, 17 Sep 2013 03:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41d6fhwzDhIw for ; Tue, 17 Sep 2013 03:05:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5011E80D1 for ; Tue, 17 Sep 2013 03:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6369; q=dns/txt; s=iport; t=1379412326; x=1380621926; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WCS/7/evX4GHIl+qTloUICW1VMKkv3S/NszgY80wXK4=; b=J7fls4Yco1/XshQb1PLhB5BX2DzYcgWWe1EV6JqO8yInrD0H3RY/KwDr Bj5TqnzmCRDA+EtbyUMYIPBjpqOJ4SeEMgchRs5PeMknmWGv5olEhNigr YweXH7V5/bJcVFCvGPOhiix/bwnmvCDCAZ1OmeAGn5dOuZxAEOgI84Ndr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAKkoOFKtJV2c/2dsb2JhbABbgwc4UsBMSoEcFnSCJQEBAQMBAQEBCRFRFwICAgEIEQMBAQEBCg4LBAcbDAsUCAEIAgQBEggRAodiBgy6ZwQEjzIGMgYSgwaBAAOJAIsflVCBZoE+gWokHA X-IronPort-AV: E=Sophos;i="4.90,922,1371081600"; d="scan'208";a="260547705" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Sep 2013 10:05:25 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8HA5Pra008990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 10:05:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 05:05:25 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) Thread-Index: AQHOs4C/clq2b3F4c0Cq3gToydiwV5nJqo4A Date: Tue, 17 Sep 2013 10:05:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com> References: <52381402.8070400@alvestrand.no> In-Reply-To: <52381402.8070400@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) 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, 17 Sep 2013 10:05:31 -0000 Hi Harald, Please see inline > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Harald Alvestrand > Sent: Tuesday, September 17, 2013 2:04 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adoptin= g > draft-muthu-behave-consent-freshness?) >=20 > Changing subject line in order to make life easier for those who try to > review comments on the original subject.... >=20 > On 09/17/2013 07:10 AM, Ram Mohan R (rmohanr) wrote: > > Hi Please see inline > > > > -----Original Message----- > > From: Jessie , "Huawei)" > > Date: Thursday, 12 September 2013 1:27 PM > > To: "rtcweb@ietf.org" > > Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? > > > >> Hi all, > >> > >> As a newcomer to RTCWEB, I have some doubts after I have read the draf= t. > >> > >> 1. in "4. Solution Overview", may be it would be better to clarify wh= en > >> to send a STUN Binding Request(in the middle of a media session or bef= ore > >> sending traffic, during sending traffic or only during silence periods= ) > >> and which side to send the request(controlling agent or both sides)? > > The introduction section explains when consent is needed. During the > > initial call setup ICE connectivity checks are used. This mechanism > > described in this document is for periodic consent after initial sessio= ns > > is setup. > > > >> 2. in " 7. Security Considerations", there are the following words. A= s > >> when one agent receives STUN Binding Request, unlike the processing of > >> indication message, it have to do more processes to send the Response > >> message, I am not sure whether it is appreciate not to authenticate th= e > >> source and respond directly. Is it more open to malicious attacks? > > I am not clear on what you asking here. The below text just tells that > > there is no need to re-asserting the username/password that was sent > > initially during ICE checks. Are you saying this can lead to attacks ? = If > > yes can you explain on what you meant in detail ? >=20 > The text below is wrong. >=20 > If, as is commonly the case, an attacker has the ability to inject > packets on the wire with the same IP address as the victim, the attacker > can forge ICE packets. >=20 > If the victim's correspondent checks MESSAGE-INTEGRITY (which implicitly > checks username and password), he will detect that these packets don't > have the correct authorization, and throw them away. >=20 > If the victim's correspondent does not check MESSAGE-INTEGRITY, the > attacker can keep renewing any consent to receive as long as he wants, > even though the victim wanted to stop consenting. Since each endpoint contributes at least 24 bits of randomness to the ice-u= frag which provides 48 bits of randomness. It would not be possible for off= -path attacker to guess those 48 bits to cause the endpoint to perform HMAC= -SHA1 validation of the MESSAGE-INTEGRITY attribute. Hence my understanding= is for consent freshness checking MESSAGE-INTEGRITY is not be required, on= ly checking IP address and USERNAME attribute looks sufficient to handle of= f-path attacks. -Tiru. >=20 > Since the whole purpose of consent-freshness is to allow the potential > victim to stop consenting to receiving traffic, checking > MESSAGE-INTEGRITY (which implictily checks username and password) is > necessary. >=20 > This whole paragraph should be deleted from the "Security > Considerations" section and replaced with text properly describing the > situation. >=20 > > > > Ram > > > >> "Once that connection to the remote > >> peer has been established with ICE, the consent to continue sending > >> traffic does not benefit from re-asserting that same username and > >> password, so long as the senders and receiver's IP addresses remain > >> the same (as they usually do)." > >> > >> Neglect my words, if my understandings are wrong. > >> > >> Best regards, > >> > >> Jessie > >> > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beha= lf > >> Of Magnus Westerlund > >> Sent: Monday, September 09, 2013 4:37 PM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? > >> > >> WG, > >> > >> This is a call for WG adoption of STUN Usage for Consent Freshness > >> (draft-muthu-behave-consent-freshness-04). This document defines a STU= N > >> usage for consent freshness. As this requires no protocol extensions w= e > >> as intended users can define this usage in our WG. Such work also > >> matches our charter. The draft-ietf-rtcweb-security-arch-07 is > >> normatively dependent on this STUN usage. > >> > >> Document: > >> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ > >> > >> WG, please indicate your support or issues with adopting this document > >> as WG item with a proposed milestone: > >> > >> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication > >> as proposed standard. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> > >> _______________________________________________ > >> 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 michelg@upperside.fr Tue Sep 17 04:31:00 2013 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 CDD7C11E83F6 for ; Tue, 17 Sep 2013 04:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSu0dSgchMqY for ; Tue, 17 Sep 2013 04:30:54 -0700 (PDT) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3146111E83FF for ; Tue, 17 Sep 2013 04:30:05 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id r8HBU2Pd012120 for ; Tue, 17 Sep 2013 13:30:02 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 17 Sep 2013 13:30:05 +0200 Message-ID: <006301ceb399$423179f0$c6946dd0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CEB3AA.05BBA980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6zhnfVBRWvODE2Ty2eCrzfvtDyog== Content-Language: fr X-Backend: sophos44 X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.17.111215 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [rtcweb] WebRTC Paris 2013: The first real-world deployments 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, 17 Sep 2013 11:31:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01CEB3AA.05BBA980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The second edition of the WebRTC conference will be held in Paris Roissy CDG, from 10 to 12 December, 2013: Sessions include telco and enterprise testimonies, standardization updates, performance, QoS & codecs issues. A large part of the second day is dedicated to implementations. A panel will focus on Browser/HTML5 vs. Native applications and support for WebRTC on mobile devices and chipsets. A startup speed dating session will include descriptions from start-ups and from new initiatives at larger companies. Each will have a few minutes to present the company and key benefits. Application for this session is still open. Organizers will select finalists to present on stage. More info: http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html ------=_NextPart_000_0064_01CEB3AA.05BBA980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= The second edition of the WebRTC conference will be held in Paris Roissy = CDG, from 10 to 12 December, 2013:

= Sessions include telco and enterprise testimonies, standardization = updates, performance, QoS & codecs issues. A large part of the = second day is dedicated to implementations.

= A panel = will focus on Browser/HTML5 vs. Native applications and support for = WebRTC on mobile devices and chipsets.

A startup = speed dating session will include descriptions from start-ups and from = new initiatives at larger companies. Each will have a few minutes to = present the company and key benefits.

Application = for this session is still open. Organizers will select finalists to = present on stage.

More info: = http://www.uppersideconferences.com/webrtc2013/webrtc2013int= ro.html

------=_NextPart_000_0064_01CEB3AA.05BBA980-- From harald@alvestrand.no Tue Sep 17 04:33:56 2013 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 A741911E81A4 for ; Tue, 17 Sep 2013 04:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.256 X-Spam-Level: X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBUJVVHpUjU7 for ; Tue, 17 Sep 2013 04:33:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4165111E8100 for ; Tue, 17 Sep 2013 04:33:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DD9539E4EB; Tue, 17 Sep 2013 13:33:50 +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 VcE6g31F5zQA; Tue, 17 Sep 2013 13:33:46 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0BCD339E240; Tue, 17 Sep 2013 13:33:46 +0200 (CEST) Message-ID: <52383E19.2070107@alvestrand.no> Date: Tue, 17 Sep 2013 13:33:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <52381402.8070400@alvestrand.no> <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) 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, 17 Sep 2013 11:33:56 -0000 On 09/17/2013 12:05 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Harald, > > Please see inline > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of >> Harald Alvestrand >> Sent: Tuesday, September 17, 2013 2:04 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adopting >> draft-muthu-behave-consent-freshness?) >> >> Changing subject line in order to make life easier for those who try to >> review comments on the original subject.... >> >> On 09/17/2013 07:10 AM, Ram Mohan R (rmohanr) wrote: >>> Hi Please see inline >>> >>> -----Original Message----- >>> From: Jessie , "Huawei)" >>> Date: Thursday, 12 September 2013 1:27 PM >>> To: "rtcweb@ietf.org" >>> Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? >>> >>>> Hi all, >>>> >>>> As a newcomer to RTCWEB, I have some doubts after I have read the draft. >>>> >>>> 1. in "4. Solution Overview", may be it would be better to clarify when >>>> to send a STUN Binding Request(in the middle of a media session or before >>>> sending traffic, during sending traffic or only during silence periods) >>>> and which side to send the request(controlling agent or both sides)? >>> The introduction section explains when consent is needed. During the >>> initial call setup ICE connectivity checks are used. This mechanism >>> described in this document is for periodic consent after initial sessions >>> is setup. >>> >>>> 2. in " 7. Security Considerations", there are the following words. As >>>> when one agent receives STUN Binding Request, unlike the processing of >>>> indication message, it have to do more processes to send the Response >>>> message, I am not sure whether it is appreciate not to authenticate the >>>> source and respond directly. Is it more open to malicious attacks? >>> I am not clear on what you asking here. The below text just tells that >>> there is no need to re-asserting the username/password that was sent >>> initially during ICE checks. Are you saying this can lead to attacks ? If >>> yes can you explain on what you meant in detail ? >> The text below is wrong. >> >> If, as is commonly the case, an attacker has the ability to inject >> packets on the wire with the same IP address as the victim, the attacker >> can forge ICE packets. >> >> If the victim's correspondent checks MESSAGE-INTEGRITY (which implicitly >> checks username and password), he will detect that these packets don't >> have the correct authorization, and throw them away. >> >> If the victim's correspondent does not check MESSAGE-INTEGRITY, the >> attacker can keep renewing any consent to receive as long as he wants, >> even though the victim wanted to stop consenting. > Since each endpoint contributes at least 24 bits of randomness to the ice-ufrag which provides 48 bits of randomness. It would not be possible for off-path attacker to guess those 48 bits to cause the endpoint to perform HMAC-SHA1 validation of the MESSAGE-INTEGRITY attribute. Hence my understanding is for consent freshness checking MESSAGE-INTEGRITY is not be required, only checking IP address and USERNAME attribute looks sufficient to handle off-path attacks. > Are we talking past each other? In order to perform HMAC-SHA1 validation of the MESSAGE-INTEGRITY attribute, the HMAC-SHA1 function takes two inputs: The key and the message. From RFC 5389 section 15.4: For long-term credentials, the key is 16 bytes: key = MD5(username ":" realm ":" SASLprep(password)) For short-term credentials: key = SASLprep(password) In other words: A successful HMAC that produces a match with the MESSAGE-INTEGRITY attribute value means that the producer of the MESSAGE-INTEGRITY attribute knows the password, and, if long term credentials are used, he knows the username. This implicitly reasserts the password (and possibly the username), and the words we're discussing: "Once that connection to the remote peer has been established with ICE, the consent to continue sending traffic does not benefit from re-asserting that same username and password, so long as the senders and receiver's IP addresses remain the same (as they usually do)." don't make any sense to me. If they don't make any sense to other people, they do not belong in the document. From magnus.westerlund@ericsson.com Tue Sep 17 04:59:46 2013 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 C687111E80FD for ; Tue, 17 Sep 2013 04:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.369 X-Spam-Level: X-Spam-Status: No, score=-104.369 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeFQqOjz-MCA for ; Tue, 17 Sep 2013 04:59:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5EA11E8234 for ; Tue, 17 Sep 2013 04:59:36 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-d1-523844263c6f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C8.01.03802.62448325; Tue, 17 Sep 2013 13:59:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Tue, 17 Sep 2013 13:59:34 +0200 Message-ID: <5238446D.8050700@ericsson.com> Date: Tue, 17 Sep 2013 14:00:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3RlfdxSLIYPsBFovNNycxWnRMZrNY +6+d3YHZY8rvjaweS5b8ZPL4cvkzWwBzFJdNSmpOZllqkb5dAlfG6b60gs1xFY8mTmJvYJzo 2cXIySEhYCIx9W4LC4QtJnHh3nq2LkYuDiGBw4wSXTOuM0M4yxklTu+/yApSxSugLfF5ymEm EJtFQFXi762pYDabgIXEzR+NbCC2qECwRPv2r2wQ9YISJ2c+AdsgInCTUeLnSvkuRg4OYQFf iW1LVUDCQgI+Eod+zwUr5wQJ/5nEDHGQpMS2RcfYQWxmAQOJI4vmsELY8hLNW2czQ/RqSzQ0 dbBOYBSchWTbLCQts5C0LGBkXsXInpuYmZNebrSJERiiB7f8Vt3BeOecyCFGaQ4WJXHezXpn AoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwCtcaOMt/PV+t9v3p17bG3kmCj2dJeCywafVp WPGdzdzZ0JWjwfi9y7lZG/XynGxE78zOvX5a4J6mc8an+/GZasklbhMSRU4+X6ai7bfwUrl9 +ew5RizFZpvfVPvdvCby4kidBfeeU2euLdjTfVQr+2GURJ/Rky1py95c4OxLeL37GpPXpE47 JZbijERDLeai4kQADqxulx8CAAA= Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 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, 17 Sep 2013 11:59:46 -0000 Hi, I have reviewed the Use Case and Requirements draft (v11) in the WG last call. I have the following comments on this document. I have found a number of issues that I definitely needs to be fixed prior to any publication request. 1. First of all I like to bring up a document structure problem. When reviewing this it is difficult to follow what requirements that are added for the different use cases. I would propose that each Use Case or general section that describe something that causes new requirements that hasn't been listed yet in the document to define the Requirement there. Something like this: 3.2.2.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.2.1). The difference is that one of the users is behind a NAT that blocks UDP traffic. 3.2.2.2. Derived Requirements F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 New Requirement: F29 The browser must be able to send streams and data to a peer in the presence of NATs that block UDP traffic. This makes the incremental use cases much more understandable in how they add requirements. This I think will also affect Section 3.1 which will need to include the requirement definitions created by these general considerations. However, I do suggest that you leave the collection of all requirements in place for easy reference. 2. Section 1: The document focuses on requirements related to real-time media streams and data exchange. Requirements related to privacy, signalling between the browser and web server etc. are currently not considered. I think this needs to be rewritten. The draft actually do consider a number of high level security and privacy concerns. 3. Section 2: If you have no definitions, do remove the section, rather then leaving it TBD. 4. Section 3.1 o Clients can be on wideband (10s of Mbits/sec) o Clients can be on narrowband (10s to 100s of Kbits/sec) Due to the usage of the terms wideband and narrowband I think you need to be more explicit about what is actually referred to here. My assumption is network throughput capability. And in these cases maybe expressing this explicitly is a better choice. 5. Section 3.1: o Clients can be on networks with any type (as described in RFC4787) of NAT. I think "any type" is unclear here, as there are no types defined in that RFC unless you are trying to express the difference between basic NAT and NAPT, which I don't believe you are. I think you should use something like this: o Clients can be on networks with a NAT using any type of Mapping and Filtering behaviors (as described in RFC4787). 6. Section 3.2.1.1: It is essential that the communication cannot be wiretapped [RFC2804]. This sentence returns a number of times in this document. I think it is a general security requirement that applies to probably all of the use cases. If there is one use case that don't need to enable protection against this, then please be explicit about that. My Suggestion is to move this into the general considerations section. 7. Section 3.2.1.1: In addition, it is required that browsers enable the media and data security keys to be cryptographically bound to the user identity. I think this sentence is actually subtly wrong in a couple of ways. First of all it talks about "the identity", where I think it should be talking about "a identity". This can both the human users identity, but also a role identity, like Police Officer. Secondly, binding it to the security keys without putting requirements on the keying and key-exchange mechanism to prevent man in the middles empties this requirement. I would recommend that you reformulate this to a high level requirement without going into mechanism. For example: In addition, it is required that browsers enables binding an identity of the user's choice to his end of the secured communication and that such mechanism prevent man in the middle attacks. 8. Section 3.2.1.1 One user has an unreliable Internet connection. It sometimes loses packets, and sometimes goes down completely. I guess the requirement here is to handle this in a graceful way from media transport and rendering perspective. The packet loss is also unclear as I don't know if the intention is to capture spurious packet losses due to the link media, or congestion losses. I think some expansion of this is needed. 9. Section 3.2.1.1: One user is located behind a Network Address Translator (NAT). What is the point being stressed here that isn't covered by the general consideration in 3.1 that says: o Clients can be on networks with any type (as described in RFC4787) of NAT. Section 3.2.2.2: 3.2.2.2. Derived Requirements F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F29 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 How come this list of Derived Requirements are shorter than for the parent use case which has the following list: 3.2.1.2. Derived Requirements F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 If each use case is listing all the requirement then it needs to be consistently done and actually list all that applies. If there are requirements from the parent that doesn't apply that may even be worth explicitly mentioning. This comments applies to all use cases as there appears to be general inconsistencies. 10. Section 3.2.3.1: 3.2.3.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.2.1). The difference is that one of the users is behind a FW that only allows http traffic. If a firewall only allows HTTP traffic, then can we really assume that the firewall administrator per default will accept WebRTC Media and Data traffic? I am far from certain of this, and think on a requirement level needs to express a situation where the firewall administrator allows WebRTC across its FW, or at least can easily configure a rule to block it. Thus resulting in that any solution for this needs to be easily identifiable and possible to block. See also PNTAW@ietf.org mailing list. 11. Section 3.2.8.1: But in addition to this, one of the users can share what is being displayed on her/his screen with a peer. The user can choose to share the entire screen, part of the screen (part selected by the user) or what a selected applicaton displays with the peer. Does this needs mentioning of additional high level security requirements? 12. Section 3.2.10.1: The service providers are interconnected by some means, but exchange no more information about the users than what can be carried using SIP. NOTE: More profiling of what this means may be needed. The Note, can it be removed, or do we need additional text in this document? 13. Section 3.2.10.1: The same issues with connectivity apply. I don't understand this comment. What is it intended to refer to? 14. Section 3.2.11.1: Before the game starts, and during game breaks, the talent scout and the manager have a 1-1 audiovisual communication session. Only the rear facing camera of the mobile phone is used. On the display of the mobile phone, the video of the club manager is shown with a picture-in-picture thumbnail of the rear facing camera (self-view). On the display of the desktop, the video of the talent scout is shown with a picture-in-picture thumbnail of the desktop camera (self- view). I get a bit confused with what is the front and rear of my smart phone. I would consider the display side the front side, and the rear the other big side of my block shaped mobile phone. I suggest using other terms. 15. Section 3.2.14.1: Discussion: This use-case was briefly discussed at the Quebec webrtc meeting and it got support. So far the only concrete requirement (A17) derived is that the application must be able to ask the browser to treat the audio signal as audio (in contrast to speech). However, the use case should be further analysed to determine other requirements (could be e.g. on delay mic->speaker, level control of audio signals, etc.). I think this Discussion points needs to be dealt with before we can publish this document. I would consider the question if this needs more analysis a open issue. 16. Section 3.3.2.1: Alice uses her web browser with a service that allows her to call PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to hear the initial prompts from the fedex IVR and when the IVR says press 1, there should be a way for Alice to navigate the IVR. Can you please expand IVR. 17. Section 3.3.3.1: The organization has an internal network set up with an aggressive firewall handling access to the Internet. If users cannot physically access the internal network, they can establish a Virtual Private Network (VPN). I think the requirements or limitations the above paragraph try to express is not clear. There is some missing assumptions of location of server related to clients that is not covered. Thus it is not clear what requirements this results in. Can you please expand this to something that is understandable. 18. Section 3.3.3.1: This use-case adds requirements on support for fast stream switches F7, on encryption of media and on ability to traverse very restrictive FWs. Regarding the restricted FWs, my comment 10) applies to also this comment. 19. Section 4.2: F14 The browser must be able to measure the level F15 The browser must be able to change the level in audio streams. Can you please make explicit what type level you think should be measured or changed, energy, "voice activity"? 20. Section 4.2 F19 Streams and data must be able to pass through limited middleboxes. What type of limitations are you considering in this requirement? 21. Section 4.2 I note that F30, and F36 may be affected by earlier comments on the underlying reason for these requirements and need additional text or clarifications. 22. Section 4.2: F37 The browser must be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. I think this requirement should have a caveat along the lines: when FW policy allos WebRTC traffic. 23. Section 5: Change the TBD to a statement that there are no IANA actions in this document. 24. Section 6.2: These security considerations are really security requirements on the browser or the API. I don't know if would be better to move them to relevant use case sections, or leave them in place. 25. Section 7: 13. Enable company coop without being able to decipher http:// www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html What is "coop" in the above? 26. Please run a spell checker on the document prior to submitting the update. 27. Ensure that the ID nits issues are not real issues: == Line 667 has weird spacing: '...resence of NA...' == Line 785 has weird spacing: '...of that strea...' Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tireddy@cisco.com Tue Sep 17 10:40:37 2013 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 A1C9B11E8533 for ; Tue, 17 Sep 2013 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-VOdErUAUVa for ; Tue, 17 Sep 2013 10:40:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7B11E82B7 for ; Tue, 17 Sep 2013 10:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5248; q=dns/txt; s=iport; t=1379439631; x=1380649231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dRJppFvTgcWjIE0Wx/1d9jagGPV1nUhW+ANk/2HA5n4=; b=T7h9xzxCm/w9a7t3gC/Hr3LeXyubqN2P+9uZzFtRBKVA0sAD1pO6o5uN MqCjrHSyxFLlyFMnrlg96OK4RZ1UYFytper90lABTuCz7kOgf90LH/lsM VlqK+YYtkFFGchXuvTRaVv684Zru992ol5oPj29wwYu5sL7GmSZXb+CLX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMSTOFKtJXG8/2dsb2JhbABagweBCsEigR4WdIIlAQEBAwE6PwwEAgEIEQMBAQEBCg4GBQQHMhQIAQgCBA4FCBECh2IGujqPNgYrBwYSgwaBAAOUH5VQgWaBPoFqJBw X-IronPort-AV: E=Sophos;i="4.90,925,1371081600"; d="scan'208";a="260938961" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2013 17:40:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8HHeCL0027829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 17:40:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 12:40:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Harald Alvestrand Thread-Topic: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) Thread-Index: AQHOs4C/clq2b3F4c0Cq3gToydiwV5nJqo4AgAB1y4CAABEQ4A== Date: Tue, 17 Sep 2013 17:40:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1907975B@xmb-rcd-x10.cisco.com> References: <52381402.8070400@alvestrand.no> <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com> <52383E19.2070107@alvestrand.no> In-Reply-To: <52383E19.2070107@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?) 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, 17 Sep 2013 17:40:37 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, September 17, 2013 5:04 PM > To: Tirumaleswar Reddy (tireddy) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Ado= pting > draft-muthu-behave-consent-freshness?) >=20 > On 09/17/2013 12:05 PM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Harald, > > > > Please see inline > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beha= lf Of > >> Harald Alvestrand > >> Sent: Tuesday, September 17, 2013 2:04 PM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adop= ting > >> draft-muthu-behave-consent-freshness?) > >> > >> Changing subject line in order to make life easier for those who try t= o > >> review comments on the original subject.... > >> > >> On 09/17/2013 07:10 AM, Ram Mohan R (rmohanr) wrote: > >>> Hi Please see inline > >>> > >>> -----Original Message----- > >>> From: Jessie , "Huawei)" > >>> Date: Thursday, 12 September 2013 1:27 PM > >>> To: "rtcweb@ietf.org" > >>> Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness? > >>> > >>>> Hi all, > >>>> > >>>> As a newcomer to RTCWEB, I have some doubts after I have read the dr= aft. > >>>> > >>>> 1. in "4. Solution Overview", may be it would be better to clarify = when > >>>> to send a STUN Binding Request(in the middle of a media session or b= efore > >>>> sending traffic, during sending traffic or only during silence perio= ds) > >>>> and which side to send the request(controlling agent or both sides)? > >>> The introduction section explains when consent is needed. During the > >>> initial call setup ICE connectivity checks are used. This mechanism > >>> described in this document is for periodic consent after initial sess= ions > >>> is setup. > >>> > >>>> 2. in " 7. Security Considerations", there are the following words.= As > >>>> when one agent receives STUN Binding Request, unlike the processing = of > >>>> indication message, it have to do more processes to send the Respons= e > >>>> message, I am not sure whether it is appreciate not to authenticate = the > >>>> source and respond directly. Is it more open to malicious attacks? > >>> I am not clear on what you asking here. The below text just tells tha= t > >>> there is no need to re-asserting the username/password that was sent > >>> initially during ICE checks. Are you saying this can lead to attacks = ? If > >>> yes can you explain on what you meant in detail ? > >> The text below is wrong. > >> > >> If, as is commonly the case, an attacker has the ability to inject > >> packets on the wire with the same IP address as the victim, the attack= er > >> can forge ICE packets. > >> > >> If the victim's correspondent checks MESSAGE-INTEGRITY (which implicit= ly > >> checks username and password), he will detect that these packets don't > >> have the correct authorization, and throw them away. > >> > >> If the victim's correspondent does not check MESSAGE-INTEGRITY, the > >> attacker can keep renewing any consent to receive as long as he wants, > >> even though the victim wanted to stop consenting. > > Since each endpoint contributes at least 24 bits of randomness to the i= ce- > ufrag which provides 48 bits of randomness. It would not be possible for = off- > path attacker to guess those 48 bits to cause the endpoint to perform HMA= C- > SHA1 validation of the MESSAGE-INTEGRITY attribute. Hence my understandin= g is > for consent freshness checking MESSAGE-INTEGRITY is not be required, only > checking IP address and USERNAME attribute looks sufficient to handle off= -path > attacks. > > >=20 > Are we talking past each other? >=20 > In order to perform HMAC-SHA1 validation of the MESSAGE-INTEGRITY > attribute, the HMAC-SHA1 function takes two inputs: The key and the messa= ge. >=20 > From RFC 5389 section 15.4: >=20 > For long-term credentials, the key is 16 bytes: >=20 > key =3D MD5(username ":" realm ":" SASLprep(password)) >=20 > For short-term credentials: >=20 > key =3D SASLprep(password) >=20 > In other words: A successful HMAC that produces a match with the > MESSAGE-INTEGRITY attribute value means that the producer of the > MESSAGE-INTEGRITY attribute knows the password, and, if long term > credentials are used, he knows the username. >=20 > This implicitly reasserts the password (and possibly the username), and > the words we're discussing: >=20 > "Once that connection to the remote > peer has been established with ICE, the consent to continue sending > traffic does not benefit from re-asserting that same username and > password, so long as the senders and receiver's IP addresses remain > the same (as they usually do)." Agreed, the above text in the draft needs to be corrected.=20 -Tiru. >=20 > don't make any sense to me. > If they don't make any sense to other people, they do not belong in the > document. >=20 >=20 >=20 >=20 From cowwoc@bbs.darktech.org Tue Sep 17 11:54:41 2013 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 9C31511E8534 for ; Tue, 17 Sep 2013 11:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmCOYCTsgLzl for ; Tue, 17 Sep 2013 11:54:36 -0700 (PDT) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9412D11E8546 for ; Tue, 17 Sep 2013 11:54:36 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id h11so4305846vbh.2 for ; Tue, 17 Sep 2013 11:54:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=syqFjkCCKC/yVo0st+padWZ/fNsRKKcJg9HvgapG6vk=; b=MnpC/FNXLBBN53IW3undNqmKnt11SNOoevl1q7lMz2B9uQsGO+R+wTmCFYURFTqaxP RNEGiQ+vinKeEASpbyPdRuuLLSFj82RcrYeXMhWqh35JWSKDJOMmJkuZpjEvpjiclri8 SINq7jiXdmexsgh95vBpiLU22ot/bLE6LrPGN+z926SbMbrdYaSoNjbDyrUjoWAGUDAH XFDb+XAIyquk4iIZrGvrvup2P+RPisNoG5wBFZhjlbwq87TAFnGYOzGM1HpSSW265pF0 1uds6fiIhfrHUgXThdn6EwZik1X4hKJAOvtMdxjLzzIXopepQfjK9X4l/p4D9IBWF4fg 9ScQ== X-Gm-Message-State: ALoCoQnVk0uw+v4PK7zSgDW+toeGWhG0H24EOvLBWFlSCIBbroPHjJ06lpbjfHM8im6p9Q+Y8s8d X-Received: by 10.220.88.13 with SMTP id y13mr10961413vcl.20.1379444074889; Tue, 17 Sep 2013 11:54:34 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id m6sm26154326vdi.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 11:54:34 -0700 (PDT) Message-ID: <5238A564.2070601@bbs.darktech.org> Date: Tue, 17 Sep 2013 14:54:28 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030508010109070800030408" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 18:54:41 -0000 This is a multi-part message in MIME format. --------------030508010109070800030408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, Seeing as this discussion stems from licensing concerns, I like to propose the following alternative: 1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point. 2. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video codec. This will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision. Gili 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. Gili On 13/09/2013 12:52 PM, Ted Hardie wrote: > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030508010109070800030408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ted,

    Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:
  1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.
  2. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video codec.

    This will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili


1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


Gili

On 13/09/2013 12:52 PM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin,
so please review now.  Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be
verified on the mailing list for anyone who can't participate. The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their
presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,  Cullen, and Ted


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

--------------030508010109070800030408-- From christer.holmberg@ericsson.com Tue Sep 17 12:36:37 2013 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 822FB11E8138 for ; Tue, 17 Sep 2013 12:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=-1.390, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9pH02GICyjD for ; Tue, 17 Sep 2013 12:36:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 856C711E8107 for ; Tue, 17 Sep 2013 12:36:27 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-03-5238af3ac322 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.82.25272.A3FA8325; Tue, 17 Sep 2013 21:36:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 17 Sep 2013 21:36:26 +0200 From: Christer Holmberg To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Video Codec Selection Plan Thread-Index: AQHOsKGlgFckpjmyWUWeg8/SX7SR85nKK+EAgAAsdkA= Date: Tue, 17 Sep 2013 19:36:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A6064@ESESSMB209.ericsson.se> References: <5238A564.2070601@bbs.darktech.org> In-Reply-To: <5238A564.2070601@bbs.darktech.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A6064ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja7Veosgg83/1S3O3PzPbrH2Xzu7 A5PHkwnT2T2WLPnJFMAUxWWTkpqTWZZapG+XwJXR/s2zYGtRxY3J11kbGNcndjFyckgImEhs bZrBDGGLSVy4t54NxBYSOMoo0XNao4uRC8hewijx6f1O9i5GDg42AQuJ7n/aIDUiAp4Sf6e/ B6sXFjCQaDx3jBUibigxdfksVpByEQEriY9bmUDCLAKqEsfnXgZbxSvgK7Fp5g2oVWUSje+e gbVyAo15uG89WD0j0DnfT60Bs5kFxCU+HLwOdaaAxJI956FsUYmXj/+xQthKEj82XGKBqM+X eL1zHiPELkGJkzOfsExgFJmFZNQsJGWzkJRBxPUkbkydwgZha0ssW/gaql5XYsa/QyzI4gsY 2VcxchSnFiflphsZbGIExs3BLb8tdjBe/mtziFGag0VJnHeL3plAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYw7ptzhFtq4+NGJ67Nity3hfXht//F/myY220hpLGb99EBawftfn4OmrwpL +C6+tCl3VYt0+27l27HP/Xp49epfxlqBovIpTpk6F4x+uK19avH68DkJg2n+5itTzfpaSk2+ RBveLXcMXr+Al8N3brGbIUfC0wmzlqqcf1gQreOwm/nYpef7wlqVWIozEg21mIuKEwGNPCTM aQIAAA== Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 19:36:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A6064ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, SDP Offer/Answer is used to negotiate codecs etc, so the API (JSEP) already= provides such negotiation mechanism. (Obviously the peers also need to negotiate with each other, but whatever p= rotocol is used for that is outside the scope.) Regards, Christer L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta cowwoc L=E4hetetty: 17. syyskuuta 2013 21:54 Vastaanottaja: rtcweb@ietf.org Aihe: Re: [rtcweb] Video Codec Selection Plan Hi Ted, Seeing as this discussion stems from licensing concerns, I like to prop= ose the following alternative: 1. Mandate a video codec whose IPR has expired. I agree that video quali= ty will degrade, which brings me to the next point. 2. Provide a negotiation mechanism which would allow peers to "upgrade" = to a superior (optionally-implemented) video codec. This will allow us to support VP8, VP9, H264, H265 or whatever other co= dec people like without the fear of transcoding or IPR. I believe that in m= ost cases negotiation will succeed in upgrading to a superior codec. It wil= l also encourage (as opposed to force) vendors to support each other's code= cs, which is the right way to go in light of the political nature of this d= ecision. Gili 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. Gili On 13/09/2013 12:52 PM, Ted Hardie wrote: WG, The chairs have created a plan for how to perform the Video Codec selection in our WG. The chairs are asking for review of our plan on how to undertake the mandatory-to-implement video codec selection. We'd much prefer to have comments on the mechanics before they begin, so please review now. Proponents of a particular proposal should note both the actions required and the timelines proposed. The main goal of this plan is to hold a consensus call on which of the proposed alternatives we as a WG should select at one of the WG sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate. The chairs will recuse themselves from judging this particular consensus. In the WG session each codec proposal will be allowed an equal amount of time to highlight the arguments for their proposal. After that a there will be a slot for discussion and clarifying questions. To enable the WG participants to get answers to any questions, the proposals in draft form and any supporting material MUST be made available by 6th of October. This is to ensure that the WG participants can verify or object to any claims or statements in the proposal material prior to the WG session. We chairs would really not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any arguments on the list ahead of time to enable the proponents to respond to such arguments. The proposed consensus questions will be of the following form: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. You may indicate support on both questions and we encourage you to do so if you can live with either, even if you have a preference for one over the other. Additional proposals than the previous ones are welcome, but must be submitted as draft and their proponents must notify the chairs no later than the 6th of October that they also have a candidate proposal. In case the WG fails to reach consensus we chairs propose that we use the alternative decision process as discussed in RFC3929. The method and its usage will be discussed on the list should the WG not establish consensus on a proposal for mandatory to implement video codec. regards, Magnus, Cullen, and Ted _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C4A6064ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

SDP Offer/= Answer is used to negotiate codecs etc, so the API (JSEP) already provides = such negotiation mechanism.

 = ;

(Obviously= the peers also need to negotiate with each other, but whatever protocol is= used for that is outside the scope.)

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] Puolesta cowwoc
L=E4hetetty: 17. syyskuuta 2013 21:54
Vastaanottaja: rtcweb@ietf.org
Aihe: Re: [rtcweb] Video Codec Selection Plan

 

Hi Ted,

    Seeing as this discussion stems from licensing concerns,= I like to propose the following alternative:

  1. Mandate a video codec whose IPR has expired. I agree that video quality wil= l degrade, which brings me to the next point.
  2. Provide a negotiation mechanism which would allow peers to "upgrade&qu= ot; to a superior (optionally-implemented) video codec.

    3.     This will allow us to support VP8, VP9, H264, H265 or= whatever other codec people like without the fear of transcoding or IPR. I= believe that in most cases negotiation will succeed in upgrading to a supe= rior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way t= o go in light of the political nature of this decision.

    Gili


    1. If you support H.264 as the mandatory to implement codec or are
    willing to live with it as the MTI, please raise your hand now.

    2. If you support VP8 as the mandatory to implement codec or are
    willing to live with it as the MTI, please raise your hand now.


    Gili

    On 13/09/2013 12:52 PM, Ted Hardie wrote:

WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin,
so please review now.  Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be
verified on the mailing list for anyone who can't participate. The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their
presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,  Cullen, and Ted




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4A6064ESESSMB209erics_-- From cowwoc@bbs.darktech.org Tue Sep 17 12:48:09 2013 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 6521B11E855C for ; Tue, 17 Sep 2013 12:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmxZkeQ7urTO for ; Tue, 17 Sep 2013 12:48:04 -0700 (PDT) Received: from mail-ye0-f181.google.com (mail-ye0-f181.google.com [209.85.213.181]) by ietfa.amsl.com (Postfix) with ESMTP id 824A811E8569 for ; Tue, 17 Sep 2013 12:48:04 -0700 (PDT) Received: by mail-ye0-f181.google.com with SMTP id r14so2442232yen.26 for ; Tue, 17 Sep 2013 12:48:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=7MTg2gp01ft1CSg4RECnLuy1/kk3mXypLA/flqaNsDQ=; b=TTZoMKPAYC4QiMC3qLqIanfHdhXEYImFSYx4ZlSaAsMDnvfd4Yhxn748AUFfadl93p fePoJjIolEfUKb0ybv7EA+vLQ/7XRKxFKPLED1mTJj/y2GVXRFcWudgXAnz61om2bJvP RsmNiNLA80Sl9Yoru4+m1eyUGTV7PIR+Ky6FqagTZjYpY6hnABEComvxNjw7c1rfIbs8 uj6kAKk1B4TOMFnMo5U9dNmQRg4yd+3/9Z+gMlWPJ7yDVfgzvjqzu9gPqfmeGotNT6dv rLRWxdY3oqFCjOM+qQO5sEqtfkbEtBu9uRqDCjUAszvepwgIVEjDv07VD5bqcFJEsuBq bjJQ== X-Gm-Message-State: ALoCoQkPs7dFbfdgxt/IYsm9c4onBh/uPpFtFyH+V+svjECndos00ScGn5NxrA3wVS5cjplb0K5T X-Received: by 10.236.139.112 with SMTP id b76mr3417196yhj.112.1379447283801; Tue, 17 Sep 2013 12:48:03 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id e10sm48553291yhj.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:48:02 -0700 (PDT) Message-ID: <5238B1EE.20505@bbs.darktech.org> Date: Tue, 17 Sep 2013 15:47:58 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <5238A564.2070601@bbs.darktech.org> <7594FB04B1934943A5C02806D1A2204B1C4A6064@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A6064@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050303010104060505080205" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 19:48:09 -0000 This is a multi-part message in MIME format. --------------050303010104060505080205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit So then the only question is: is there a reasonable video codec whose IPR has expired that we can agree on? My goal is to displease everyone equally. By picking a neutral codec, acknowledging that it displeases all parties in some way, we should be able to defuse most of the politics surrounding the decision. Gili On 17/09/2013 3:36 PM, Christer Holmberg wrote: > > Hi, > > SDP Offer/Answer is used to negotiate codecs etc, so the API (JSEP) > already provides such negotiation mechanism. > > (Obviously the peers also need to negotiate with each other, but > whatever protocol is used for that is outside the scope.) > > Regards, > > Christer > > *Lähettäjä:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *Puolesta *cowwoc > *Lähetetty:* 17. syyskuuta 2013 21:54 > *Vastaanottaja:* rtcweb@ietf.org > *Aihe:* Re: [rtcweb] Video Codec Selection Plan > > Hi Ted, > > Seeing as this discussion stems from licensing concerns, I like to > propose the following alternative: > > 1. Mandate a video codec whose IPR has expired. I agree that video > quality will degrade, which brings me to the next point. > 2. Provide a negotiation mechanism which would allow peers to > "upgrade" to a superior (optionally-implemented) video codec. > > This will allow us to support VP8, VP9, H264, H265 or whatever > other codec people like without the fear of transcoding or IPR. I > believe that in most cases negotiation will succeed in upgrading to a > superior codec. It will also encourage (as opposed to force) vendors > to support each other's codecs, which is the right way to go in light > of the political nature of this decision. > > Gili > > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > > Gili > > On 13/09/2013 12:52 PM, Ted Hardie wrote: > > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no > later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video > codec. > > regards, > > Magnus, Cullen, and Ted > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------050303010104060505080205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    So then the only question is: is there a reasonable video codec whose IPR has expired that we can agree on?

    My goal is to displease everyone equally. By picking a neutral codec, acknowledging that it displeases all parties in some way, we should be able to defuse most of the politics surrounding the decision.

Gili

On 17/09/2013 3:36 PM, Christer Holmberg wrote:

Hi,

 

SDP Offer/Answer is used to negotiate codecs etc, so the API (JSEP) already provides such negotiation mechanism.

 

(Obviously the peers also need to negotiate with each other, but whatever protocol is used for that is outside the scope.)

 

Regards,

 

Christer

 

Lähettäjä: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Puolesta cowwoc
Lähetetty: 17. syyskuuta 2013 21:54
Vastaanottaja: rtcweb@ietf.org
Aihe: Re: [rtcweb] Video Codec Selection Plan

 

Hi Ted,

    Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:

  1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.
  2. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video codec.

    This will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili


1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


Gili

On 13/09/2013 12:52 PM, Ted Hardie wrote:

WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before they begin,
so please review now.  Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be
verified on the mailing list for anyone who can't participate. The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their
presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,  Cullen, and Ted




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

 


--------------050303010104060505080205-- From john@jlc.net Tue Sep 17 12:53:34 2013 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 7D57911E8140 for ; Tue, 17 Sep 2013 12:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.998 X-Spam-Level: X-Spam-Status: No, score=-104.998 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwL8OABjKhZK for ; Tue, 17 Sep 2013 12:53:29 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2461511E8138 for ; Tue, 17 Sep 2013 12:53:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 47BE4C94C2; Tue, 17 Sep 2013 15:53:26 -0400 (EDT) Date: Tue, 17 Sep 2013 15:53:26 -0400 From: John Leslie To: cowwoc Message-ID: <20130917195326.GH59497@verdi> References: <5238A564.2070601@bbs.darktech.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5238A564.2070601@bbs.darktech.org> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 19:53:34 -0000 cowwoc wrote: > > Seeing as this discussion stems from licensing concerns, I like to > propose the following alternative: > > 1. Mandate a video codec whose IPR has expired. I agree that video > quality will degrade, which brings me to the next point. This is what I support. It won't be that long before whatever we mandate will be obsolete anyway... But the chairs have determined we shall do one more round of duking it out between H.264 and VP8. To get any other codec considered this round, you must write a draft proposing it and stating its benefits. I do not choose to do so. Perhaps we _will_ choose one of these front-runners... Regardless, folks seem determined to argue the technical benefits of these front-runners; and a number of us hold pretty strong opinions of which of these is "better". I don't wish to complicate that argument. YMMV, of course... -- John Leslie From ted.ietf@gmail.com Tue Sep 17 13:10:28 2013 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 42DB211E8140 for ; Tue, 17 Sep 2013 13:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA3LtlDpwefI for ; Tue, 17 Sep 2013 13:10:27 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0AECC11E810A for ; Tue, 17 Sep 2013 13:10:26 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so11448837ief.29 for ; Tue, 17 Sep 2013 13:10:26 -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=Snn0UqeedZGsk4m5J+Kqk8e01WT7WfOlSNaq4LA4vXA=; b=NXoJUOthfEXHXifmgjNupnr68/9TKeAb/6B+5kDbf236gDsumm1mAzmdGYUCnr3a/E vxkLiFLXHet5Fb3LcSGNH8F9Kh6It8g8koDylIqna7xwvyHsUs714C58+zZw6o6l86WN PrnLjJeFtUrOY00la4jQaT+E5eqBTWyDqzAN9vKwAgGmYtHeUgscmC4nG9acrFK/PX+0 k40AzetCJ1WM1Mq83Y03aIJMhHeVNhuYwR9Apye+DHn99KdD32ZkAYI+P8wTS08hRnfM 5A9q4eHGRsMBqzkshdgHGvmkGpTCBLoKcGBxdLz3bz7q7N92TwHXo2rFDoUpy+0wHAK0 2n8g== MIME-Version: 1.0 X-Received: by 10.42.51.6 with SMTP id c6mr9026775icg.3.1379448626587; Tue, 17 Sep 2013 13:10:26 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 17 Sep 2013 13:10:26 -0700 (PDT) In-Reply-To: <5238A564.2070601@bbs.darktech.org> References: <5238A564.2070601@bbs.darktech.org> Date: Tue, 17 Sep 2013 13:10:26 -0700 Message-ID: From: Ted Hardie To: cowwoc Content-Type: multipart/alternative; boundary=20cf301cc4565fb25104e699e95d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 20:10:28 -0000 --20cf301cc4565fb25104e699e95d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 17, 2013 at 11:54 AM, cowwoc wrote: > Hi Ted, > > Seeing as this discussion stems from licensing concerns, I like to > propose the following alternative: > > 1. Mandate a video codec whose IPR has expired. I agree that video > quality will degrade, which brings me to the next point. > > To propose a video codec, please write a draft before the deadline and put forward the technical details you're proposing (if there are profiles, for example, which profile). Saying you want this on the list isn't enough information for folks to judge the proposal. This is why we are insisting on drafts at a deadline that gives folks the opportunity to review the proposal. > 1. Provide a negotiation mechanism which would allow peers to > "upgrade" to a superior (optionally-implemented) video codec. > > This is a base part of the system. Ted > This will allow us to support VP8, VP9, H264, H265 or whatever other > codec people like without the fear of transcoding or IPR. I believe that in > most cases negotiation will succeed in upgrading to a superior codec. It > will also encourage (as opposed to force) vendors to support each other's > codecs, which is the right way to go in light of the political nature of > this decision. > > Gili > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > > Gili > > > On 13/09/2013 12:52 PM, Ted Hardie wrote: > > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf301cc4565fb25104e699e95d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <cowwoc@bb= s.darktech.org> wrote:
=20 =20 =20
Hi Ted,

=A0=A0=A0 Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:
  1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.

To propose a video code= c, please write a draft before the deadline and put forward the technical d= etails you're proposing (if there are profiles, for example, which prof= ile).=A0 Saying you want this on the list isn't enough information for = folks to judge the proposal.=A0 This is why we are insisting on drafts at a= deadline that gives folks the opportunity to review the proposal.

  1. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video = codec.


This is a base pa= rt of the system.

Ted

=A0

=A0=A0=A0 This will allow= us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili


1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


Gili


On 13/09/2013 12:52 PM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before the= y begin,
so please review now.=A0 Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate= . The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=A0 Cullen, and Ted


__________________________________=
_____________
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


--20cf301cc4565fb25104e699e95d-- From bernard_aboba@hotmail.com Tue Sep 17 13:18:37 2013 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 F0CC711E81B2 for ; Tue, 17 Sep 2013 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U82ZNLjSLuzD for ; Tue, 17 Sep 2013 13:18:32 -0700 (PDT) Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79411E8141 for ; Tue, 17 Sep 2013 13:18:32 -0700 (PDT) Received: from BLU402-EAS371 ([65.55.116.9]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Sep 2013 13:18:30 -0700 X-TMN: [xTa6kCmiAFqIrEwPWb4amPYvrCiqg2+nx50wMB68h2s=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <5238A564.2070601@bbs.darktech.org> <20130917195326.GH59497@verdi> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <20130917195326.GH59497@verdi> Date: Tue, 17 Sep 2013 13:18:29 -0700 To: John Leslie X-OriginalArrivalTime: 17 Sep 2013 20:18:30.0677 (UTC) FILETIME=[13853C50:01CEB3E3] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 17 Sep 2013 20:18:38 -0000 On Sep 17, 2013, at 12:53, "John Leslie" wrote: > cowwoc wrote: >>=20 >>=20 >> 1. Mandate a video codec whose IPR has expired. I agree that video >> quality will degrade, which brings me to the next point. >=20 > This is what I support. It won't be that long before whatever we > mandate will be obsolete anyway... [BA] I agree that the VP8 vs. H.264 discussion is past it's due date. Howev= er, starting a discussion of even older, completely obsolete codecs that no b= rowser vendor has shown an interest in doesn't seem like a better choice. > I do not choose to do so. [BA] Thank you for your leadership on this. Now if everyone else would follo= w your lead we can recover the time for more productive pursuits :)= From ietf-secretariat-reply@ietf.org Tue Sep 17 13:31:41 2013 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 B4C3A11E8581 for ; Tue, 17 Sep 2013 13:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFkE0+hm9c8i for ; Tue, 17 Sep 2013 13:31:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BC511E8563 for ; Tue, 17 Sep 2013 13:31:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917203141.18586.77178.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 13:31:41 -0700 From: IETF Secretariat Subject: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 20:31:41 -0000 Changed milestone "Send STUN Usage for Consent Freshness to IESG for publication as proposed standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From bernard_aboba@hotmail.com Tue Sep 17 14:33:22 2013 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 734DE11E82FF for ; Tue, 17 Sep 2013 14:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhEYiq9uybQQ for ; Tue, 17 Sep 2013 14:32:59 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9966311E85D2 for ; Tue, 17 Sep 2013 14:32:12 -0700 (PDT) Received: from BLU169-W73 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Sep 2013 14:32:11 -0700 X-TMN: [H3kwqX3VODtN4JimJAFo7J2DYCHJRiRNJzA9Jfx+ITE=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_8f222632-cb83-4518-886b-d36de25f0e66_" From: Bernard Aboba To: Magnus Westerlund , "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" Date: Tue, 17 Sep 2013 14:32:11 -0700 Importance: Normal In-Reply-To: <5238446D.8050700@ericsson.com> References: , <5238446D.8050700@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Sep 2013 21:32:11.0778 (UTC) FILETIME=[5EB3B620:01CEB3ED] Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 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, 17 Sep 2013 21:33:39 -0000 --_8f222632-cb83-4518-886b-d36de25f0e66_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Magnus's comments in large part. A few notes:=20 > 1. First of all I like to bring up a document structure problem. When > reviewing this it is difficult to follow what requirements that are > added for the different use cases. I would propose that each Use Case or > general section that describe something that causes new requirements > that hasn't been listed yet in the document to define the Requirement > there....>> This makes the incremental use cases much more understandable= in how> they add requirements. [BA] +1 on this. I found myself flipping back and forth between the requir= ements definition and the use cases to try to understand what the increment= al functionality was and sometimes it was less than obvious why a requireme= nt (such as "no wiretapping") was dropped from the basic use case. To me= =2C it makes more sense to lay out basic use cases=2C and then to focus on = incremental requirement additions based on that. =20 > The document focuses on requirements related to real-time media > streams and data exchange. Requirements related to privacy=2C > signalling between the browser and web server etc. are currently not > considered. >=20 > I think this needs to be rewritten. The draft actually do consider a > number of high level security and privacy concerns. [BA] I do think the document covers the security and privacy concerns (modu= lo some issues I had with the "wiretapping" definition). So I think we can= eliminate that last sentence entirely.=20 > It is essential that the communication cannot be wiretapped > [RFC2804]. >=20 > This sentence returns a number of times in this document. I think it is > a general security requirement that applies to probably all of the use > cases. If there is one use case that don't need to enable protection > against this=2C then please be explicit about that.>> My Suggestion is to= move this into the general considerations section. [BA] There is a use case ("distributed music band") that omits the requirem= ent=2C but that omission didn't make sense to me. Personally=2C I would el= evate this to a universal requirement in the base use case=2C and all other= cases.=20 > One user has an unreliable Internet connection. It sometimes loses > packets=2C and sometimes goes down completely. >=20 > I guess the requirement here is to handle this in a graceful way from > media transport and rendering perspective. The packet loss is also > unclear as I don't know if the intention is to capture spurious packet > losses due to the link media=2C or congestion losses. I think some > expansion of this is needed. [BA] To me=2C connectivity loss and packet loss are somewhat different issu= es. Connectivity loss leads to addition of requirements relating to keep-a= lives and/or consent (e.g. if the peer drops off the Internet=2C the consen= t mechanism will detect it eventually and stop sending). Packet loss lead= s to requirements relating to concealment=2C FEC and/or RTX. So lumping th= em together doesn't make sense to me. > 3.2.2.2. Derived Requirements >=20 > F1=2C F2=2C F3=2C F4=2C F5=2C F8=2C F9=2C F10=2C F20=2C F25=2C F28=2C = F29 >=20 > A1=2C A2=2C A3=2C A4=2C A5=2C A6=2C A7=2C A8=2C A9=2C A10=2C A11=2C A1= 2 >=20 > How come this list of Derived Requirements are shorter than for the > parent use case which has the following list: [BA] Yes=2C that didn't make sense to me either. Better to stick with the = requirements of the base case and add to them as necessary for more advance= d cases. If something is deleted=2C I think the document needs to explain = why=2C but in this case the deletions didn't make sense to me.=20 > If a firewall only allows HTTP traffic=2C then can we really assume that > the firewall administrator per default will accept WebRTC Media and Data > traffic? [BA] Data traffic sent as SCTP/DTLS/UDP will *not* work in this case. Web= sockets might=2C but then I think you need to clarify whether "HTTP only" i= ncludes websockets (in my experience=2C in most cases it won't).=20 > But in addition to this=2C one of the users can share what is being > displayed on her/his screen with a peer. The user can choose to > share the entire screen=2C part of the screen (part selected by the > user) or what a selected applicaton displays with the peer. >=20 > Does this needs mentioning of additional high level security requirements= ? [BA] The requirements may need to be *very* high level (e.g. "without intr= oducing other vulnerabilities")=2C because this is a tricky area that may e= nd up requiring significant work.=20 > 12. Section 3.2.10.1: >=20 > The service providers are interconnected by some means=2C but exchange > no more information about the users than what can be carried using > SIP. >=20 > NOTE: More profiling of what this means may be needed. >=20 > The Note=2C can it be removed=2C or do we need additional text in this do= cument? [BA] The NOTE tells me that we're not even really sure why this section is = there. So perhaps we should figure out what it adds above and beyond the g= ateway use case.=20 = --_8f222632-cb83-4518-886b-d36de25f0e66_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Magnus's comments i= n large part.  =3BA few notes: =3B

>=3B 1. First of a= ll I like to bring up a document structure problem. When
>=3B reviewin= g this it is difficult to follow what requirements that are
>=3B added= for the different use cases. I would propose that each Use Case or
>= =3B general section that describe something that causes new requirements>=3B that hasn't been listed yet in the document to define the Requireme= nt
>=3B there....
>=3B<= /span>
>=3B This makes the i= ncremental use cases much more understandable in how
>=3B the= y add requirements.


[BA] +1 on this. &nbs= p=3BI found myself flipping back and forth between the requirements definit= ion and the use cases to =3B
try to understand what the incre= mental functionality was and sometimes it was less than obvious why a requi= rement (such as "no wiretapping") was dropped from the basic use case. &nbs= p=3BTo me=2C it makes more sense to lay out basic use cases=2C and then to = focus on incremental requirement additions based on that.  =3B

>=3B The document focuses on requirements related to = real-time media
>=3B streams and data exchange. Requirements relat= ed to privacy=2C
>=3B signalling between the browser and web server= etc. are currently not
>=3B considered.
>=3B
>=3B I thi= nk this needs to be rewritten. The draft actually do consider a
>=3B n= umber of high level security and privacy concerns.

[BA] I do think the document covers the security and privacy concerns (mod= ulo some issues I had with the "wiretapping" definition).  =3BSo I thin= k we can eliminate that last sentence entirely. =3B

>=3B It is essential that the= communication cannot be wiretapped
>=3B [RFC2804].
>= =3B
>=3B This sentence returns a number of times in this document. I = think it is
>=3B a general security requirement that applies to probab= ly all of the use
>=3B cases. If there is one use case that don't need= to enable protection
>=3B against this=2C then please be explicit abo= ut that.
>=3B
>=3B My Suggestion is to move this in= to the general considerations section.

[BA] There is a us= e case ("distributed music band") that omits the requirement=2C but that om= ission didn't make sense to me.  =3BPersonally=2C I would elevate this = to a universal requirement in the base use case=2C and all other cases.&nbs= p=3B

>=3B One user has an unreliable Internet= connection. It sometimes loses
>=3B packets=2C and sometimes goes= down completely.
>=3B
>=3B I guess the requirement here is to h= andle this in a graceful way from
>=3B media transport and rendering p= erspective. The packet loss is also
>=3B unclear as I don't know if th= e intention is to capture spurious packet
>=3B losses due to the link = media=2C or congestion losses. I think some
>=3B expansion of this is = needed.

[BA] To me=2C connectivity loss and packet loss a= re somewhat different issues.  =3BConnectivity loss leads to addition o= f requirements relating to keep-alives and/or consent (e.g. if the peer dro= ps off the Internet=2C the consent mechanism will detect it eventually and = stop sending).  =3B Packet loss leads to requirements relating to conce= alment=2C FEC and/or RTX.  =3BSo lumping them together doesn't make sen= se to me. =3B
 =3B
>=3B 3.2.2.2. Derived Requirements
>=3B
>=3B = F1=2C F2=2C F3=2C F4=2C F5=2C F8=2C F9=2C F10=2C F20=2C F25=2C F28=2C F29<= br>>=3B
>=3B A1=2C A2=2C A3=2C A4=2C A5=2C A6=2C A7=2C A8=2C A9= =2C A10=2C A11=2C A12
>=3B
>=3B How come this list of Derived Re= quirements are shorter than for the
>=3B parent use case which has the= following list:

[BA] Yes=2C that didn't make sense to me= either.  =3BBetter to stick with the requirements of the base case and= add to them as necessary for more advanced cases.  =3BIf something is = deleted=2C I think the document needs to explain why=2C but in this case th= e deletions didn't make sense to me. =3B

>= =3B If a firewall only allows HTTP traffic=2C then can we really assume tha= t
>=3B the firewall administrator per default will accept WebRTC Media= and Data
>=3B traffic?

[BA]  =3BData traffic se= nt as SCTP/DTLS/UDP will *not* work in this case.  =3BWebsockets might= =2C but then I think you need to clarify whether "HTTP only" includes webso= ckets (in my experience=2C in most cases it won't). =3B

<= /div>
>=3B But in addition to this=2C one of the users can share w= hat is being
>=3B displayed on her/his screen with a peer. The use= r can choose to
>=3B share the entire screen=2C part of the screen = (part selected by the
>=3B user) or what a selected applicaton disp= lays with the peer.
>=3B
>=3B Does this needs mentioning of addi= tional high level security requirements?

[BA]  =3BThe= requirements may need to be *very* high level (e.g. "without introducing o= ther vulnerabilities")=2C because this is a tricky area that may end up req= uiring significant work. =3B

>=3B 12. Sectio= n 3.2.10.1:
>=3B
>=3B The service providers are interconnected= by some means=2C but exchange
>=3B no more information about the u= sers than what can be carried using
>=3B SIP.
>=3B
>=3B = NOTE: More profiling of what this means may be needed.
>=3B
>= =3B The Note=2C can it be removed=2C or do we need additional text in this = document?

[BA] The NOTE tells me that we're not ev= en really sure why this section is there.  =3BSo perhaps we should figu= re out what it adds above and beyond the gateway use case. =3B

= --_8f222632-cb83-4518-886b-d36de25f0e66_-- From internet-drafts@ietf.org Tue Sep 17 15:23:28 2013 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 9E99C21F9D62; Tue, 17 Sep 2013 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyeG12ClHmBb; Tue, 17 Sep 2013 15:23:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB3B21F9CF3; Tue, 17 Sep 2013 15:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917222328.25460.80088.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 15:23:28 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 22:23:28 -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 : Javascript Session Establishment Protocol Author(s) : Justin Uberti Cullen Jennings Filename : draft-ietf-rtcweb-jsep-04.txt Pages : 46 Date : 2013-09-17 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From juberti@google.com Tue Sep 17 15:29:32 2013 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 5FABD11E85D2 for ; Tue, 17 Sep 2013 15:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tDgb+Ssy4QX for ; Tue, 17 Sep 2013 15:29:31 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 86E7F11E85F2 for ; Tue, 17 Sep 2013 15:29:26 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so11335999iec.16 for ; Tue, 17 Sep 2013 15:29:26 -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; bh=59no2aJdmjH8yH9zwksUxlwwGK5sGrB3INz9vreOx4A=; b=Anojan01iLf1Qjid+QtKrMdteinJH9OZCQa3lKrOg3sbL/QJ2P7U3ItOLEis0Udjuh WP2tHliBSPGGgooosvzWWizj6Gk0vB7I8Tk+5FFP1uJ2WguPZ6PpDPcVOiRgfcTq/uXx VsJ/TNv8fFI+LeNQ0cNXcJg5a4UJctX8kmcP51mHyoDLvvGTOVTqUNp1da97ye8Gnbza 3ajF4GU3Nl8Yok5Yl8V3hu5pP1yqdS45HcGGnrOdUkt8C1kCJO2AxJOA52kGZlkS9etu GwZFzmEV5Fp9bXC7gGmSvEvnyQnj/AicefzcKrT25DpfaB/ps6Siac3lVmE1B1yTsiI4 qbOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=59no2aJdmjH8yH9zwksUxlwwGK5sGrB3INz9vreOx4A=; b=j/FBx4WILhgZYCIIVFF4x5qMKIN5WaElt9zt0GsO+7ZXLAsI1TJNvZRClkBThmbSpJ 60VsQIm23Od/qf+o+vO0EvgVTIY0qL46xJXHxzZ8sBW+pDDHsTLEVLWPZ8qsEB24+Dsl BlAH0ouZX9UW2w1CgUCfXIKPHMQmCt6sd7lmEugUwEhzLoI6hKZlc1WLKz2InF4dJMAa c3rgo61Yf4tGPfzPArgyd7R4PUPGwQVWH3J9sfxPEhDKIihmygCGRn8sPFyjovMM4TBO sNzi4Sx2YuPr+QZh2pjSBT/3GfZXL+x151GvGHPlYN/ObLkdMSNWikrSSKWb8UosHMIx 2VjA== X-Gm-Message-State: ALoCoQnn6zvnZAByUIQ9jwsp0mNLRfbO6zB13IuDoPDyNLdhJC5/mf6S7Kg/6iEF3HL14DlUTz4qhvr4fTZivWqRiaMucQ/GI+NrJQ8xiP7X3k9D4f3x4UPmf/gt8Ue9VEolKHh0r7c3mB6Vh6VjowyHu9hcTvs6n2cyo0FSlYlZVa/WJp3qzZzXMus0dATILyj3muwk83yv X-Received: by 10.50.103.6 with SMTP id fs6mr2075483igb.16.1379456965889; Tue, 17 Sep 2013 15:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.104 with HTTP; Tue, 17 Sep 2013 15:29:05 -0700 (PDT) In-Reply-To: <523817FC.80406@ericsson.com> References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> From: Justin Uberti Date: Tue, 17 Sep 2013 15:29:05 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b2e0abb6f6d4504e69bdae0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 17 Sep 2013 22:29:32 -0000 --047d7b2e0abb6f6d4504e69bdae0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The draft has now been posted at http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with 13 new pages of text. Readers should focus on Section 5, which specifies the behavior of createOffer/createAnswer, as well as Appendix A.2, which provides examples of the generated SDP. On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2013-09-17 10:47, Harald Alvestrand wrote: > > Magnus, > > > > what is the expected duration of the call? > > 2 hour maximum > > Magnus > > > > > On 09/17/2013 10:38 AM, Magnus Westerlund wrote: > >> WG, > >> > >> I know that the new JSEP Draft is not yet submitted. I am hoping that = it > >> will show up during the morning hours for the US based people. That wa= y > >> everyone gets at least some few hours to look at the draft prior to th= e > >> call. If it hasn't we will postpone the call, but I really hope we can > >> avoid this. I will send a notice to the WG if we have to postpone it. > >> > >> Cheers > >> > >> Magnus > >> > >> On 2013-09-11 07:58, Magnus Westerlund wrote: > >>> WG, > >>> > >>> There will be a new version of JSEP draft coming out Monday. As a > follow > >>> up to get as much progress on this topic as possible. The chairs and > >>> authors are offering a informal walk through session on Wednesday the > >>> 18th. People will be strongly recommended to have reviewed the new > >>> draft. > >>> > >>> The intention of the session is enable the authors to inform you abou= t > >>> the latest changes, any issues to consider and what needs further > >>> discussion. The will also enable you as participant after your review > of > >>> the document to ask clarifying questions or for motivations behind > >>> choices, and raise issues you have spotted. > >>> > >>> The session is not intended to solve issues or judge consensus on par= t > >>> of the draft. Discussions of what is the best solution etc, will to b= e > >>> cut off. > >>> > >>> This will be a webex conference per details below. > >>> > >>> Cheers > >>> > >>> Magnus Westerlund > >>> > >>> Topic: RTCWeb - JSEP > >>> Date: Wednesday, September 18, 2013 > >>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > >>> Meeting Number: 302 061 238 > >>> Meeting Password: ietf > >>> > >>> ------------------------------------------------------- > >>> To join the online meeting (Now from mobile devices!) > >>> ------------------------------------------------------- > >>> 1. Go to > >>> > https://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW=3DNYjk= 4NmE0ODBj&RT=3DMiM0 > >>> > >>> > >>> 2. Enter your name and email address. > >>> 3. Enter the meeting password: ietf > >>> 4. Click "Join Now". > >>> > >>> To view in other time zones or languages, please click the link: > >>> > https://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW=3DNYjk= 4NmE0ODBj&ORT=3DMiM0 > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> To join the teleconference only > >>> ------------------------------------------------------- > >>> 1. Dial into Cisco WebEx (view all Global Access Numbers at > >>> http://cisco.com/en/US/about/doing_business/conferencing/index.html > >>> 2. Follow the prompts to enter the Meeting Number (listed above) or > >>> Access Code followed by the # sign. > >>> > >>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > >>> > >>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > >>> > >>> India: +91.80.4350.1111 Germany: +49.619.6773.9002 > >>> > >>> Japan: +81.3.5763.9394 China: +86.10.8515.5666 > >>> > >>> > >>> ---------------------------------------------------------------- > >>> ALERT =E2=80=93 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM W= ITHIN THE > >>> (408) OR (919) AREA CODES > >>> ---------------------------------------------------------------- > >>> Please dial the local access number for your area from the list below= : > >>> - San Jose/Milpitas (408) area: 525-6800 > >>> - RTP (919) area: 392-3330 > >>> > >>> Dialing the WebEx toll free numbers from within 408 or 919 area codes > is > >>> not enabled (non-Cisco phones). =E2=80=9C If you dial the toll-free n= umbers > >>> within the 408 or 919 area codes you will be instructed to hang up an= d > >>> dial the local access number.=E2=80=9D Please use the call-back optio= n whenever > >>> possible and otherwise dial local numbers only. The affected toll fre= e > >>> numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) > >>> 349-3520 for the RTP area. > >>> > >> > > > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 > --047d7b2e0abb6f6d4504e69bdae0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The draft has now been posted at=C2=A0http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, wit= h 13 new pages of text.

Readers should focus on Section 5, which specifies the behav= ior of createOffer/createAnswer, as well as Appendix A.2, which provides ex= amples of the generated SDP.


On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlu= nd <magnus.westerlund@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On 2013-09-17 10:47, Harald Alvestrand wrote:
> Magnus,
>
> what is the expected duration of the call?

2 hour maximum

Magnus

>
> On 09/17/2013 10:38 AM, Magnus Westerlund wrote:
>> WG,
>>
>> I know that the new JSEP Draft is not yet submitted. I am hoping t= hat it
>> will show up during the morning hours for the US based people. Tha= t way
>> everyone gets at least some few hours to look at the draft prior t= o the
>> call. If it hasn't we will postpone the call, but I really hop= e we can
>> avoid this. I will send a notice to the WG if we have to postpone = it.
>>
>> Cheers
>>
>> Magnus
>>
>> On 2013-09-11 07:58, Magnus Westerlund wrote:
>>> WG,
>>>
>>> There will be a new version of JSEP draft coming out Monday. A= s a follow
>>> up to get as much progress on this topic as possible. The chai= rs and
>>> authors are offering a informal walk through session on Wednes= day the
>>> 18th. People will be strongly recommended to have reviewed the= new
>>> draft.
>>>
>>> The intention of the session is enable the authors to inform y= ou about
>>> the latest changes, any issues to consider and what needs furt= her
>>> discussion. The will also enable you as participant after your= review of
>>> the document to ask clarifying questions or for motivations be= hind
>>> choices, and raise issues you have spotted.
>>>
>>> The session is not intended to solve issues or judge consensus= on part
>>> of the draft. Discussions of what is the best solution etc, wi= ll to be
>>> cut off.
>>>
>>> This will be a webex conference per details below.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>> Topic: RTCWeb - JSEP
>>> Date: Wednesday, September 18, 2013
>>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00= )
>>> Meeting Number: 302 061 238
>>> Meeting Password: ietf
>>>
>>> -------------------------------------------------------
>>> To join the online meeting (Now from mobile devices!)
>>> -------------------------------------------------------
>>> 1. Go to
>>> ht= tps://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW=3D= NYjk4NmE0ODBj&RT=3DMiM0
>>>
>>>
>>> 2. Enter your name and email address.
>>> 3. Enter the meeting password: ietf
>>> 4. Click "Join Now".
>>>
>>> To view in other time zones or languages, please click the lin= k:
>>> h= ttps://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW= =3DNYjk4NmE0ODBj&ORT=3DMiM0
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> To join the teleconference only
>>> -------------------------------------------------------
>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at >>> http://cisco.com/en/US/about/doing_busi= ness/conferencing/index.html
>>> 2. Follow the prompts to enter the Meeting Number (listed abov= e) or
>>> Access Code followed by the # sign.
>>>
>>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>>
>>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>>
>>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>>
>>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>>
>>>
>>> --------------------------------------------------------------= --
>>> ALERT =E2=80=93 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS= FROM WITHIN THE
>>> (408) OR (919) AREA CODES
>>> --------------------------------------------------------------= --
>>> Please dial the local access number for your area from the lis= t below:
>>> - San Jose/Milpitas (408) area: 525-6800
>>> - RTP (919) area: 392-3330
>>>
>>> Dialing the WebEx toll free numbers from within 408 or 919 are= a codes is
>>> not enabled (non-Cisco phones). =E2=80=9C If you dial the toll= -free numbers
>>> within the 408 or 919 area codes you will be instructed to han= g up and
>>> dial the local access number.=E2=80=9D Please use the call-bac= k option whenever
>>> possible and otherwise dial local numbers only. The affected t= oll free
>>> numbers are: (866) 432-9903 for the San Jose/Milpitas area and= (866)
>>> 349-3520 for the RTP area.
>>>
>>
>
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone = =C2=A0+46 10 71= 48287
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

--047d7b2e0abb6f6d4504e69bdae0-- From ekr@rtfm.com Tue Sep 17 17:13:52 2013 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 3764211E815E for ; Tue, 17 Sep 2013 17:13:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENchbPc6m0JZ for ; Tue, 17 Sep 2013 17:13:48 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id A29C911E8153 for ; Tue, 17 Sep 2013 17:13:47 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id k4so2434142qaq.4 for ; Tue, 17 Sep 2013 17:13:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pUnCIKqWrRNUZCvw7DM6xgsL99nsLgenA5PMl82j/Js=; b=ioVMJIdKXAzJyWE+I2qsyIpUhz9Pw7q9FBOg8hbKU5dGo7+0Lmoroj2kP1uB9cos2G 5cxj4Dca065uQu4hc5K2AhX9XdIu4El/ciC2b9SoilwEW/QxKd01MUwPxxTlQ0/kWsFM dmuDhCpBH6yo7gwtYSicaDvKOKKc8HNsJsKBIrxZmJSnprJD0eww+AcI++HgPa2lboT8 ciRNM/dYVp8xOcm+rhiMzrFpMqRqU+0U9yHd/wKFfGjLKMZKrGJyF5GP7Gr3D+1/5Lo6 KfqJxaPDcDLDtdIDz5A2jwqxJZtKVIDHR4CFTDpYwSOfKQzGvM6VSCL+sXBCK44zUbVy QR6w== X-Gm-Message-State: ALoCoQmhyMfxEHvN5TKfNRvHB26Pa3Q6oAbmFEVG9epM3VbG/7iin5CEWvT5NOo0Rr1k6KXKARPq X-Received: by 10.49.58.174 with SMTP id s14mr14613939qeq.73.1379463226037; Tue, 17 Sep 2013 17:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.42.68 with HTTP; Tue, 17 Sep 2013 17:13:05 -0700 (PDT) X-Originating-IP: [2620:101:8003:200:3c4b:f377:1bf5:f3de] In-Reply-To: <5238A564.2070601@bbs.darktech.org> References: <5238A564.2070601@bbs.darktech.org> From: Eric Rescorla Date: Tue, 17 Sep 2013 17:13:05 -0700 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=047d7b6d8afc91b17104e69d4fe7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 18 Sep 2013 00:13:52 -0000 --047d7b6d8afc91b17104e69d4fe7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 17, 2013 at 11:54 AM, cowwoc wrote: > Hi Ted, > > Seeing as this discussion stems from licensing concerns, I like to > propose the following alternative: > > 1. Mandate a video codec whose IPR has expired. I agree that video > quality will degrade, which brings me to the next point. > 2. Provide a negotiation mechanism which would allow peers to > "upgrade" to a superior (optionally-implemented) video codec. > > Negotiation has always been part of the design. The sole question is which codec is mandatory to implement, not which is the sole codec to be mandated. -Ekr This will allow us to support VP8, VP9, H264, H265 or whatever other > codec people like without the fear of transcoding or IPR. I believe that in > most cases negotiation will succeed in upgrading to a superior codec. It > will also encourage (as opposed to force) vendors to support each other's > codecs, which is the right way to go in light of the political nature of > this decision. > > Gili > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > > Gili > > > On 13/09/2013 12:52 PM, Ted Hardie wrote: > > WG, > > The chairs have created a plan for how to perform the Video Codec > selection in our WG. The chairs are asking for review of our plan on > how to undertake the mandatory-to-implement video codec selection. > We'd much prefer to have comments on the mechanics before they begin, > so please review now. Proponents of a particular proposal should > note both the actions required and the timelines proposed. > > The main goal of this plan is to hold a consensus call on which of > the proposed alternatives we as a WG should select at one of the WG > sessions in Vancouver. Such a consensus call will of course be > verified on the mailing list for anyone who can't participate. The > chairs will recuse themselves from judging this particular > consensus. > > In the WG session each codec proposal will be allowed an equal amount > of time to highlight the arguments for their proposal. After that a > there will be a slot for discussion and clarifying questions. > > To enable the WG participants to get answers to any questions, the > proposals in draft form and any supporting material MUST be made > available by 6th of October. This is to ensure that the WG > participants can verify or object to any claims or statements in > the proposal material prior to the WG session. We chairs would really > not like to see the proponents bring up new arguments at their > presentation. Also the WG participants are expected to raise any > arguments on the list ahead of time to enable the proponents to > respond to such arguments. > > The proposed consensus questions will be of the following form: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may indicate support on both questions and we encourage you to do > so if you can live with either, even if you have a preference for one > over the other. > > Additional proposals than the previous ones are welcome, but must be > submitted as draft and their proponents must notify the chairs no later > than the 6th of October that they also have a candidate proposal. > > In case the WG fails to reach consensus we chairs propose that we use > the alternative decision process as discussed in RFC3929. The method > and its usage will be discussed on the list should the WG not > establish consensus on a proposal for mandatory to implement video codec. > > regards, > > Magnus, Cullen, and Ted > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6d8afc91b17104e69d4fe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <cowwoc@bbs.darktec= h.org> wrote:
=20 =20 =20
Hi Ted,

=A0=A0=A0 Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:
  1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.
  2. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video = codec.
Negotiation has always been p= art of the design. The sole question is which
codec is mandatory = to implement, not which is the sole codec to be mandated.

-Ekr


=A0 =A0 T= his will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili


1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


Gili


On 13/09/2013 12:52 PM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before the= y begin,
so please review now.=A0 Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate= . The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=A0 Cullen, and Ted


__________________________________=
_____________
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


--047d7b6d8afc91b17104e69d4fe7-- From lgeyser@gmail.com Wed Sep 18 01:39:20 2013 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 3288911E81EC for ; Wed, 18 Sep 2013 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoG1TC2z-cAy for ; Wed, 18 Sep 2013 01:39:18 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 50BC811E81E9 for ; Wed, 18 Sep 2013 01:39:18 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so6433206lbi.32 for ; Wed, 18 Sep 2013 01:39:17 -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=Yn2l5FUsOcbbe5tFlEKEkM7Jwe4B/8DC5N9kEGuuc+4=; b=g3D3sLbF15WaRpLBhu2VnAqfN6HI8IE9vTSMob/J8QrB2j10o3rO5rj2f6ootNOo0A 4T/JAIedmPbnryJM/5/rayBCYEOVP1EH9AX1ExJe+UVUKYkwu3V1zWYsOsZjP0pwnx5w WaE9nYb+oMF0cApBkkSiZ6yU+3qBqQ4IDbDgiC3cWtoYM10GsNhwv7vMWGAAnG8q/Koj QKNvGzIC1v9Y+ivQlcCG+hpbFsKLgoAMXdExtdEdWkmGin4F+ak3i2YzAYsrKP7GOnfG 6O2Ghp9CIg/W/Cg0fRdS3SweAGUPHzT6KIWraM2UIyyUMv3Zic26JN7ixnBN/FvlHxlq CKlQ== MIME-Version: 1.0 X-Received: by 10.112.40.110 with SMTP id w14mr528002lbk.42.1379493557187; Wed, 18 Sep 2013 01:39:17 -0700 (PDT) Received: by 10.114.0.239 with HTTP; Wed, 18 Sep 2013 01:39:17 -0700 (PDT) In-Reply-To: References: <5238A564.2070601@bbs.darktech.org> Date: Wed, 18 Sep 2013 10:39:17 +0200 Message-ID: From: Leon Geyser To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11336bba7239ba04e6a45f88 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 18 Sep 2013 08:39:20 -0000 --001a11336bba7239ba04e6a45f88 Content-Type: text/plain; charset=ISO-8859-1 Anyone willing to create a draft for H.261? On 18 September 2013 02:13, Eric Rescorla wrote: > > > > On Tue, Sep 17, 2013 at 11:54 AM, cowwoc wrote: > >> Hi Ted, >> >> Seeing as this discussion stems from licensing concerns, I like to >> propose the following alternative: >> >> 1. Mandate a video codec whose IPR has expired. I agree that video >> quality will degrade, which brings me to the next point. >> 2. Provide a negotiation mechanism which would allow peers to >> "upgrade" to a superior (optionally-implemented) video codec. >> >> Negotiation has always been part of the design. The sole question is which > codec is mandatory to implement, not which is the sole codec to be > mandated. > > -Ekr > > > This will allow us to support VP8, VP9, H264, H265 or whatever other >> codec people like without the fear of transcoding or IPR. I believe that in >> most cases negotiation will succeed in upgrading to a superior codec. It >> will also encourage (as opposed to force) vendors to support each other's >> codecs, which is the right way to go in light of the political nature of >> this decision. >> >> Gili >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> >> Gili >> >> >> On 13/09/2013 12:52 PM, Ted Hardie wrote: >> >> WG, >> >> The chairs have created a plan for how to perform the Video Codec >> selection in our WG. The chairs are asking for review of our plan on >> how to undertake the mandatory-to-implement video codec selection. >> We'd much prefer to have comments on the mechanics before they begin, >> so please review now. Proponents of a particular proposal should >> note both the actions required and the timelines proposed. >> >> The main goal of this plan is to hold a consensus call on which of >> the proposed alternatives we as a WG should select at one of the WG >> sessions in Vancouver. Such a consensus call will of course be >> verified on the mailing list for anyone who can't participate. The >> chairs will recuse themselves from judging this particular >> consensus. >> >> In the WG session each codec proposal will be allowed an equal amount >> of time to highlight the arguments for their proposal. After that a >> there will be a slot for discussion and clarifying questions. >> >> To enable the WG participants to get answers to any questions, the >> proposals in draft form and any supporting material MUST be made >> available by 6th of October. This is to ensure that the WG >> participants can verify or object to any claims or statements in >> the proposal material prior to the WG session. We chairs would really >> not like to see the proponents bring up new arguments at their >> presentation. Also the WG participants are expected to raise any >> arguments on the list ahead of time to enable the proponents to >> respond to such arguments. >> >> The proposed consensus questions will be of the following form: >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> You may indicate support on both questions and we encourage you to do >> so if you can live with either, even if you have a preference for one >> over the other. >> >> Additional proposals than the previous ones are welcome, but must be >> submitted as draft and their proponents must notify the chairs no later >> than the 6th of October that they also have a candidate proposal. >> >> In case the WG fails to reach consensus we chairs propose that we use >> the alternative decision process as discussed in RFC3929. The method >> and its usage will be discussed on the list should the WG not >> establish consensus on a proposal for mandatory to implement video codec. >> >> regards, >> >> Magnus, Cullen, and Ted >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://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 > > --001a11336bba7239ba04e6a45f88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anyone willing to create a draft for H.261?


On 18 September 20= 13 02:13, Eric Rescorla <ekr@rtfm.com> wrote:



On Tue, Sep 17, 20= 13 at 11:54 AM, cowwoc <cowwoc@bbs.darktech.org> wrote= :
=20 =20 =20
Hi Ted,

=A0=A0=A0 Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:
  1. Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.
  2. Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video = codec.
Negotiation has always = been part of the design. The sole question is which
codec is mand= atory to implement, not which is the sole codec to be mandated.

-Ekr

=A0 =A0 This will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili


1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


Gili


On 13/09/2013 12:52 PM, Ted Hardie wrote:
WG,

The chairs have created a plan for how to perform the Video Codec
selection in our WG. The chairs are asking for review of our plan on
how to undertake the mandatory-to-implement video codec selection.
We'd much prefer to have comments on the mechanics before the= y begin,
so please review now.=A0 Proponents of a particular proposal should
note both the actions required and the timelines proposed.

The main goal of this plan is to hold a consensus call on which of
the proposed alternatives we as a WG should select at one of the WG
sessions in Vancouver. Such a consensus call will of course be verified on the mailing list for anyone who can't participate= . The
chairs will recuse themselves from judging this particular
consensus.

In the WG session each codec proposal will be allowed an equal amount
of time to highlight the arguments for their proposal. After that a
there will be a slot for discussion and clarifying questions.

To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session. We chairs would really
not like to see the proponents bring up new arguments at their presentation. Also the WG participants are expected to raise any
arguments on the list ahead of time to enable the proponents to
respond to such arguments.

The proposed consensus questions will be of the following form:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

You may indicate support on both questions and we encourage you to do
so if you can live with either, even if you have a preference for one
over the other.

Additional proposals than the previous ones are welcome, but must be
submitted as draft and their proponents must notify the chairs no later
than the 6th of October that they also have a candidate proposal.

In case the WG fails to reach consensus we chairs propose that we use
the alternative decision process as discussed in RFC3929. The method
and its usage will be discussed on the list should the WG not
establish consensus on a proposal for mandatory to implement video codec.

regards,

Magnus,=A0 Cullen, and Ted


_______________________________________________
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


--001a11336bba7239ba04e6a45f88-- From xiphmont@gmail.com Wed Sep 18 01:50:03 2013 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 CD9BB11E80E6 for ; Wed, 18 Sep 2013 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 555z7Stqh3tA for ; Wed, 18 Sep 2013 01:50:02 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 52A0311E820F for ; Wed, 18 Sep 2013 01:49:31 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so6346892lbh.33 for ; Wed, 18 Sep 2013 01:49:30 -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=5laXPDMzdsVOBIaZi9GO6eVfKyZfkfZuA9WRrvNXvlI=; b=Vnyi50VQ0wHHb/WYZmiOjpqM5FR1A7lyVnvUQcQo7RnLq9v2iCLUBT0BEuZJXWsL5I KDwgul8aSMgSZOUOmCBVpSdp+ntSyZbN8p9YbhBEV7bKVXz2Bbj8iT2pT1kAN+KH+0eM 2Kw12hV1H4iwP0GoXuLFT1XRkUl8j8r+U/w/7XUCeTVoBuH83VEdReY9JpIQMDllRQ5e qGggtrWRPx4b0n5/eGBc5/zSqYLyXhqhEQ/G611ayVIistF3PCc6VjLjiKOuEfRlJMjy a8r/A8CT/OWngM7txRfTWa5JVZnh8IRKm7nJU+0v6dF+XScpv40OlUDwICEfXDjWhHJj QxaQ== MIME-Version: 1.0 X-Received: by 10.112.14.102 with SMTP id o6mr10351000lbc.28.1379494170091; Wed, 18 Sep 2013 01:49:30 -0700 (PDT) Received: by 10.112.11.48 with HTTP; Wed, 18 Sep 2013 01:49:29 -0700 (PDT) In-Reply-To: References: <5238A564.2070601@bbs.darktech.org> Date: Wed, 18 Sep 2013 04:49:29 -0400 Message-ID: From: Monty Montgomery To: Leon Geyser Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Plan 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, 18 Sep 2013 08:50:17 -0000 I'll see your h.261 and raise one Theora. At least it has one hell of an encoder. Cheers, Monty On Wed, Sep 18, 2013 at 4:39 AM, Leon Geyser wrote: > Anyone willing to create a draft for H.261? > > > On 18 September 2013 02:13, Eric Rescorla wrote: >> >> >> >> >> On Tue, Sep 17, 2013 at 11:54 AM, cowwoc wrote: >>> >>> Hi Ted, >>> >>> Seeing as this discussion stems from licensing concerns, I like to >>> propose the following alternative: >>> >>> Mandate a video codec whose IPR has expired. I agree that video quality >>> will degrade, which brings me to the next point. >>> Provide a negotiation mechanism which would allow peers to "upgrade" to a >>> superior (optionally-implemented) video codec. >> >> Negotiation has always been part of the design. The sole question is which >> codec is mandatory to implement, not which is the sole codec to be >> mandated. >> >> -Ekr >> >> >>> This will allow us to support VP8, VP9, H264, H265 or whatever other >>> codec people like without the fear of transcoding or IPR. I believe that in >>> most cases negotiation will succeed in upgrading to a superior codec. It >>> will also encourage (as opposed to force) vendors to support each other's >>> codecs, which is the right way to go in light of the political nature of >>> this decision. >>> >>> Gili >>> >>> >>> 1. If you support H.264 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> 2. If you support VP8 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> >>> Gili >>> >>> >>> On 13/09/2013 12:52 PM, Ted Hardie wrote: >>> >>> WG, >>> >>> The chairs have created a plan for how to perform the Video Codec >>> selection in our WG. The chairs are asking for review of our plan on >>> how to undertake the mandatory-to-implement video codec selection. >>> We'd much prefer to have comments on the mechanics before they begin, >>> so please review now. Proponents of a particular proposal should >>> note both the actions required and the timelines proposed. >>> >>> The main goal of this plan is to hold a consensus call on which of >>> the proposed alternatives we as a WG should select at one of the WG >>> sessions in Vancouver. Such a consensus call will of course be >>> verified on the mailing list for anyone who can't participate. The >>> chairs will recuse themselves from judging this particular >>> consensus. >>> >>> In the WG session each codec proposal will be allowed an equal amount >>> of time to highlight the arguments for their proposal. After that a >>> there will be a slot for discussion and clarifying questions. >>> >>> To enable the WG participants to get answers to any questions, the >>> proposals in draft form and any supporting material MUST be made >>> available by 6th of October. This is to ensure that the WG >>> participants can verify or object to any claims or statements in >>> the proposal material prior to the WG session. We chairs would really >>> not like to see the proponents bring up new arguments at their >>> presentation. Also the WG participants are expected to raise any >>> arguments on the list ahead of time to enable the proponents to >>> respond to such arguments. >>> >>> The proposed consensus questions will be of the following form: >>> >>> 1. If you support H.264 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> 2. If you support VP8 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> You may indicate support on both questions and we encourage you to do >>> so if you can live with either, even if you have a preference for one >>> over the other. >>> >>> Additional proposals than the previous ones are welcome, but must be >>> submitted as draft and their proponents must notify the chairs no later >>> than the 6th of October that they also have a candidate proposal. >>> >>> In case the WG fails to reach consensus we chairs propose that we use >>> the alternative decision process as discussed in RFC3929. The method >>> and its usage will be discussed on the list should the WG not >>> establish consensus on a proposal for mandatory to implement video codec. >>> >>> regards, >>> >>> Magnus, Cullen, and Ted >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From christer.holmberg@ericsson.com Wed Sep 18 03:50:38 2013 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 EB74811E8214 for ; Wed, 18 Sep 2013 03:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpgR7CVlHub8 for ; Wed, 18 Sep 2013 03:50:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B20D311E8212 for ; Wed, 18 Sep 2013 03:50:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-42-5239856f4a42 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1F.D8.22048.F6589325; Wed, 18 Sep 2013 12:50:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Wed, 18 Sep 2013 12:50:13 +0200 From: Christer Holmberg To: Justin Uberti , Magnus Westerlund Thread-Topic: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) Thread-Index: AQHOrrQWfRliQImOMU+QwmqTVLuQyJnJg4YAgAACuACAAADsAIAA5ImAgADXzPA= Date: Wed, 18 Sep 2013 10:50:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A6A20@ESESSMB209.ericsson.se> References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A6A20ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW5+q2WQwbu/5hZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgybhx7y1TQ95Sp4tDZj8wNjE9uM3UxcnJICJhI PH7WygZhi0lcuLceyObiEBI4zCgx/ddjFghnCaPExXktQA4HB5uAhUT3P20QU0QgRuLd0WKQ XmYBdYk7i8+xg9jCAqkSE39NZQWxRQTSJGZPPcwOYftJTPkHMpKTg0VAVWLv1TNgN/AK+Eo0 z93FBLHqMqNEz57F7CDzOQUCJQ7fNAGpYQS67fupNUwQu8Qlbj2ZD3W/gMSSPeeZIWxRiZeP /7GCtEoIKEos75eDKM+X2NR0FWqVoMTJmU9YJjCKzkIyaRaSsllIymYBTWIW0JRYv0sfokRR Ykr3Q3YIW0Oidc5cdmTxBYzsqxjZcxMzc9LLzTcxAqPp4JbfBjsYN90XO8QozcGiJM67We9M oJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGxZb3HmnaL+LunIqP+buOx63vjbpAwcH6Cen1 C1m+CM/YNEeK45Rq/V7xme1Tw/7Pb17Cd09+g1Ntn41q3M/jhxM4CrY2ZVhUSvzfcm9PvQW3 fdbbImlFn5VZsZPeeeoqfd5yfk2/zb5fAhVPD349b2haEVZ5slJ5SmTD07i80vCykHVddTJK LMUZiYZazEXFiQANzVLLdAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 18 Sep 2013 10:50:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A6A20ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgbWF5IG5vdCBiZSBhYmxlIHRvIGF0dGVuZCB0aGUgcGhvbmUgbWVldGluZyB0b2Rh eSwgc28gSSBzZW5kIG15IGlucHV0IGJ5IHRoZSBlLW1haWwuDQoNCkFzIHJlcXVlc3RlZCBieSB0 aGUgV0cgY2hhaXJzLCBJ4oCZbGwgZm9jdXMgb24gY2xhcmlmaWNhdGlvbiBpc3N1ZXMvcXVlc3Rp b25zLCBhbmQgd2lsbCBmb3Igbm93IG5vdCByZXBlYXQgdGhlIGlzc3VlcyBJIGhhdmUgd2l0aCBw cmFuc3dlciBhbmQgZm9ya2luZyAoYWxzbywgd2UgbWF5IGhhdmUgZm91bmQgYSB3YXkgZm9yd2Fy ZCB0byBzb2x2ZSB0aGF0KS4NCg0KDQoNClFfMTogICAgICBNZWFuaW5nIG9mIOKAnHNlc3Npb27i gJ06DQoNCldoZW4gdGhlIGRvY3VtZW50IHRhbGtzIGFib3V0IOKAnHNlc3Npb27igJ0sIEkgdGhp bmsgaXQgbmVlZHMgdG8gYmUgbW9yZSBjbGVhciB0aGF0IHRoZSBzY29wZSBvZiBhIHNlc3Npb24g aXMgYSBQZWVyQ29ubmVjdGlvbi4NCg0KRm9yIGV4YW1wbGUsIGFzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDMuNSwgaW4gdGhlIGNhc2Ugb2YgZm9ya2luZyB0aGVyZSBtaWdodCBiZSBtdWx0aXBsZSBQ ZWVyQ29ubmVjdGlvbnMsIGVhY2ggZm9ybWluZyBkaWZmZXJlbnQg4oCcc2Vzc2lvbnPigJ0g4oCT IGV2ZW50aG91Z2ggdGhleSB3aWxsIGFsbCBiZSBwYXJ0IG9mIGUuZy4gdGhlIHNhbWUgaGlnaGVy LWxldmVsIFNJUCBzZXNzaW9uLg0KDQpTaW1pbGFyLCB3aGVuIHRoZSB0ZXh0IHRhbGtzIGFib3V0 IOKAnGluaXRpYWwgT2ZmZXLigJ0sIGl0IG5lZWRzIHRvIGJlIGNsZWFyIHRoYXQgaXQgcmVmZXJz IHRvIGEgZ2l2ZW4gUGVlckNvbm5lY3Rpb24uDQoNCg0KDQpRXzI6ICAgICAgRm9ya2luZw0KDQpJ IHdvdWxkIHN1Z2dlc3Qgc29tZSByZS13b3JkaW5nIChJIGFtIHdpbGxpbmcgdG8gcHJvdmlkZSB0 ZXh0KSBvZiB0aGUgZm9ya2luZyBzZWN0aW9ucy4gQXQgbGVhc3QgdGhlIGZvbGxvd2luZyBJIHdh bnQgbW9yZSBjbGVhcjoNCg0KDQoxLiAgICAgICBTaW1pbGFyIHRvIHBhcmFsbGVsIGZvcmtpbmcs IHNlcXVlbnRpYWwgZm9ya2luZyBjYW4gYWxzbyBiZSBpbXBsZW1lbnRlZCB1c2luZyBtdWx0aXBs ZSBQZWVyQ29ubmVjdGlvbnMuDQoNCg0KMi4gICAgICAgV2hlbiBhIG5ldyBQZWVyQ29ubmVjdGlv biBpcyBjcmVhdGVkLCBpdCB3aWxsIGhhdmUgZGlmZmVyZW50IGFkZHJlc3MgcHJvcGVydGllcyB0 aGFuIHRoZSDigJxtb3RoZXLigJ0gUGVlckNvbm5lY3Rpb24sIHNvIGEgbmV3IE9mZmVyIG5lZWRz IHRvIGJlIGNyZWF0ZWQgaW1tZWRpYXRlbHksIGluIG9yZGVyIHRvIGluZm9ybSB0aGUgcmVtb3Rl IHBlZXIgYWJvdXQgdGhvc2UgcHJvcGVydGllcy4gVGhlIGRyYWZ0IERPRVMgc2F5IHRoYXQgdGhl IHNhbWUgbG9jYWwgbWVkaWEgc3RyZWFtcyBhcmUgYWRkZWQgdG8gdGhlIG5ldyBQZWVyQ29ubmVj dGlvbiwgYnV0IGl0IGRvZXMgbm90IG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgbmV3IFBlZXJDb25u ZWN0aW9uIHdpbGwgaGF2ZSBkaWZmZXJlbnQgYWRkcmVzcyBwcm9wZXJ0aWVzLCBhbmQgcG9zc2li bHkgYWxzbyBvdGhlciBwcm9wZXJ0aWVzIHRoYXQgdmFyeS4gVGhlIGRyYWZ0IGFsc28gRE9FUyB0 YWxrIGFib3V0IHRoZSDigJxVUERBVEUgYXBwcm9hY2jigJ0sIGJ1dCB0aGF0IGlzIHZlcnkgdW5j bGVhciAoc2VlIFFfMykuDQoNCg0KDQozLiAgICAgICBQYXJhbGxlbCBmb3JraW5nIGRvZXMgbm90 IG5lY2Vzc2FyaWx5IG1lYW4geW91IHJlY2VpdmUgbWVkaWEgc2ltdWx0YW5lb3VzbHkgZnJvbSBt dWx0aXBsZSBlbmRwb2ludHMuIFlvdSBtaWdodCBlc3RhYmxpc2ggYSBtZWRpYSBjb25uZWN0aW9u IChlLmcuIHVzaW5nIFNJUCBwcmVjb25kaXRpb25zKSB3aXRoIG11bHRpcGxlIGVuZHBvaW50cywg YnV0IHRoYXQgZG9lcyBub3QgbWVhbiB5b3Ugd2lsbCByZWNlaXZlIG1lZGlhIGZyb20gYWxsIG9m IHRoZW0gYXQgdGhlIHNhbWUgdGltZS4gSSBjYW4gcHJvdmlkZSBzb21lIDNHUFAgY2FsbCBmbG93 cyB0aGF0IHNob3cgZXhhbXBsZXMgb2YgdGhhdC4NCg0KDQpRXzM6ICAgICAgVVBEQVRFIGFwcHJv YWNoDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSB0ZXh0IHRhbGtpbmcgYWJvdXQgdGhlIOKA nFVQREFURSBhcHByb2FjaOKAnSBhbmQg4oCcVVBEQVRFIHN0cmF0ZWd54oCdLCByZWZlcnJpbmcg dG8gUkZDIDM5NjAuIFdpdGggbXkgU0lQIGJhY2tncm91bmQsIEkga2luZCBvZiB1bmRlcnN0YW5k IHdoYXQgeW914oCZcmUgdGhpbmtpbmcgaXMsIGJ1dCBJIHRoaW5rIG5vbi1TSVAgcGVvcGxlIHdp bGwgaGF2ZSB2ZXJ5IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIGV4YWN0bHkgd2hhdCB5b3UgbWVh bi4gSSB0aGluayBpdCBpcyBtdWNoIGJldHRlciB0byBzaW1wbHkgc2F5IHRoYXQsIGZvciB0aGUg bmV3IFBlZXJDb25uZWN0aW9uLCBhbiBPZmZlciBuZWVkcyB0byBiZSBzZW50IChzZWUgUV8yKS4N Cg0KDQpRXzQ6ICAgICAgQXBwZW5kaXggQS4yLg0KDQpBcyB0aGUgZXhhbXBsZSBjb250YWlucyBC VU5ETEUsIEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSDigJwybmQgT2ZmZXLigJ0gKHdpdGggaWRl bnRpY2FsIHBvcnQgbnVtYmVycyksIGZvciBjb21wbGV0ZW5lc3MuDQoNCg0KUV81OiAgICAgIEFw cGVuZGl4IEZvcmtpbmcNCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGV4YW1wbGVzIHdpdGgg Zm9ya2luZy4NCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpG cm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogMTguIHN5eXNrdXV0YSAyMDEz IDE6MjkNClRvOiBNYWdudXMgV2VzdGVybHVuZA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtydGN3ZWJdIEpTRVAgV2FsayBUaHJvdWdoIG9uIFdlZG5lc2RheSB0aGUgMTh0aCBv ZiBTZXB0ZW1iZXIgYXQgMTcuMDAgQ0VTVCAoOCBBTSBQRFQpDQoNClRoZSBkcmFmdCBoYXMgbm93 IGJlZW4gcG9zdGVkIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtcnRjd2ViLWpzZXAtMDQudHh0LCB3aXRoIDEzIG5ldyBwYWdlcyBvZiB0ZXh0Lg0KDQpS ZWFkZXJzIHNob3VsZCBmb2N1cyBvbiBTZWN0aW9uIDUsIHdoaWNoIHNwZWNpZmllcyB0aGUgYmVo YXZpb3Igb2YgY3JlYXRlT2ZmZXIvY3JlYXRlQW5zd2VyLCBhcyB3ZWxsIGFzIEFwcGVuZGl4IEEu Miwgd2hpY2ggcHJvdmlkZXMgZXhhbXBsZXMgb2YgdGhlIGdlbmVyYXRlZCBTRFAuDQoNCk9uIFR1 ZSwgU2VwIDE3LCAyMDEzIGF0IDE6NTEgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KT24gMjAxMy0wOS0xNyAxMDo0NywgSGFyYWxkIEFsdmVzdHJhbmQgd3JvdGU6 DQo+IE1hZ251cywNCj4NCj4gd2hhdCBpcyB0aGUgZXhwZWN0ZWQgZHVyYXRpb24gb2YgdGhlIGNh bGw/DQoyIGhvdXIgbWF4aW11bQ0KDQpNYWdudXMNCg0KPg0KPiBPbiAwOS8xNy8yMDEzIDEwOjM4 IEFNLCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4+IFdHLA0KPj4NCj4+IEkga25vdyB0aGF0 IHRoZSBuZXcgSlNFUCBEcmFmdCBpcyBub3QgeWV0IHN1Ym1pdHRlZC4gSSBhbSBob3BpbmcgdGhh dCBpdA0KPj4gd2lsbCBzaG93IHVwIGR1cmluZyB0aGUgbW9ybmluZyBob3VycyBmb3IgdGhlIFVT IGJhc2VkIHBlb3BsZS4gVGhhdCB3YXkNCj4+IGV2ZXJ5b25lIGdldHMgYXQgbGVhc3Qgc29tZSBm ZXcgaG91cnMgdG8gbG9vayBhdCB0aGUgZHJhZnQgcHJpb3IgdG8gdGhlDQo+PiBjYWxsLiBJZiBp dCBoYXNuJ3Qgd2Ugd2lsbCBwb3N0cG9uZSB0aGUgY2FsbCwgYnV0IEkgcmVhbGx5IGhvcGUgd2Ug Y2FuDQo+PiBhdm9pZCB0aGlzLiBJIHdpbGwgc2VuZCBhIG5vdGljZSB0byB0aGUgV0cgaWYgd2Ug aGF2ZSB0byBwb3N0cG9uZSBpdC4NCj4+DQo+PiBDaGVlcnMNCj4+DQo+PiBNYWdudXMNCj4+DQo+ PiBPbiAyMDEzLTA5LTExIDA3OjU4LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4+PiBXRywN Cj4+Pg0KPj4+IFRoZXJlIHdpbGwgYmUgYSBuZXcgdmVyc2lvbiBvZiBKU0VQIGRyYWZ0IGNvbWlu ZyBvdXQgTW9uZGF5LiBBcyBhIGZvbGxvdw0KPj4+IHVwIHRvIGdldCBhcyBtdWNoIHByb2dyZXNz IG9uIHRoaXMgdG9waWMgYXMgcG9zc2libGUuIFRoZSBjaGFpcnMgYW5kDQo+Pj4gYXV0aG9ycyBh cmUgb2ZmZXJpbmcgYSBpbmZvcm1hbCB3YWxrIHRocm91Z2ggc2Vzc2lvbiBvbiBXZWRuZXNkYXkg dGhlDQo+Pj4gMTh0aC4gUGVvcGxlIHdpbGwgYmUgc3Ryb25nbHkgcmVjb21tZW5kZWQgdG8gaGF2 ZSByZXZpZXdlZCB0aGUgbmV3DQo+Pj4gZHJhZnQuDQo+Pj4NCj4+PiBUaGUgaW50ZW50aW9uIG9m IHRoZSBzZXNzaW9uIGlzIGVuYWJsZSB0aGUgYXV0aG9ycyB0byBpbmZvcm0geW91IGFib3V0DQo+ Pj4gdGhlIGxhdGVzdCBjaGFuZ2VzLCBhbnkgaXNzdWVzIHRvIGNvbnNpZGVyIGFuZCB3aGF0IG5l ZWRzIGZ1cnRoZXINCj4+PiBkaXNjdXNzaW9uLiBUaGUgd2lsbCBhbHNvIGVuYWJsZSB5b3UgYXMg cGFydGljaXBhbnQgYWZ0ZXIgeW91ciByZXZpZXcgb2YNCj4+PiB0aGUgZG9jdW1lbnQgdG8gYXNr IGNsYXJpZnlpbmcgcXVlc3Rpb25zIG9yIGZvciBtb3RpdmF0aW9ucyBiZWhpbmQNCj4+PiBjaG9p Y2VzLCBhbmQgcmFpc2UgaXNzdWVzIHlvdSBoYXZlIHNwb3R0ZWQuDQo+Pj4NCj4+PiBUaGUgc2Vz c2lvbiBpcyBub3QgaW50ZW5kZWQgdG8gc29sdmUgaXNzdWVzIG9yIGp1ZGdlIGNvbnNlbnN1cyBv biBwYXJ0DQo+Pj4gb2YgdGhlIGRyYWZ0LiBEaXNjdXNzaW9ucyBvZiB3aGF0IGlzIHRoZSBiZXN0 IHNvbHV0aW9uIGV0Yywgd2lsbCB0byBiZQ0KPj4+IGN1dCBvZmYuDQo+Pj4NCj4+PiBUaGlzIHdp bGwgYmUgYSB3ZWJleCBjb25mZXJlbmNlIHBlciBkZXRhaWxzIGJlbG93Lg0KPj4+DQo+Pj4gQ2hl ZXJzDQo+Pj4NCj4+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4+DQo+Pj4gVG9waWM6IFJUQ1dlYiAt IEpTRVANCj4+PiBEYXRlOiBXZWRuZXNkYXksIFNlcHRlbWJlciAxOCwgMjAxMw0KPj4+IFRpbWU6 IDg6MDAgYW0sIFBhY2lmaWMgRGF5bGlnaHQgVGltZSAoU2FuIEZyYW5jaXNjbywgR01ULTA3OjAw KQ0KPj4+IE1lZXRpbmcgTnVtYmVyOiAzMDIgMDYxIDIzOA0KPj4+IE1lZXRpbmcgUGFzc3dvcmQ6 IGlldGYNCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+PiBUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20g bW9iaWxlIGRldmljZXMhKQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAxLiBHbyB0bw0KPj4+IGh0dHBzOi8vY2lzY28ud2Vi ZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjA2NDAwODk4JlVJRD0wJlBXPU5Zams0Tm1FME9E QmomUlQ9TWlNMA0KPj4+DQo+Pj4NCj4+PiAyLiBFbnRlciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFk ZHJlc3MuDQo+Pj4gMy4gRW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6IGlldGYNCj4+PiA0LiBD bGljayAiSm9pbiBOb3ciLg0KPj4+DQo+Pj4gVG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9y IGxhbmd1YWdlcywgcGxlYXNlIGNsaWNrIHRoZSBsaW5rOg0KPj4+IGh0dHBzOi8vY2lzY28ud2Vi ZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjA2NDAwODk4JlVJRD0wJlBXPU5Zams0Tm1FME9E QmomT1JUPU1pTTANCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gVG8gam9pbiB0aGUgdGVsZWNvbmZl cmVuY2Ugb25seQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+PiAxLiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEds b2JhbCBBY2Nlc3MgTnVtYmVycyBhdA0KPj4+IGh0dHA6Ly9jaXNjby5jb20vZW4vVVMvYWJvdXQv ZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWwNCj4+PiAyLiBGb2xsb3cgdGhl IHByb21wdHMgdG8gZW50ZXIgdGhlIE1lZXRpbmcgTnVtYmVyIChsaXN0ZWQgYWJvdmUpIG9yDQo+ Pj4gQWNjZXNzIENvZGUgZm9sbG93ZWQgYnkgdGhlICMgc2lnbi4NCj4+Pg0KPj4+IFNhbiBKb3Nl LCBDQTogKzEuNDA4LjUyNS42ODAwPHRlbDolMkIxLjQwOC41MjUuNjgwMD4gUlRQOiArMS45MTku MzkyLjMzMzA8dGVsOiUyQjEuOTE5LjM5Mi4zMzMwPg0KPj4+DQo+Pj4gVVMvQ2FuYWRhOiArMS44 NjYuNDMyLjk5MDM8dGVsOiUyQjEuODY2LjQzMi45OTAzPiBVbml0ZWQgS2luZ2RvbTogKzQ0LjIw Ljg4MjQuMDExNzx0ZWw6JTJCNDQuMjAuODgyNC4wMTE3Pg0KPj4+DQo+Pj4gSW5kaWE6ICs5MS44 MC40MzUwLjExMTE8dGVsOiUyQjkxLjgwLjQzNTAuMTExMT4gR2VybWFueTogKzQ5LjYxOS42Nzcz LjkwMDI8dGVsOiUyQjQ5LjYxOS42NzczLjkwMDI+DQo+Pj4NCj4+PiBKYXBhbjogKzgxLjMuNTc2 My45Mzk0PHRlbDolMkI4MS4zLjU3NjMuOTM5ND4gQ2hpbmE6ICs4Ni4xMC44NTE1LjU2NjY8dGVs OiUyQjg2LjEwLjg1MTUuNTY2Nj4NCj4+Pg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IEFMRVJUIOKA kyBQTEVBU0UgUkVBRDogRE8gTk9UIERJQUwgVEhFIFRPTEwgRlJFRSBOVU1CRVJTIEZST00gV0lU SElOIFRIRQ0KPj4+ICg0MDgpIE9SICg5MTkpIEFSRUEgQ09ERVMNCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4g UGxlYXNlIGRpYWwgdGhlIGxvY2FsIGFjY2VzcyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRo ZSBsaXN0IGJlbG93Og0KPj4+IC0gU2FuIEpvc2UvTWlscGl0YXMgKDQwOCkgYXJlYTogNTI1LTY4 MDANCj4+PiAtIFJUUCAoOTE5KSBhcmVhOiAzOTItMzMzMA0KPj4+DQo+Pj4gRGlhbGluZyB0aGUg V2ViRXggdG9sbCBmcmVlIG51bWJlcnMgZnJvbSB3aXRoaW4gNDA4IG9yIDkxOSBhcmVhIGNvZGVz IGlzDQo+Pj4gbm90IGVuYWJsZWQgKG5vbi1DaXNjbyBwaG9uZXMpLiDigJwgSWYgeW91IGRpYWwg dGhlIHRvbGwtZnJlZSBudW1iZXJzDQo+Pj4gd2l0aGluIHRoZSA0MDggb3IgOTE5IGFyZWEgY29k ZXMgeW91IHdpbGwgYmUgaW5zdHJ1Y3RlZCB0byBoYW5nIHVwIGFuZA0KPj4+IGRpYWwgdGhlIGxv Y2FsIGFjY2VzcyBudW1iZXIu4oCdIFBsZWFzZSB1c2UgdGhlIGNhbGwtYmFjayBvcHRpb24gd2hl bmV2ZXINCj4+PiBwb3NzaWJsZSBhbmQgb3RoZXJ3aXNlIGRpYWwgbG9jYWwgbnVtYmVycyBvbmx5 LiBUaGUgYWZmZWN0ZWQgdG9sbCBmcmVlDQo+Pj4gbnVtYmVycyBhcmU6ICg4NjYpIDQzMi05OTAz IGZvciB0aGUgU2FuIEpvc2UvTWlscGl0YXMgYXJlYSBhbmQgKDg2NikNCj4+PiAzNDktMzUyMCBm b3IgdGhlIFJUUCBhcmVhLg0KPj4+DQo+Pg0KPg0KPg0KPg0KDQotLQ0KDQpNYWdudXMgV2VzdGVy bHVuZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24g UmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAg ICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODc8dGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3Pg0KRsOk csO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OTx0ZWw6JTJC NDYlMjA3MyUyMDA5NDkwNzk+DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzog bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1C4A6A20ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207 DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmhvZW56 Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjExNjE0NDY1MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ5NzYyOTU1NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBtYXkgbm90IGJlIGFibGUgdG8gYXR0ZW5kIHRoZSBwaG9uZSBtZWV0 aW5nIHRvZGF5LCBzbyBJIHNlbmQgbXkgaW5wdXQgYnkgdGhlIGUtbWFpbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFz IHJlcXVlc3RlZCBieSB0aGUgV0cgY2hhaXJzLCBJ4oCZbGwgZm9jdXMgb24NCjxiPmNsYXJpZmlj YXRpb24gaXNzdWVzL3F1ZXN0aW9uczwvYj4sIGFuZCB3aWxsIGZvciBub3cgbm90IHJlcGVhdCB0 aGUgaXNzdWVzIEkgaGF2ZSB3aXRoIHByYW5zd2VyIGFuZCBmb3JraW5nIChhbHNvLCB3ZSBtYXkg aGF2ZSBmb3VuZCBhIHdheSBmb3J3YXJkIHRvIHNvbHZlIHRoYXQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5RXzE6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1lYW5pbmcg b2Yg4oCcc2Vzc2lvbuKAnTo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIHRoZSBkb2N1bWVudCB0YWxrcyBh Ym91dCDigJxzZXNzaW9u4oCdLCBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlIG1vcmUgY2xlYXIgdGhh dCB0aGUgc2NvcGUgb2YgYSBzZXNzaW9uIGlzIGEgUGVlckNvbm5lY3Rpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5G b3IgZXhhbXBsZSwgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy41LCBpbiB0aGUgY2FzZSBvZiBm b3JraW5nIHRoZXJlIG1pZ2h0IGJlIG11bHRpcGxlIFBlZXJDb25uZWN0aW9ucywgZWFjaCBmb3Jt aW5nIGRpZmZlcmVudCDigJxzZXNzaW9uc+KAnSDigJMgZXZlbnRob3VnaCB0aGV5DQogd2lsbCBh bGwgYmUgcGFydCBvZiBlLmcuIHRoZSBzYW1lIGhpZ2hlci1sZXZlbCBTSVAgc2Vzc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNpbWlsYXIsIHdoZW4gdGhlIHRleHQgdGFsa3MgYWJvdXQg4oCcaW5pdGlhbCBPZmZl cuKAnSwgaXQgbmVlZHMgdG8gYmUgY2xlYXIgdGhhdCBpdCByZWZlcnMgdG8gYSBnaXZlbiBQZWVy Q29ubmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UV8yOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBGb3JraW5nPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBzdWdnZXN0 IHNvbWUgcmUtd29yZGluZyAoSSBhbSB3aWxsaW5nIHRvIHByb3ZpZGUgdGV4dCkgb2YgdGhlIGZv cmtpbmcgc2VjdGlvbnMuIEF0IGxlYXN0IHRoZSBmb2xsb3dpbmcgSSB3YW50IG1vcmUgY2xlYXI6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+U2ltaWxhciB0byBwYXJhbGxlbCBmb3JraW5nLCBzZXF1ZW50aWFsIGZvcmtpbmcgY2FuIGFs c28gYmUgaW1wbGVtZW50ZWQgdXNpbmcgbXVsdGlwbGUgUGVlckNvbm5lY3Rpb25zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIGEgbmV3 IFBlZXJDb25uZWN0aW9uIGlzIGNyZWF0ZWQsIGl0IHdpbGwgaGF2ZSBkaWZmZXJlbnQgYWRkcmVz cyBwcm9wZXJ0aWVzIHRoYW4gdGhlIOKAnG1vdGhlcuKAnSBQZWVyQ29ubmVjdGlvbiwgc28gYSBu ZXcgT2ZmZXIgbmVlZHMgdG8gYmUgY3JlYXRlZCBpbW1lZGlhdGVseSwgaW4gb3JkZXIgdG8gaW5m b3JtIHRoZSByZW1vdGUgcGVlciBhYm91dCB0aG9zZSBwcm9wZXJ0aWVzLiBUaGUgZHJhZnQgRE9F UyBzYXkgdGhhdCB0aGUgc2FtZSBsb2NhbCBtZWRpYSBzdHJlYW1zIGFyZSBhZGRlZCB0byB0aGUg bmV3IFBlZXJDb25uZWN0aW9uLCBidXQgaXQgZG9lcyBub3QgbWFrZSBpdCBjbGVhciB0aGF0IHRo ZSBuZXcgUGVlckNvbm5lY3Rpb24gd2lsbCBoYXZlIGRpZmZlcmVudCBhZGRyZXNzIHByb3BlcnRp ZXMsIGFuZCBwb3NzaWJseSBhbHNvIG90aGVyIHByb3BlcnRpZXMgdGhhdCB2YXJ5LiBUaGUgZHJh ZnQgYWxzbyBET0VTIHRhbGsgYWJvdXQgdGhlIOKAnFVQREFURSBhcHByb2FjaOKAnSwgYnV0IHRo YXQgaXMgdmVyeSB1bmNsZWFyIChzZWUgUV8zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFyYWxsZWwgZm9ya2luZyBkb2Vz IG5vdCBuZWNlc3NhcmlseSBtZWFuIHlvdSByZWNlaXZlIG1lZGlhIHNpbXVsdGFuZW91c2x5IGZy b20gbXVsdGlwbGUgZW5kcG9pbnRzLiBZb3UgbWlnaHQgZXN0YWJsaXNoIGEgbWVkaWEgY29ubmVj dGlvbiAoZS5nLiB1c2luZyBTSVAgcHJlY29uZGl0aW9ucykgd2l0aCBtdWx0aXBsZSBlbmRwb2lu dHMsIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4geW91IHdpbGwgcmVjZWl2ZSBtZWRpYSBmcm9tIGFs bCBvZiB0aGVtIGF0IHRoZSBzYW1lIHRpbWUuIEkgY2FuIHByb3ZpZGUgc29tZSAzR1BQIGNhbGwg Zmxvd3MgdGhhdCBzaG93IGV4YW1wbGVzIG9mIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5RXzM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFVQREFURSBhcHByb2FjaDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB1bmRlcnN0YW5k IHRoZSB0ZXh0IHRhbGtpbmcgYWJvdXQgdGhlIOKAnFVQREFURSBhcHByb2FjaOKAnSBhbmQg4oCc VVBEQVRFIHN0cmF0ZWd54oCdLCByZWZlcnJpbmcgdG8gUkZDIDM5NjAuIFdpdGggbXkgU0lQIGJh Y2tncm91bmQsIEkga2luZCBvZiB1bmRlcnN0YW5kIHdoYXQNCiB5b3XigJlyZSB0aGlua2luZyBp cywgYnV0IEkgdGhpbmsgbm9uLVNJUCBwZW9wbGUgd2lsbCBoYXZlIHZlcnkgZGlmZmljdWx0IHRv IHVuZGVyc3RhbmQgZXhhY3RseSB3aGF0IHlvdSBtZWFuLiBJIHRoaW5rIGl0IGlzIG11Y2ggYmV0 dGVyIHRvIHNpbXBseSBzYXkgdGhhdCwgZm9yIHRoZSBuZXcgUGVlckNvbm5lY3Rpb24sIGFuIE9m ZmVyIG5lZWRzIHRvIGJlIHNlbnQgKHNlZSBRXzIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlFfNDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQXBwZW5kaXggQS4yLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIHRoZSBleGFtcGxlIGNvbnRhaW5zIEJV TkRMRSwgSSB3b3VsZCBhbHNvIGxpa2UgdG8gc2VlIOKAnDI8c3VwPm5kPC9zdXA+IE9mZmVy4oCd ICh3aXRoIGlkZW50aWNhbCBwb3J0IG51bWJlcnMpLCBmb3IgY29tcGxldGVuZXNzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlFfNTombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQXBwZW5kaXggRm9ya2luZzxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291 bGQgbGlrZSB0byBzZWUgc29tZSBleGFtcGxlcyB3aXRoIGZvcmtpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IDE4LiBzeXlza3V1dGEgMjAxMyAxOjI5 PGJyPg0KPGI+VG86PC9iPiBNYWdudXMgV2VzdGVybHVuZDxicj4NCjxiPkNjOjwvYj4gcnRjd2Vi QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBKU0VQIFdhbGsgVGhy b3VnaCBvbiBXZWRuZXNkYXkgdGhlIDE4dGggb2YgU2VwdGVtYmVyIGF0IDE3LjAwIENFU1QgKDgg QU0gUERUKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBo YXMgbm93IGJlZW4gcG9zdGVkIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1ydGN3ZWItanNlcC0wNC50eHQiIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJ0Y3dl Yi1qc2VwLTA0LnR4dDwvYT4sIHdpdGggMTMgbmV3IHBhZ2VzIG9mIHRleHQuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWFkZXJzIHNob3VsZCBmb2N1cyBv biBTZWN0aW9uIDUsIHdoaWNoIHNwZWNpZmllcyB0aGUgYmVoYXZpb3Igb2YgY3JlYXRlT2ZmZXIv Y3JlYXRlQW5zd2VyLCBhcyB3ZWxsIGFzIEFwcGVuZGl4IEEuMiwgd2hpY2ggcHJvdmlkZXMgZXhh bXBsZXMgb2YgdGhlIGdlbmVyYXRlZCBTRFAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBTZXAgMTcsIDIwMTMgYXQgMTo1MSBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhy ZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPk9uIDIwMTMtMDktMTcgMTA6NDcsIEhhcmFsZCBBbHZlc3RyYW5kIHdyb3RlOjxicj4N CiZndDsgTWFnbnVzLDxicj4NCiZndDs8YnI+DQomZ3Q7IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGR1 cmF0aW9uIG9mIHRoZSBjYWxsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4yIGhvdXIgbWF4aW11bTxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5NYWdudXM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDA5LzE3LzIwMTMgMTA6MzggQU0s IE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOjxicj4NCiZndDsmZ3Q7IFdHLDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgSSBrbm93IHRoYXQgdGhlIG5ldyBKU0VQIERyYWZ0IGlzIG5vdCB5ZXQg c3VibWl0dGVkLiBJIGFtIGhvcGluZyB0aGF0IGl0PGJyPg0KJmd0OyZndDsgd2lsbCBzaG93IHVw IGR1cmluZyB0aGUgbW9ybmluZyBob3VycyBmb3IgdGhlIFVTIGJhc2VkIHBlb3BsZS4gVGhhdCB3 YXk8YnI+DQomZ3Q7Jmd0OyBldmVyeW9uZSBnZXRzIGF0IGxlYXN0IHNvbWUgZmV3IGhvdXJzIHRv IGxvb2sgYXQgdGhlIGRyYWZ0IHByaW9yIHRvIHRoZTxicj4NCiZndDsmZ3Q7IGNhbGwuIElmIGl0 IGhhc24ndCB3ZSB3aWxsIHBvc3Rwb25lIHRoZSBjYWxsLCBidXQgSSByZWFsbHkgaG9wZSB3ZSBj YW48YnI+DQomZ3Q7Jmd0OyBhdm9pZCB0aGlzLiBJIHdpbGwgc2VuZCBhIG5vdGljZSB0byB0aGUg V0cgaWYgd2UgaGF2ZSB0byBwb3N0cG9uZSBpdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IENoZWVyczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTWFnbnVzPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBPbiAyMDEzLTA5LTExIDA3OjU4LCBNYWdudXMgV2VzdGVybHVuZCB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgV0csPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IFRoZXJlIHdpbGwgYmUgYSBuZXcgdmVyc2lvbiBvZiBKU0VQIGRyYWZ0IGNvbWluZyBvdXQg TW9uZGF5LiBBcyBhIGZvbGxvdzxicj4NCiZndDsmZ3Q7Jmd0OyB1cCB0byBnZXQgYXMgbXVjaCBw cm9ncmVzcyBvbiB0aGlzIHRvcGljIGFzIHBvc3NpYmxlLiBUaGUgY2hhaXJzIGFuZDxicj4NCiZn dDsmZ3Q7Jmd0OyBhdXRob3JzIGFyZSBvZmZlcmluZyBhIGluZm9ybWFsIHdhbGsgdGhyb3VnaCBz ZXNzaW9uIG9uIFdlZG5lc2RheSB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgMTh0aC4gUGVvcGxlIHdp bGwgYmUgc3Ryb25nbHkgcmVjb21tZW5kZWQgdG8gaGF2ZSByZXZpZXdlZCB0aGUgbmV3PGJyPg0K Jmd0OyZndDsmZ3Q7IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBU aGUgaW50ZW50aW9uIG9mIHRoZSBzZXNzaW9uIGlzIGVuYWJsZSB0aGUgYXV0aG9ycyB0byBpbmZv cm0geW91IGFib3V0PGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBsYXRlc3QgY2hhbmdlcywgYW55IGlz c3VlcyB0byBjb25zaWRlciBhbmQgd2hhdCBuZWVkcyBmdXJ0aGVyPGJyPg0KJmd0OyZndDsmZ3Q7 IGRpc2N1c3Npb24uIFRoZSB3aWxsIGFsc28gZW5hYmxlIHlvdSBhcyBwYXJ0aWNpcGFudCBhZnRl ciB5b3VyIHJldmlldyBvZjxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZG9jdW1lbnQgdG8gYXNrIGNs YXJpZnlpbmcgcXVlc3Rpb25zIG9yIGZvciBtb3RpdmF0aW9ucyBiZWhpbmQ8YnI+DQomZ3Q7Jmd0 OyZndDsgY2hvaWNlcywgYW5kIHJhaXNlIGlzc3VlcyB5b3UgaGF2ZSBzcG90dGVkLjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgc2Vzc2lvbiBpcyBub3QgaW50ZW5kZWQg dG8gc29sdmUgaXNzdWVzIG9yIGp1ZGdlIGNvbnNlbnN1cyBvbiBwYXJ0PGJyPg0KJmd0OyZndDsm Z3Q7IG9mIHRoZSBkcmFmdC4gRGlzY3Vzc2lvbnMgb2Ygd2hhdCBpcyB0aGUgYmVzdCBzb2x1dGlv biBldGMsIHdpbGwgdG8gYmU8YnI+DQomZ3Q7Jmd0OyZndDsgY3V0IG9mZi48YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyB3aWxsIGJlIGEgd2ViZXggY29uZmVyZW5jZSBw ZXIgZGV0YWlscyBiZWxvdy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hl ZXJzPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE1hZ251cyBXZXN0ZXJsdW5k PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRvcGljOiBSVENXZWIgLSBKU0VQ PGJyPg0KJmd0OyZndDsmZ3Q7IERhdGU6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE4LCAyMDEzPGJy Pg0KJmd0OyZndDsmZ3Q7IFRpbWU6IDg6MDAgYW0sIFBhY2lmaWMgRGF5bGlnaHQgVGltZSAoU2Fu IEZyYW5jaXNjbywgR01ULTA3OjAwKTxicj4NCiZndDsmZ3Q7Jmd0OyBNZWV0aW5nIE51bWJlcjog MzAyIDA2MSAyMzg8YnI+DQomZ3Q7Jmd0OyZndDsgTWVldGluZyBQYXNzd29yZDogaWV0Zjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7IFRvIGpvaW4g dGhlIG9ubGluZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpPGJyPg0KJmd0OyZn dDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsgMS4gR28gdG88YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMDY0MDA4OTgm YW1wO1VJRD0wJmFtcDtQVz1OWWprNE5tRTBPREJqJmFtcDtSVD1NaU0wIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTIwNjQwMDg5 OCZhbXA7VUlEPTAmYW1wO1BXPU5Zams0Tm1FME9EQmomYW1wO1JUPU1pTTA8L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IDIuIEVudGVyIHlv dXIgbmFtZSBhbmQgZW1haWwgYWRkcmVzcy48YnI+DQomZ3Q7Jmd0OyZndDsgMy4gRW50ZXIgdGhl IG1lZXRpbmcgcGFzc3dvcmQ6IGlldGY8YnI+DQomZ3Q7Jmd0OyZndDsgNC4gQ2xpY2sgJnF1b3Q7 Sm9pbiBOb3cmcXVvdDsuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRvIHZp ZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5ndWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGlu azo8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lz Y29zYWxlcy9qLnBocD9FRD0yMDY0MDA4OTgmYW1wO1VJRD0wJmFtcDtQVz1OWWprNE5tRTBPREJq JmFtcDtPUlQ9TWlNMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcy9qLnBocD9FRD0yMDY0MDA4OTgmYW1wO1VJRD0wJmFtcDtQVz1OWWprNE5tRTBP REJqJmFtcDtPUlQ9TWlNMDwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyBUbyBq b2luIHRoZSB0ZWxlY29uZmVyZW5jZSBvbmx5PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0 OyZndDsgMS4gRGlhbCBpbnRvIENpc2NvIFdlYkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNjZXNzIE51 bWJlcnMgYXQ8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL2Npc2NvLmNvbS9lbi9V Uy9hYm91dC9kb2luZ19idXNpbmVzcy9jb25mZXJlbmNpbmcvaW5kZXguaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2luZ19idXNpbmVzcy9jb25m ZXJlbmNpbmcvaW5kZXguaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgMi4gRm9sbG93IHRoZSBw cm9tcHRzIHRvIGVudGVyIHRoZSBNZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvcjxicj4N CiZndDsmZ3Q7Jmd0OyBBY2Nlc3MgQ29kZSBmb2xsb3dlZCBieSB0aGUgIyBzaWduLjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBTYW4gSm9zZSwgQ0E6IDxhIGhyZWY9InRlbDol MkIxLjQwOC41MjUuNjgwMCI+JiM0MzsxLjQwOC41MjUuNjgwMDwvYT4gUlRQOiA8YSBocmVmPSJ0 ZWw6JTJCMS45MTkuMzkyLjMzMzAiPg0KJiM0MzsxLjkxOS4zOTIuMzMzMDwvYT48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVVMvQ2FuYWRhOiA8YSBocmVmPSJ0ZWw6JTJCMS44 NjYuNDMyLjk5MDMiPiYjNDM7MS44NjYuNDMyLjk5MDM8L2E+IFVuaXRlZCBLaW5nZG9tOg0KPGEg aHJlZj0idGVsOiUyQjQ0LjIwLjg4MjQuMDExNyI+JiM0Mzs0NC4yMC44ODI0LjAxMTc8L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluZGlhOiA8YSBocmVmPSJ0ZWw6JTJC OTEuODAuNDM1MC4xMTExIj4mIzQzOzkxLjgwLjQzNTAuMTExMTwvYT4gR2VybWFueTogPGEgaHJl Zj0idGVsOiUyQjQ5LjYxOS42NzczLjkwMDIiPg0KJiM0Mzs0OS42MTkuNjc3My45MDAyPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBKYXBhbjogPGEgaHJlZj0idGVsOiUy QjgxLjMuNTc2My45Mzk0Ij4mIzQzOzgxLjMuNTc2My45Mzk0PC9hPiBDaGluYTogPGEgaHJlZj0i dGVsOiUyQjg2LjEwLjg1MTUuNTY2NiI+DQomIzQzOzg2LjEwLjg1MTUuNTY2NjwvYT48YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsmZ3Q7Jmd0OyBBTEVSVCDigJMgUExFQVNFIFJFQUQ6IERPIE5PVCBESUFMIFRIRSBU T0xMIEZSRUUgTlVNQkVSUyBGUk9NIFdJVEhJTiBUSEU8YnI+DQomZ3Q7Jmd0OyZndDsgKDQwOCkg T1IgKDkxOSkgQVJFQSBDT0RFUzxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZn dDsmZ3Q7IFBsZWFzZSBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVyIGZvciB5b3VyIGFyZWEg ZnJvbSB0aGUgbGlzdCBiZWxvdzo8YnI+DQomZ3Q7Jmd0OyZndDsgLSBTYW4gSm9zZS9NaWxwaXRh cyAoNDA4KSBhcmVhOiA1MjUtNjgwMDxicj4NCiZndDsmZ3Q7Jmd0OyAtIFJUUCAoOTE5KSBhcmVh OiAzOTItMzMzMDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBEaWFsaW5nIHRo ZSBXZWJFeCB0b2xsIGZyZWUgbnVtYmVycyBmcm9tIHdpdGhpbiA0MDggb3IgOTE5IGFyZWEgY29k ZXMgaXM8YnI+DQomZ3Q7Jmd0OyZndDsgbm90IGVuYWJsZWQgKG5vbi1DaXNjbyBwaG9uZXMpLiDi gJwgSWYgeW91IGRpYWwgdGhlIHRvbGwtZnJlZSBudW1iZXJzPGJyPg0KJmd0OyZndDsmZ3Q7IHdp dGhpbiB0aGUgNDA4IG9yIDkxOSBhcmVhIGNvZGVzIHlvdSB3aWxsIGJlIGluc3RydWN0ZWQgdG8g aGFuZyB1cCBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDsgZGlhbCB0aGUgbG9jYWwgYWNjZXNzIG51bWJl ci7igJ0gUGxlYXNlIHVzZSB0aGUgY2FsbC1iYWNrIG9wdGlvbiB3aGVuZXZlcjxicj4NCiZndDsm Z3Q7Jmd0OyBwb3NzaWJsZSBhbmQgb3RoZXJ3aXNlIGRpYWwgbG9jYWwgbnVtYmVycyBvbmx5LiBU aGUgYWZmZWN0ZWQgdG9sbCBmcmVlPGJyPg0KJmd0OyZndDsmZ3Q7IG51bWJlcnMgYXJlOiAoODY2 KSA0MzItOTkwMyBmb3IgdGhlIFNhbiBKb3NlL01pbHBpdGFzIGFyZWEgYW5kICg4NjYpPGJyPg0K Jmd0OyZndDsmZ3Q7IDM0OS0zNTIwIGZvciB0aGUgUlRQIGFyZWEuPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLTxicj4NCjxicj4NCk1hZ251cyBXZXN0 ZXJsdW5kPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCk11bHRpbWVkaWEgVGVjaG5vbG9n aWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkVy aWNzc29uIEFCICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8IFBob25lICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NiUyMDEwJTIwNzE0ODI4NyI+ JiM0Mzs0NiAxMCA3MTQ4Mjg3PC9hPjxicj4NCkbDpHLDtmdhdGFuIDYgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgTW9iaWxlIDxhIGhyZWY9 InRlbDolMkI0NiUyMDczJTIwMDk0OTA3OSI+JiM0Mzs0NiA3MyAwOTQ5MDc5PC9hPjxicj4NClNF LTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj4NCm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C4A6A20ESESSMB209erics_-- From fippo@goodadvice.pages.de Wed Sep 18 04:46:06 2013 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 302DE11E823C for ; Wed, 18 Sep 2013 04:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-vBBv6qyt14 for ; Wed, 18 Sep 2013 04:46:02 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id C342C11E8102 for ; Wed, 18 Sep 2013 04:46:01 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8IBjx7k007211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 13:45:59 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r8IBjwDK007207; Wed, 18 Sep 2013 13:45:58 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Wed, 18 Sep 2013 13:45:58 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Justin Uberti In-Reply-To: Message-ID: References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-208692068-1379504758=:6225" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 18 Sep 2013 11:46:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --683466026-208692068-1379504758=:6225 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 17 Sep 2013, Justin Uberti wrote: > The draft has now been posted at http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with 13 new pages of text. > Readers should focus on Section 5, which specifies the behavior of createOffer/createAnswer, as well as Appendix A.2, which provides examples of the generated SDP. I have a question about the OfferToReceiveAudio / OfferToReceiveVideo sections (5.2.3.1& 5.2.3.2)... In createAnswer (I'd note that both section currently only talk about the offerer), what is the expected behaviour when those constraints are set to false and a MediaStreamTrack of the respective type has been attached to the peerconnection? Is the behaviour different when there is no MST of a certain type attached? Does this only affect the direction attribute or also whether the m-line is rejected by setting the port to zero? --683466026-208692068-1379504758=:6225-- From suhasietf@gmail.com Wed Sep 18 05:22:01 2013 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 D817011E828B for ; Wed, 18 Sep 2013 05:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TyD9OkXNlPg for ; Wed, 18 Sep 2013 05:22:00 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0234D11E82BC for ; Wed, 18 Sep 2013 05:21:38 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq15so6302997wib.6 for ; Wed, 18 Sep 2013 05:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sjegi+TLgwPvPHoM+NQD7hMgHeKnp0Ue5OJ3hxFT95k=; b=LoNRMSibcTRRmjEJ6J0YfbF18kpa6xC6W8vl3AtXpFTwka2pOQudIwN1P96bdV6ftn pc57smtRUD8gd/x0QPEtt2LYwYzogP2lTUeszgB4UiXO88njNcHGXWeSiL66XIisCng8 OOC0eVBirOV8NDupxuD2xHqulzNo6Rdur1YhGodTt59gMQgNI9BPA415cuZTJ936a5DE 1Wd5ATsVheGS5TlDJbeS4tiguYtvgz6Q/jdL2SmPep/sAOSpB7G46F7zkfj9k5kzADJP RgZjoF9i+JPsen0NmkZ4dxXnIwMSc9t6UunpAt9VHhzUd+4Mt/wfELOoCOOPWTk6IzHo w33Q== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr6853612wik.13.1379506892328; Wed, 18 Sep 2013 05:21:32 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Wed, 18 Sep 2013 05:21:32 -0700 (PDT) In-Reply-To: References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> Date: Wed, 18 Sep 2013 05:21:32 -0700 Message-ID: From: Suhas Nandakumar To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c2b01c4857ef04e6a77ad1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 18 Sep 2013 12:22:02 -0000 --001a11c2b01c4857ef04e6a77ad1 Content-Type: text/plain; charset=ISO-8859-1 I think we should include RFC5104 referenced in the sections corresponding to RTCP feedback Thanks Suhas On Tuesday, September 17, 2013, Justin Uberti wrote: > The draft has now been posted at > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with > 13 new pages of text. > > Readers should focus on Section 5, which specifies the behavior of > createOffer/createAnswer, as well as Appendix A.2, which provides examples > of the generated SDP. > > > On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > On 2013-09-17 10:47, Harald Alvestrand wrote: > > Magnus, > > > > what is the expected duration of the call? > > 2 hour maximum > > Magnus > > > > > On 09/17/2013 10:38 AM, Magnus Westerlund wrote: > >> WG, > >> > >> I know that the new JSEP Draft is not yet submitted. I am hoping that it > >> will show up during the morning hours for the US based people. That way > >> everyone gets at least some few hours to look at the draft prior to the > >> call. If it hasn't we will postpone the call, but I really hope we can > >> avoid this. I will send a notice to the WG if we have to postpone it. > >> > >> Cheers > >> > >> Magnus > >> > >> On 2013-09-11 07:58, Magnus Westerlund wrote: > >>> WG, > >>> > >>> There will be a new version of JSEP draft coming out Monday. As a > follow > >>> up to get as much progress on this topic as possible. The chairs and > >>> authors are offering a informal walk through session on Wednesday the > >>> 18th. People will be strongly recommended to have reviewed the new > >>> draft. > >>> > >>> The intention of the session is enable the authors to inform you about > >>> the latest changes, any issues to consider and what needs further > >>> discussion. The will also enable you as participant after your review > of > >>> the document to ask clarifying questions or for motivations behind > >>> choices, and raise issues you have spotted. > >>> > >>> The session is not intended to solve issues or judge consensus on part > >>> of the draft. Discussions of what is the best solution etc, will to be > >>> cut off. > >>> > >>> This will be a webex conference per details below. > >>> > >>> Cheers > >>> > >>> Magnus Westerlund > >>> > >>> Topic: RTCWeb - JSEP > >>> Date: Wednesday, September 18, 2013 > >>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > >>> Meeting Number: 302 061 238 > >>> Meeting Password: ietf > >>> > >>> ------------------------------------------------------- > >>> To join the online meeting (Now from mobile devices!) > >>> ------------------------------------------------------- > >>> 1. Go to > >>> > https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0 > >>> > >>> > >>> 2. Enter your name and email address. > >>> 3. Enter the meeting password: ietf > >>> 4. Click "Join Now". > >>> > >>> To view in other time zones or languages, please click the link: > >>> > https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0 > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> To join the teleconference only > >>> ------------------------------------------------------- > >>> 1. Dial into Cisco WebEx (view all Global Access Numbers at > >>> http://cisco.com/en/US/about/doing_business/conferencing/index.html > >>> 2. Follow the prompts to enter the Meeting Number (listed above) or > >>> Access Code followed by the # sign. > >>> > >>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > >>> > >>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > >>> > >>> India: +91 > > --001a11c2b01c4857ef04e6a77ad1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we should include RFC5104 referenced in the sections corresponding = to RTCP feedback

Thanks
Suhas=A0<= br>
On Tuesday, September 17, 2013, Justin Uberti wrote:
The draft has now been posted at=A0ht= tp://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with 1= 3 new pages of text.

Readers should focus on Section 5, which specifies the behav= ior of createOffer/createAnswer, as well as Appendix A.2, which provides ex= amples of the generated SDP.


On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlund &= lt;magnus.westerlund@ericsson.com> wrote:
On 2013-09-17 10:47, Harald Alvestrand wrote:
> Magnus,
>
> what is the expected duration of the call?

2 hour maximum

Magnus

>
> On 09/17/2013 10:38 AM, Magnus Westerlund wrote:
>> WG,
>>
>> I know that the new JSEP Draft is not yet submitted. I am hoping t= hat it
>> will show up during the morning hours for the US based people. Tha= t way
>> everyone gets at least some few hours to look at the draft prior t= o the
>> call. If it hasn't we will postpone the call, but I really hop= e we can
>> avoid this. I will send a notice to the WG if we have to postpone = it.
>>
>> Cheers
>>
>> Magnus
>>
>> On 2013-09-11 07:58, Magnus Westerlund wrote:
>>> WG,
>>>
>>> There will be a new version of JSEP draft coming out Monday. A= s a follow
>>> up to get as much progress on this topic as possible. The chai= rs and
>>> authors are offering a informal walk through session on Wednes= day the
>>> 18th. People will be strongly recommended to have reviewed the= new
>>> draft.
>>>
>>> The intention of the session is enable the authors to inform y= ou about
>>> the latest changes, any issues to consider and what needs furt= her
>>> discussion. The will also enable you as participant after your= review of
>>> the document to ask clarifying questions or for motivations be= hind
>>> choices, and raise issues you have spotted.
>>>
>>> The session is not intended to solve issues or judge consensus= on part
>>> of the draft. Discussions of what is the best solution etc, wi= ll to be
>>> cut off.
>>>
>>> This will be a webex conference per details below.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>> Topic: RTCWeb - JSEP
>>> Date: Wednesday, September 18, 2013
>>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00= )
>>> Meeting Number: 302 061 238
>>> Meeting Password: ietf
>>>
>>> -------------------------------------------------------
>>> To join the online meeting (Now from mobile devices!)
>>> -------------------------------------------------------
>>> 1. Go to
>>> ht= tps://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW=3D= NYjk4NmE0ODBj&RT=3DMiM0
>>>
>>>
>>> 2. Enter your name and email address.
>>> 3. Enter the meeting password: ietf
>>> 4. Click "Join Now".
>>>
>>> To view in other time zones or languages, please click the lin= k:
>>> h= ttps://cisco.webex.com/ciscosales/j.php?ED=3D206400898&UID=3D0&PW= =3DNYjk4NmE0ODBj&ORT=3DMiM0
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> To join the teleconference only
>>> -------------------------------------------------------
>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at >>> http://cisco.com/en/US/about/doing_busi= ness/conferencing/index.html
>>> 2. Follow the prompts to enter the Meeting Number (listed abov= e) or
>>> Access Code followed by the # sign.
>>>
>>> San Jose, CA: +1.408.525.6800 RT= P: +1.919.392.3330
>>>
>>> US/Canada: +1.866.432.9903 Unite= d Kingdom: +44.20.8824.0117
>>>
>>> India: +91
--001a11c2b01c4857ef04e6a77ad1-- From magnus.westerlund@ericsson.com Wed Sep 18 05:46:46 2013 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 A76FC11E8292 for ; Wed, 18 Sep 2013 05:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.633 X-Spam-Level: X-Spam-Status: No, score=-105.633 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DokSx4bw2NVs for ; Wed, 18 Sep 2013 05:46:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2011E8293 for ; Wed, 18 Sep 2013 05:46:24 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-f7-5239a09ea3b0 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5A.79.03802.E90A9325; Wed, 18 Sep 2013 14:46:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.328.9; Wed, 18 Sep 2013 14:46:21 +0200 Message-ID: <5239A0E9.7@ericsson.com> Date: Wed, 18 Sep 2013 14:47:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C4A6A20@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A6A20@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje68BZZBBudWq1lsnSpksfZfO7sD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKWHJyOmvBVe6KWffWsTYwrubsYuTkkBAwkbj8 uZsJwhaTuHBvPVsXIxeHkMBhRokpC/sYIZzljBITft1jA6niFVCVWLDyIVgHC5B9/Md8sDib gIXEzR+NYLaoQLBE+/avUPWCEidnPmEBsUUEzCSuf+4F62UW8Jb4tOgBO4gtLJAqsXD/D6hl E5kkGg8/BWvgFPCTWDnjNiPEeZIS2xYdY4do1pRo3f4bypaXaN46mxnEFhLQlmho6mCdwCg0 C8nuWUhaZiFpWcDIvIqRPTcxMye93GgTIzBUD275rbqD8c45kUOM0hwsSuK8m/XOBAoJpCeW pGanphakFsUXleakFh9iZOLglGpgnB9zi1eR/c3+hU+rripu+na8fsEbt/27o49X152MyJ2x On7ptdeLt53atjH73pVFT+IbJaKWrDYX8F1VGvXs5HQhZ/+iOe8uXJh6Ov3dhUre1aeffv2W vGzd1RNhNzgc1t532OmyZEPeXeWym/7Heg+lpzekeE2uPVv15LBoYNuf+qKr9v6nJzcpsRRn JBpqMRcVJwIA70O7hCMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 18 Sep 2013 12:46:46 -0000 On 2013-09-18 12:50, Christer Holmberg wrote: > Hi, > > > > I may not be able to attend the phone meeting today, so I send my input > by the e-mail. > > > > As requested by the WG chairs, I’ll focus on *clarification > issues/questions*, and will for now not repeat the issues I have with > pranswer and forking (also, we may have found a way forward to solve that). A point of clarification. In the phone conference we will focus getting understanding for JSEP for the participants so that you all can provide comments, feedback and bring proposals for improvements. It is also okay to ask about technical issues. But in the interest of time I think we need to focus on exposing and understanding potential issues, not solving them. All type of issues are fine to contribute on the list and towards the authors. However, I would recommend to use another thread than this one. Create a new thread or follow up on the I-D announcement for the version you are commenting on. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Wed Sep 18 05:54:47 2013 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 9E1A211E8298 for ; Wed, 18 Sep 2013 05:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku+Mtb4+cIGp for ; Wed, 18 Sep 2013 05:54:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5163F11E82A8 for ; Wed, 18 Sep 2013 05:54:11 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-46-5239a27107ea Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.5A.03802.172A9325; Wed, 18 Sep 2013 14:54:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Wed, 18 Sep 2013 14:54:09 +0200 From: Christer Holmberg To: Magnus Westerlund Thread-Topic: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) Thread-Index: AQHOrrQWfRliQImOMU+QwmqTVLuQyJnJg4YAgAACuACAAADsAIAA5ImAgADXzPCAABgTgIAAIh6A Date: Wed, 18 Sep 2013 12:54:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A6FE6@ESESSMB209.ericsson.se> References: <523006A3.4020907@ericsson.com> <523814EE.2080205@ericsson.com> <52381736.5000709@alvestrand.no> <523817FC.80406@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1C4A6A20@ESESSMB209.ericsson.se> <5239A0E9.7@ericsson.com> In-Reply-To: <5239A0E9.7@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+JvjW7RIssgg/6fghZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyTpzeyVqwSrzi3dK5rA2Md8S6GDk4JARMJF5P qO9i5AQyxSQu3FvP1sXIxSEkcJhR4mL/bhYIZwmjxLut89hAGtgELCS6/2mDNIgImEk8nLCf DcRmFvCW+LToATuILSyQKjHx11RWiJo0idlTD7ND2FESi+52gdksAqoSe/btYgKxeQV8JSa9 P8UKsWszk8S6bdeZQRKcAmoSm5pPgg1iBLru+6k1TBDLxCVuPZnPBHG1gMSSPeeZIWxRiZeP /7FCPKYosbxfDsRkFtCUWL9LH6JTUWJK90N2iLWCEidnPmGZwCg2C8nQWQgds5B0zELSsYCR ZRUje25iZk56udEmRmBkHNzyW3UH451zIocYpTlYlMR5N+udCRQSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAKHT9UPOJF15HdMPsP7jmd7jPcShQVfeJblm87OUpzSe1LZ5vps8N+rt/g9J3 k9y8TzZapgenqLWwqAqvcHr9eU63nc7HdCUL8TMtdXwXLu/b9LD/hsJxBe4whtrNsi4hm1nL v34/bqvKztolcHTj3c41Je224nIullvXPlBK3H7babuXipadEktxRqKhFnNRcSIAMJvh3VoC AAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT) 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, 18 Sep 2013 12:54:47 -0000 SGksDQoNCkJhc2VkIG9uIHNvbWUgcHJpdmF0ZSBkaXNjdXNzaW9ucyB3aXRoIEN1bGxlbiBhbmQg SnVzdGluLCBJIHRoaW5rIHRoZXJlIGlzIGEgd2F5IGZvcndhcmQgcmVnYXJkaW5nIHByYW5zd2Vy IGFuZCBmb3JraW5nLg0KDQpTb21lIG9mIHRob3NlIGlkZWFzIGFyZSBhbHJlYWR5IHByZXNlbnRl ZCBpbiB0aGUgZHJhZnQgKHVzaW5nIHNlcGFyYXRlIFBlZXJDb25uZWN0aW9ucyBmb3IgZWFjaCBm b3JrZWQgbGVnIGV0YykuIEJ1dCwgdGhlcmUgYXJlIGRldGFpbHMgdGhhdCBuZWVkIHRvIGJlIHNv cnRlZCBvdXQsIGFuZCBJIGRvbid0IHRoaW5rIHRoaXMgbWVldGluZyBpcyBhcHByb3ByaWF0ZSB0 byBkaXNjdXNzIHRob3NlIC0gZXNwZWNpYWxseSB3aGVuIEkgbWF5IG5vdCBldmVuIGJlIGFibGUg dG8gYXR0ZW5kIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgDQpTZW50OiAxOC4gc3l5c2t1 dXRhIDIwMTMgMTU6NDgNClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IEp1c3RpbiBVYmVydGk7 IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEpTRVAgV2FsayBUaHJvdWdo IG9uIFdlZG5lc2RheSB0aGUgMTh0aCBvZiBTZXB0ZW1iZXIgYXQgMTcuMDAgQ0VTVCAoOCBBTSBQ RFQpDQoNCk9uIDIwMTMtMDktMTggMTI6NTAsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBI aSwNCj4gDQo+ICANCj4gDQo+IEkgbWF5IG5vdCBiZSBhYmxlIHRvIGF0dGVuZCB0aGUgcGhvbmUg bWVldGluZyB0b2RheSwgc28gSSBzZW5kIG15IA0KPiBpbnB1dCBieSB0aGUgZS1tYWlsLg0KPiAN Cj4gIA0KPiANCj4gQXMgcmVxdWVzdGVkIGJ5IHRoZSBXRyBjaGFpcnMsIEnigJlsbCBmb2N1cyBv biAqY2xhcmlmaWNhdGlvbiANCj4gaXNzdWVzL3F1ZXN0aW9ucyosIGFuZCB3aWxsIGZvciBub3cg bm90IHJlcGVhdCB0aGUgaXNzdWVzIEkgaGF2ZSB3aXRoIA0KPiBwcmFuc3dlciBhbmQgZm9ya2lu ZyAoYWxzbywgd2UgbWF5IGhhdmUgZm91bmQgYSB3YXkgZm9yd2FyZCB0byBzb2x2ZSB0aGF0KS4N Cg0KQSBwb2ludCBvZiBjbGFyaWZpY2F0aW9uLg0KDQpJbiB0aGUgcGhvbmUgY29uZmVyZW5jZSB3 ZSB3aWxsIGZvY3VzIGdldHRpbmcgdW5kZXJzdGFuZGluZyBmb3IgSlNFUCBmb3IgdGhlIHBhcnRp Y2lwYW50cyBzbyB0aGF0IHlvdSBhbGwgY2FuIHByb3ZpZGUgY29tbWVudHMsIGZlZWRiYWNrIGFu ZCBicmluZyBwcm9wb3NhbHMgZm9yIGltcHJvdmVtZW50cy4NCg0KSXQgaXMgYWxzbyBva2F5IHRv IGFzayBhYm91dCB0ZWNobmljYWwgaXNzdWVzLiBCdXQgaW4gdGhlIGludGVyZXN0IG9mIHRpbWUg SSB0aGluayB3ZSBuZWVkIHRvIGZvY3VzIG9uIGV4cG9zaW5nIGFuZCB1bmRlcnN0YW5kaW5nIHBv dGVudGlhbCBpc3N1ZXMsIG5vdCBzb2x2aW5nIHRoZW0uDQoNCkFsbCB0eXBlIG9mIGlzc3VlcyBh cmUgZmluZSB0byBjb250cmlidXRlIG9uIHRoZSBsaXN0IGFuZCB0b3dhcmRzIHRoZSBhdXRob3Jz LiBIb3dldmVyLCBJIHdvdWxkIHJlY29tbWVuZCB0byB1c2UgYW5vdGhlciB0aHJlYWQgdGhhbiB0 aGlzIG9uZS4NCkNyZWF0ZSBhIG5ldyB0aHJlYWQgb3IgZm9sbG93IHVwIG9uIHRoZSBJLUQgYW5u b3VuY2VtZW50IGZvciB0aGUgdmVyc2lvbiB5b3UgYXJlIGNvbW1lbnRpbmcgb24uDQoNCkNoZWVy cw0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNdWx0aW1lZGlhIFRlY2hu b2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nz b24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCkbDpHLDtmdhdGFu IDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9j a2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0K From fluffy@cisco.com Wed Sep 18 09:01:23 2013 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 16D0F11E8256 for ; Wed, 18 Sep 2013 09:01:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFN+d5VJ695e for ; Wed, 18 Sep 2013 09:01:17 -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 5263011E8241 for ; Wed, 18 Sep 2013 09:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=149; q=dns/txt; s=iport; t=1379520077; x=1380729677; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dAfZIL0ULD8a4a21RfARLBK5PBA01+MjkZ8eotjzeAw=; b=mE8edtxy1bNRd9QNm6ySa8RLs7OENNlI1v2e7r1oZuLzf8r+nG96sSdh VBP/gQjfmSzjV2S4K0J1ov9fvxr56mYDtHGYCRWYNi8/GTZ+2hX1vfVkF DdYj754S81aLU9Ypb20kQnicj3WHXSAdzJmix9HuHcXYnBq2UGHQKsrgB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAB7NOVKtJV2a/2dsb2JhbABagweBCsEogRsWbQeCJwEEOlEBKhRCHwgEG4d7mTqhFY82g1aBAAOpb4Mkgio X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208";a="261461303" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Sep 2013 16:01:17 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8IG1GsN021425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Sep 2013 16:01:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 11:01:16 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: how to control which track plays in a video tag Thread-Index: AQHOtIhOOpUr/Q4ArEy2Io6hryUdFQ== Date: Wed, 18 Sep 2013 16:01:16 +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.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <467E1794F6B63746BA375ADC1AF2C402@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] how to control which track plays in a video tag 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, 18 Sep 2013 16:01:23 -0000 The issue got raised if there is multiple video tracks in a media stream, h= ow do you control which video track gets played in a video stream = From fluffy@cisco.com Wed Sep 18 09:04:42 2013 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 22DB011E8228 for ; Wed, 18 Sep 2013 09:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCaLxXwRsSRV for ; Wed, 18 Sep 2013 09:04:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4241811E8124 for ; Wed, 18 Sep 2013 09:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=180; q=dns/txt; s=iport; t=1379520276; x=1380729876; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JjKs8RdF4dxeUTyQV21DJTmHvQoCUWwWbG9owUEQw0Y=; b=Ge5gJyQ2w6QHjk4dp45L8eJPzOn+B0euEV/bw3N0d9o0u0M7DW2I3edQ eP8o2lqCs0LUOXrAZeQlc1fO9F6lnAswVx+4fR1bGx26LwyXCgFRyIAQE P+utFyaGNsvVUVjGduZBwh7wqRvmmQIozvd2IDxVdscXLpsGGoXvLVsi5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlANABvOOVKtJV2b/2dsb2JhbAA5IYMHgQrBKIEbFm0HgicBBDpRASoUQicEG4d7mTOhFY82g1aBAAOpb4Mkgio X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208";a="261433027" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 18 Sep 2013 16:04:35 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8IG4ZL6016899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Sep 2013 16:04:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 11:04:35 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Constraints on a track in a a given PC Thread-Index: AQHOtIjEGxzkFUWDV069BEQnoi2xQw== Date: Wed, 18 Sep 2013 16:04:35 +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.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <462C3C7B7351A44987A5A907AD30885C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Constraints on a track in a a given PC 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, 18 Sep 2013 16:04:42 -0000 It would be nice to have a way specify constraints to a given track on a pe= er connection. For example, like to be able specify if a track should be bu= ndle only or not.=20 From suhasietf@gmail.com Wed Sep 18 09:30:37 2013 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 143D421F944C for ; Wed, 18 Sep 2013 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-SN2gjMtgvE for ; Wed, 18 Sep 2013 09:30:36 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3652421F9433 for ; Wed, 18 Sep 2013 09:30:36 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id ex4so6754014wid.14 for ; Wed, 18 Sep 2013 09:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MtEVWOQVEkEIagna820uicy0RX8hc+BWNW60zvW8IM0=; b=pdwWoqJ8aaw1dUkpcm4CFhAVv7jNK8q9/o1fvPiQgbR2Siy9stfhWtNITIYXoO3vyv FOEq9onb3g4INezLignTnESmpDdMLmAf7kGJ2gFrhguKMIppCD01zTgEIqMcJN8sZYBa x13hxKg6lK9P/IhIhese3CnfTSx3kh8ajA9LPlLnpHTjvaiviVtlUmlFlWU5Bvsear4A 7alKn1NEzRuwr/UKaZRhVos0oRGe4OBPV/EPFhiDS69UgcbVH8RH3aCdtfLTsmoJ7M0J fvo1ZGgIZsiaIonFX0wAvSKFv7UHtYu2AZIN3luLC+64zAj/CkGvxO4K++W0IcEdD5lv FZnw== MIME-Version: 1.0 X-Received: by 10.180.73.65 with SMTP id j1mr7945534wiv.10.1379521835369; Wed, 18 Sep 2013 09:30:35 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Wed, 18 Sep 2013 09:30:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Sep 2013 09:30:35 -0700 Message-ID: From: Suhas Nandakumar To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=f46d04389087f5095904e6aaf47b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraints on a track in a a given PC 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, 18 Sep 2013 16:30:37 -0000 --f46d04389087f5095904e6aaf47b Content-Type: text/plain; charset=ISO-8859-1 +1 On Wed, Sep 18, 2013 at 9:04 AM, Cullen Jennings (fluffy) wrote: > > It would be nice to have a way specify constraints to a given track on a > peer connection. For example, like to be able specify if a track should be > bundle only or not. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d04389087f5095904e6aaf47b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1=A0


On Wed, Sep 18, 2013 at 9:04 AM, Cullen Jennings (fluffy) = <fluffy@cisco.com> wrote:

It would be nice to have a way specify constraints to a given track on a pe= er connection. For example, like to be able specify if a track should be bu= ndle only or not.


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

--f46d04389087f5095904e6aaf47b-- From suhasietf@gmail.com Wed Sep 18 09:32:26 2013 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 CEF4F21F967A for ; Wed, 18 Sep 2013 09:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gsD0JGMg6iy for ; Wed, 18 Sep 2013 09:32:25 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5F21F9360 for ; Wed, 18 Sep 2013 09:32:24 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so6694654wib.1 for ; Wed, 18 Sep 2013 09:32:24 -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=2+sJbOpuvT4q76F8Qa0w96sext1rJHUWkNEjUxPlkqQ=; b=gaMfhxT00qDhdXHsqghQG4SIQTWAqiZYtT6VeUKkLL/n9mSTZjRHC+tRC8OHDiwZcr ZnN2BnN/OhMFzskYWS5ghiEGU/EVYJyiVzHljdyCP2WaZnvMX2ijeUxCGhrtlWTS5/WY f/thKXPmeASH++j8Iy38HAo4ZYzH1WYuP05+CAzf1Q/5l0YsFctnYsHbva51Nhhab8tx RvZf7KVg/38bNgKrl51coO8gn8PE0fRN3ZpUvTQ7p7lcIiAEHG927rTqh1WS6jXeXMql kOTmfc+wHIK4oU5yhf2M5QICtRHsldxZTVMnB76vfA7IBjVrkmgkEsNHxP33cmFYyesB 0fdw== MIME-Version: 1.0 X-Received: by 10.194.77.2 with SMTP id o2mr2163779wjw.57.1379521943942; Wed, 18 Sep 2013 09:32:23 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Wed, 18 Sep 2013 09:32:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Sep 2013 09:32:23 -0700 Message-ID: From: Suhas Nandakumar To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7bfced9c6dbb8204e6aafb92 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] how to control which track plays in a video tag 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, 18 Sep 2013 16:32:26 -0000 --047d7bfced9c6dbb8204e6aafb92 Content-Type: text/plain; charset=ISO-8859-1 Shouldn't this be dealt with a W3C API, say videoelem.src = mediastream.trackAt(0) On Wed, Sep 18, 2013 at 9:01 AM, Cullen Jennings (fluffy) wrote: > > The issue got raised if there is multiple video tracks in a media stream, > how do you control which video track gets played in a video stream > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bfced9c6dbb8204e6aafb92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Shouldn't this be dealt with a W3C API, say videoelem.= src =3D mediastream.trackAt(0)=A0


<= div class=3D"gmail_quote">On Wed, Sep 18, 2013 at 9:01 AM, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

The issue got raised if there is multiple video tracks in a media stream, h= ow do you control which video track gets played in a video stream
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bfced9c6dbb8204e6aafb92-- From suhasietf@gmail.com Wed Sep 18 09:44:05 2013 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 B0C6711E8273 for ; Wed, 18 Sep 2013 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbw-KlE4pqos for ; Wed, 18 Sep 2013 09:44:05 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 075C011E826E for ; Wed, 18 Sep 2013 09:44:04 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so6626556wgh.26 for ; Wed, 18 Sep 2013 09:44:04 -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=EpY8t2+aOQjdBXlG5FTbDo4t2LqsB0W59p13q1CYYXU=; b=FqRyzGUxjKEtUl6j1Gg2G7cX0zpff8CTn5c0CTRGnY8hA20syuw9ENcpVBx/CZUpvt +GYBoLO7Jy6kWEPa/jL7FQtF7/YijIPmkadWWNyhBKNBtB9wFL3U9H79cIJw0jjtxicX OvMjbCkMpCRTvFIcXQ//ZHYBWlMkFHAdwuNtgMtt/qgRo+eSPxSxXZFLxu4j9D4AX1II mwgq+IcsmteExq9aPw9IH22Do8J4TahE41ez6A4R3FjPbPbe4WafZJPEMBYi0CZjJ8uK fCwQ9p5T7OBZP/jpgghMWIbAHFvbW7qcRVWpuEJqHd5rMf9iE+nnKpJVoJz9Eqr/gDp5 KGOQ== MIME-Version: 1.0 X-Received: by 10.194.77.2 with SMTP id o2mr2209790wjw.57.1379522644148; Wed, 18 Sep 2013 09:44:04 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Wed, 18 Sep 2013 09:44:04 -0700 (PDT) Date: Wed, 18 Sep 2013 09:44:04 -0700 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfced9c2a08e704e6ab25a3 Subject: [rtcweb] m=section recycling and a=mid 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, 18 Sep 2013 16:44:05 -0000 --047d7bfced9c2a08e704e6ab25a3 Content-Type: text/plain; charset=ISO-8859-1 After thinking about it a bit, I think there are some side effects associated with changing/not changing mid attribute of a re-cycled m= section and it being part of a BUNDLE group or not.. example say , we have these video m=section part of BUNDLE group as below a=group:BUNDLE 1, 2 m=video ..... a=mid:1 a=inactive m=video ..... a=mid:2 a=sendrecv Now If JS user adds a new video track and he wants it to be out of BUNDLE. If we recycle first video m=section and dont change mid attribute, we end up BUNDLing even if the user dint want to On the other hand, if we allowed mid value to be changed, we might end up UNBundling a video stream , when the user did want to BUNDLE them So allowing a mid value to be changed or not should be tied to what the JS API is asking on behalf of the user Any thoughts ? Cheers Suhas --047d7bfced9c2a08e704e6ab25a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After thinking about it a bit, I think there are some side= effects associated with changing/not changing mid attribute of a re-cycled= m=3D section and it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part= of BUNDLE group as below=A0
a=3Dgroup:BUNDLE 1, 2

=
m=3Dvideo .....
a=3Dmid:1=A0
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2=A0
a=3Dsendre= cv

Now If JS user adds a new video track and he wa= nts it to be out of BUNDLE. If we recycle first video m=3Dsection and dont = change mid attribute, =A0we end up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be change= d, we might end up UNBundling a video stream , when the user did want to BU= NDLE them

So allowing a mid value to be changed or= not should be tied to what the JS API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas


--047d7bfced9c2a08e704e6ab25a3-- From fischman@google.com Wed Sep 18 09:53:36 2013 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 AEC6211E8228 for ; Wed, 18 Sep 2013 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLgUgd5PCVXW for ; Wed, 18 Sep 2013 09:53:36 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8717811E8241 for ; Wed, 18 Sep 2013 09:53:35 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z12so6888671wgg.22 for ; Wed, 18 Sep 2013 09:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tIBAlGcoRJjaGPE/3rwZ2KfrY0d9DKAGsfa8YG6o9Vw=; b=Skgm04sEoKll7HssAy+XzKVKSAqeE83dlBcLEYqNLDO34U7p7TrU4bMZNnUjzawWXj iHfaqSgCbGFCjmZZ6hWhENq1LdGHA1HBMEuaoON2kbaBZYWXTPBe8wr4bZsGOLjNlm3i arOD8TSKoTpxRME48jeBR3tv8L1EFqbO+FcKbdIaxd8tyBJnUzMhO0/ckPpYZyW84x73 bIPlUzSdxmno2hjA5rZNymyF2JYJB7RyMTcxnlt7HTsVIjuzIcItsMAoMo/LtGdY52y1 iBkfHnKGVuXarAf0S0fXkpCPVKaHSAetHkJ3wA6M/W3GAxOFXYVUPSolIRbBPqjra8+W bldw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tIBAlGcoRJjaGPE/3rwZ2KfrY0d9DKAGsfa8YG6o9Vw=; b=T/9R8j8ZFu+6xEkIjYImUTuiSIeg4/wqvgk/cbdUgoNM1cPhCOAuX1XFPzN/m5HpG8 iNswmUW8zQzpopE3U7aG/eHPSmSOqcXKJ1bDqGeMzQ6Hrhe5BtsS88CsBeJKx7xDgeAQ 0SEeB5U/LLRHFTh6l1mw9JhreRVl5zTsfXzzJsAtlv3KqeVdgdk2GeCSnPUm5K3E3dAD Hs7Lb6jl2YjLj7w+EQvTvISaTW/uKSN5yEDfeqfVU1EQ7WDTwPiiFsGtB1hGXJ1cHDYC LfOWLWUUiX7x397Q5wWdT6MvrRLRm98WktvGJAwCutE+NFkVjDm2KZj13KdXx/esZ+YA LxZw== X-Gm-Message-State: ALoCoQn7v6XUrW5Hr3kOkISR6XzBomvW96/kmKeNoprk7dBfmYZSvYy8pDOpNFDDL7Lp5b4shRxN3+eKwBI28rOC1w3oZIDxhdGpFekHzOveihVFy+y/CLfqi1lpZVNiyFV+dSUXFKux7SIHOCiDmHAMiCtK+k1NSMi5m1s+Moc2FqXBOAQVfX6wQMcR74iKgGb8c27bF2dn MIME-Version: 1.0 X-Received: by 10.180.206.244 with SMTP id lr20mr7844209wic.45.1379523214528; Wed, 18 Sep 2013 09:53:34 -0700 (PDT) Received: by 10.194.86.68 with HTTP; Wed, 18 Sep 2013 09:53:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Sep 2013 09:53:34 -0700 Message-ID: From: Ami Fischman To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11c381222964dc04e6ab477f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] how to control which track plays in a video tag 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, 18 Sep 2013 16:53:36 -0000 --001a11c381222964dc04e6ab477f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 18, 2013 at 9:01 AM, Cullen Jennings (fluffy) wrote: > > The issue got raised if there is multiple video tracks in a media stream, > how do you control which video track gets played in a video stream > Set the selectedattribute on a VideoTrackfrom HTMLMediaElement.videoTracks ? (though I don't know that it's implemented in any shipping browser today; e.g. crbug.com/249427) Cheers, -a --001a11c381222964dc04e6ab477f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 18, 2013 at 9:01 AM, Cullen Jennings (fluffy) <= ;flu= ffy@cisco.com> wrote:
The issue got raised if there is multiple video tracks in a media stream, h= ow do you control which video track gets played in a video stream

Set the selected attribute on a VideoTrack from=A0= HTMLMediaElement.videoTracks?
(though I don't know that it's implemented in any shipping browser = today; e.g.=A0crbug.co= m/249427)

Cheers,
-a
--001a11c381222964dc04e6ab477f-- From fluffy@iii.ca Wed Sep 18 10:50:11 2013 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 5FE0721F9FCA for ; Wed, 18 Sep 2013 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtOMbW-pTib4 for ; Wed, 18 Sep 2013 10:49:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E389921F9FF1 for ; Wed, 18 Sep 2013 10:49:54 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5DC0450AA4 for ; Wed, 18 Sep 2013 13:49:51 -0400 (EDT) From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_FB2B5D6E-EB9D-41C4-B6EA-3E3492BFAD5E" Date: Wed, 18 Sep 2013 11:49:49 -0600 References: <567034116.316661379523643187.JavaMail.nobody@rsj6rmd002.webex.com> To: "rtcweb@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [rtcweb] Recording from todays call 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, 18 Sep 2013 17:50:12 -0000 --Apple-Mail=_FB2B5D6E-EB9D-41C4-B6EA-3E3492BFAD5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >=20 > Your recording is now available on the WebEx service site. Click the = link below to play it:=20 >=20 > = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D71503827&= rKey=3D2cb05592aa7be2c2=20 >=20 > RTCWeb - JSEP-20130918 1508-1=20 > Wednesday, September 18, 2013 8:08 am San Francisco Time=20 > 1 Hour 49 Minutes=20 >=20 --Apple-Mail=_FB2B5D6E-EB9D-41C4-B6EA-3E3492BFAD5E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii


Your recording is now available on the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71503827&rKey=2cb05592aa7be2c2

RTCWeb - JSEP-20130918 1508-1
Wednesday, September 18, 2013 8:08 am San Francisco Time
1 Hour 49 Minutes



--Apple-Mail=_FB2B5D6E-EB9D-41C4-B6EA-3E3492BFAD5E-- From partha@parthasarathi.co.in Wed Sep 18 11:30:33 2013 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 B2D0111E8121 for ; Wed, 18 Sep 2013 11:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZmyCOdoX2+s for ; Wed, 18 Sep 2013 11:30:29 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id 521DA11E8119 for ; Wed, 18 Sep 2013 11:30:26 -0700 (PDT) Received: from userPC (unknown [122.179.38.24]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BFDAE638C04; Wed, 18 Sep 2013 18:30:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1379529020; bh=BdJvt7yjsDqIToq0WHVpFCgHYbR4uSMc6qXMXCDpkyQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KCu0L3FqLhv4RGvQduofxIw8urLn3Sd+GIuDSb1fVmfEl7OfCpyPrCZy6aod0A3em /Weu2knx2KQGZgetdhA4yNM5ZRRHRVD0AMTbUPIEkAoK07FQpNDSJ8HD9nFwJlC3xc z6gVuRwJBSB1YtLyWMV+N3WYsUddHhezmv7VFxS0= From: "Parthasarathi R" To: "'Cullen Jennings \(fluffy\)'" , References: <20130917222328.25460.80088.idtracker@ietfa.amsl.com> In-Reply-To: <20130917222328.25460.80088.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 00:00:12 +0530 Message-ID: <00ce01ceb49d$20953e80$61bfbb80$@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: Ac6z9I7UOQbCdRAuQQ2/rqK4+9Mr5QApNc4Q Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.5239F13C.008C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: rtcweb@ietf.org Subject: [rtcweb] Missing Offer event handling in Pranswer state [was RE: I-D Action: draft-ietf-rtcweb-jsep-04.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, 18 Sep 2013 18:30:33 -0000 Hi Cullen/Justin, Unfortunately, I could not attend today's JSEP Walk through meeting. I had gone through the draft to understand Offer event handling in Pranswer state which I raised long back (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08589.html) and no resolution in the updated draft as well. Currently in JSEP state machine, OFFER event is not possible to be handled at Local-Pranswer, Remote-Pranswer state. OFFER event is required in local-pranswer for multiple offer/answer handling like BUNDLE, ICE negotiations. The example callflow for early-dialog with multiple offer/answer handling (parallel forking) is available at Sec 5.2 of draft-partha-rtcweb-jsep-sip-00. It is open item in JSEP. Please let me know your opinion on the same. Thanks Partha > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 18, 2013 3:53 AM > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB- > browsers Working Group of the IETF. > > Title : Javascript Session Establishment Protocol > Author(s) : Justin Uberti > Cullen Jennings > Filename : draft-ietf-rtcweb-jsep-04.txt > Pages : 46 > Date : 2013-09-17 > > Abstract: > This document describes the mechanisms for allowing a Javascript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From basilgohar@librevideo.org Wed Sep 18 11:32:23 2013 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 2035A11E810B for ; Wed, 18 Sep 2013 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfFBkirwL7Xn for ; Wed, 18 Sep 2013 11:32:18 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id DA55C11E80F6 for ; Wed, 18 Sep 2013 11:32:17 -0700 (PDT) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (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 08743658806 for ; Wed, 18 Sep 2013 14:32:16 -0400 (EDT) Message-ID: <5239F1AD.8010301@librevideo.org> Date: Wed, 18 Sep 2013 14:32:13 -0400 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5238A564.2070601@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Video Codec Selection Plan 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, 18 Sep 2013 18:32:23 -0000 I was thinking if we're going to go with an older, non-IPR-encumbered codec, Theora is the obvious choice, because it's been around about as long as anything currently in use and has never had it's IPR seriously challenged. The encoder is being actively developed and has long since surpassed pretty-much everything aside from H.264 and VP8 that are in common use nowadays. The fact that it takes much less CPU time to decode compared with other modern codecs is also a plus. Theora is also used in Elphel camera devices, so it's been used in hardware as well (granted, those are not "burned-in-silicon" devices). Efficiency wise, for talking-head scenarios (a common use case), I think Theora will likely do quite well. On 09/18/2013 04:49 AM, Monty Montgomery wrote: > I'll see your h.261 and raise one Theora. At least it has one hell of > an encoder. > > Cheers, > Monty > > On Wed, Sep 18, 2013 at 4:39 AM, Leon Geyser wrote: >> Anyone willing to create a draft for H.261? >> >> >> On 18 September 2013 02:13, Eric Rescorla wrote: >>> >>> >>> >>> >>> On Tue, Sep 17, 2013 at 11:54 AM, cowwoc wrote: >>>> >>>> Hi Ted, >>>> >>>> Seeing as this discussion stems from licensing concerns, I like to >>>> propose the following alternative: >>>> >>>> Mandate a video codec whose IPR has expired. I agree that video quality >>>> will degrade, which brings me to the next point. >>>> Provide a negotiation mechanism which would allow peers to "upgrade" to a >>>> superior (optionally-implemented) video codec. >>> >>> Negotiation has always been part of the design. The sole question is which >>> codec is mandatory to implement, not which is the sole codec to be >>> mandated. >>> >>> -Ekr >>> >>> >>>> This will allow us to support VP8, VP9, H264, H265 or whatever other >>>> codec people like without the fear of transcoding or IPR. I believe that in >>>> most cases negotiation will succeed in upgrading to a superior codec. It >>>> will also encourage (as opposed to force) vendors to support each other's >>>> codecs, which is the right way to go in light of the political nature of >>>> this decision. >>>> >>>> Gili >>>> >>>> >>>> 1. If you support H.264 as the mandatory to implement codec or are >>>> willing to live with it as the MTI, please raise your hand now. >>>> >>>> 2. If you support VP8 as the mandatory to implement codec or are >>>> willing to live with it as the MTI, please raise your hand now. >>>> >>>> >>>> Gili >>>> >>>> >>>> On 13/09/2013 12:52 PM, Ted Hardie wrote: >>>> >>>> WG, >>>> >>>> The chairs have created a plan for how to perform the Video Codec >>>> selection in our WG. The chairs are asking for review of our plan on >>>> how to undertake the mandatory-to-implement video codec selection. >>>> We'd much prefer to have comments on the mechanics before they begin, >>>> so please review now. Proponents of a particular proposal should >>>> note both the actions required and the timelines proposed. >>>> >>>> The main goal of this plan is to hold a consensus call on which of >>>> the proposed alternatives we as a WG should select at one of the WG >>>> sessions in Vancouver. Such a consensus call will of course be >>>> verified on the mailing list for anyone who can't participate. The >>>> chairs will recuse themselves from judging this particular >>>> consensus. >>>> >>>> In the WG session each codec proposal will be allowed an equal amount >>>> of time to highlight the arguments for their proposal. After that a >>>> there will be a slot for discussion and clarifying questions. >>>> >>>> To enable the WG participants to get answers to any questions, the >>>> proposals in draft form and any supporting material MUST be made >>>> available by 6th of October. This is to ensure that the WG >>>> participants can verify or object to any claims or statements in >>>> the proposal material prior to the WG session. We chairs would really >>>> not like to see the proponents bring up new arguments at their >>>> presentation. Also the WG participants are expected to raise any >>>> arguments on the list ahead of time to enable the proponents to >>>> respond to such arguments. >>>> >>>> The proposed consensus questions will be of the following form: >>>> >>>> 1. If you support H.264 as the mandatory to implement codec or are >>>> willing to live with it as the MTI, please raise your hand now. >>>> >>>> 2. If you support VP8 as the mandatory to implement codec or are >>>> willing to live with it as the MTI, please raise your hand now. >>>> >>>> You may indicate support on both questions and we encourage you to do >>>> so if you can live with either, even if you have a preference for one >>>> over the other. >>>> >>>> Additional proposals than the previous ones are welcome, but must be >>>> submitted as draft and their proponents must notify the chairs no later >>>> than the 6th of October that they also have a candidate proposal. >>>> >>>> In case the WG fails to reach consensus we chairs propose that we use >>>> the alternative decision process as discussed in RFC3929. The method >>>> and its usage will be discussed on the list should the WG not >>>> establish consensus on a proposal for mandatory to implement video codec. >>>> >>>> regards, >>>> >>>> Magnus, Cullen, and Ted >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -- Libre Video http://librevideo.org From christer.holmberg@ericsson.com Thu Sep 19 03:08:34 2013 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 6A71D21F8517 for ; Thu, 19 Sep 2013 03:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4aX4R1rnn1i for ; Thu, 19 Sep 2013 03:08:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B9F5921F8CB4 for ; Thu, 19 Sep 2013 03:08:19 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a1-523acd128747 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D3.16.03802.21DCA325; Thu, 19 Sep 2013 12:08:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 12:08:17 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september) Thread-Index: Ac61H8SXeXXAffdpQLKis+JdCZjjDA== Date: Thu, 19 Sep 2013 10:08:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A77DBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja7QWasgg2VXJSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXRm/HA6aCp8EV2//dZm5gnOLR xcjJISFgInH36id2CFtM4sK99WxdjFwcQgKHGSWWX5zECOEsYZTYtf4uUxcjBwebgIVE9z9t kAYRAXWJyw8vgDUzC1RIrPm4GswWFvCRWHLtOBtETbDEoj1XGCFsPYm2O59YQWwWAVWJyau2 gdXwCvhKPJ61BCzOCHTE91NrmCBmikvcejKfCeI4AYkle84zQ9iiEi8f/2MFOUdCQFFieb8c iMkskC+xYIk0xERBiZMzn7BMYBSehWTQLISqWUiqIEp0JBbs/sQGYWtLLFv4mhnGPnPgMROy +AJG9lWM7LmJmTnp5UabGIGxcnDLb9UdjHfOiRxilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD4w6+Gzs9BQ6YK8spznpYyznnQkvCriUy7uLS+yqS7hy45j59V2/T3XVJ 2ekZK58dUHn98MnM3I9S13S/MEqn2UQe9p20j5/vzJz7e15oMAkzlC+Yf+f12Wmtnt27lspm sfWfXjK18+SNW5xZPLax15e1qTv33W+w+zTpWfm5zSnxhw5ZPMl+X6LEUpyRaKjFXFScCADH HZfnYwIAAA== Cc: "Cullen Jennings \(fluffy@cisco.com\)" Subject: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september) 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, 19 Sep 2013 10:08:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A77DBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.2.1: ----------------- Q_1: o- line initial value - deviation What is the reason for recommending a zero value in the init= ial Offer, when the RFC says SHOULD use an NTP format timestamp? I don't have any strong feelings, but in general: whenever we deviate from = the "base" SDP procedures I think we should justify why. Q_2: o- line initial value - forking When a new PeerConnection is created due to forking, the val= ue must be based (incremented) on the value associated with the "mother" Pe= erConnection, for which the initial Offer of the whole communication sessio= n was created. Q_3: RTP The text says: "The field MUST be set to "RTP/SAVPF". " But, that of course only applies to RTP based streams (not the data channel= ). Also, in general, it needs to be clear what information needs to be in e= very m- line, and what information is protocol specific. I would suggest to= have a "General" sub-section, a "RTP" sub-section, etc. Q_4: BUNDLE The text says: "If a m=3D section is not being bundled into another m=3D section, it MUST generate a unique set of ICE credentials and gather its own= set of candidates. Otherwise, it MUST use the same ICE credential= s and candidates that were used in the m=3D section that it is be= ing bundled into." As, when BUNDLE is used, the initial Offer will contain identical ICE candi= dates, does that mean that we will also include identical address informati= on in the initial Offer? I don't object to that - I just want to clarify, as it has impacts on the t= ext in the BUNDLE spec :) Section 5.2.2: ----------------- Q_5: Offer when in "local-offer" The text says: "If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meani= ng the PeerConnection is still in the "local-offer" state, the ste= ps for generating an initial offer should be followed," I don't understand this. Why would you create a new Offer while you are wai= ting for an Answer to the previously sent Offer? Also, when setRemote() is called, to which Offer does it apply? Q_6: BUNDLE We'll probably also need some text about BUNDLE. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4A77DBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.2.1:

-----------------

 

Q_1:      o- line <se= ss-version> initial value - deviation

 

What is the reason for recommending a <sess-versi= on> zero value in the initial Offer, when the RFC says SHOULD use an NTP= format timestamp?

 

I don’t have any strong feelings, but in gener= al: whenever we deviate from the “base” SDP procedures I think = we should justify why.

 

 

Q_2:      o- line <se= ss-version> initial value - forking

 

When a new PeerConnection is created due to forking,= the <sess-version> value must be based (incremented) on the value as= sociated with the “mother” PeerConnection, for which the initia= l Offer of the whole communication session was created.

 

 

Q_3:      RTP=

 

The text says:

 

“The <proto>= ; field MUST be set to "RTP/SAVPF". “

 

But, that of course only applies to RTP based stream= s (not the data channel). Also, in general, it needs to be clear what infor= mation needs to be in every m- line, and what information is protocol speci= fic. I would suggest to have a “General” sub-section, a “RTP” sub-section, etc.

 

 

Q_4:      BUNDLE

 

The text says:

 

“If a m=3D sectio= n is not being bundled into another m=3D section, it MUST

         &nb= sp;      generate a unique set of ICE credentials = and gather its own set of

         &nb= sp;      candidates.  Otherwise, it MUST use = the same ICE credentials and

         &nb= sp;      candidates that were used in the m=3D sec= tion that it is being bundled

         &nb= sp;      into.”

 

As, when BUNDLE is used, the initial Offer will cont= ain identical ICE candidates, does that mean that we will also include iden= tical address information in the initial Offer?

 

I don’t object to that – I just want to = clarify, as it has impacts on the text in the BUNDLE spec :)

 

 

Section 5.2.2:

-----------------

 

 

Q_5:      Offer when in = “local-offer”

 

The text says:

 

“If the initial o= ffer was applied using setLocalDescription, but an

         &nb= sp;      answer from the remote side has not yet b= een applied, meaning the

         &nb= sp;      PeerConnection is still in the "loca= l-offer" state, the steps for

         &nb= sp;      generating an initial offer should be fol= lowed,”

 

I don’t understand this. Why would you create = a new Offer while you are waiting for an Answer to the previously sent Offe= r?

 

Also, when setRemote() is called, to which Offer doe= s it apply?

 

 

Q_6:      BUNDLE

 

We’ll probably also need some text about BUNDL= E.

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4A77DBESESSMB209erics_-- From harald@alvestrand.no Thu Sep 19 05:34:56 2013 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 0FF7921F92C2 for ; Thu, 19 Sep 2013 05:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyJ5oltUHHUW for ; Thu, 19 Sep 2013 05:34:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D3F1B21F925A for ; Thu, 19 Sep 2013 05:34:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95F3539E1A6; Thu, 19 Sep 2013 14:34: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 yz0kPuuuzjRZ; Thu, 19 Sep 2013 14:34:48 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1] (unknown [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 89A5839E04F; Thu, 19 Sep 2013 14:34:48 +0200 (CEST) Message-ID: <523AEFBD.2030306@alvestrand.no> Date: Thu, 19 Sep 2013 14:36:13 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org, fluffy@iii.ca References: <567034116.316661379523643187.JavaMail.nobody@rsj6rmd002.webex.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060309000000090802080605" Subject: Re: [rtcweb] Recording from todays call 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, 19 Sep 2013 12:34:56 -0000 This is a multi-part message in MIME format. --------------060309000000090802080605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks - can someone place this recording on a website where I can get at it? Accessing this page requires Java, which only my non-work computer supports; my non-work computer is on IPv6, which leads me to a page that tells me (presumably) how to configure the Java runtime parameters on Windows, which I don't run (it wants -Djava.net.preferIPv6Addresses=true). I'm stuck. Help? On 09/18/2013 07:49 PM, Cullen Jennings wrote: > >> >> >> Your recording is now available on the WebEx service site. Click the >> link below to play it: >> >> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71503827&rKey=2cb05592aa7be2c2 >> >> >> RTCWeb - JSEP-20130918 1508-1 >> Wednesday, September 18, 2013 8:08 am San Francisco Time >> 1 Hour 49 Minutes >> > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060309000000090802080605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks - can someone place this recording on a website where I can get at it?

Accessing this page requires Java, which only my non-work computer supports; my non-work computer is on IPv6, which leads me to a page that tells me (presumably) how to configure the Java runtime parameters on Windows, which I don't run (it wants -Djava.net.preferIPv6Addresses=true). I'm stuck.

Help?

On 09/18/2013 07:49 PM, Cullen Jennings wrote:



Your recording is now available on the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71503827&rKey=2cb05592aa7be2c2

RTCWeb - JSEP-20130918 1508-1
Wednesday, September 18, 2013 8:08 am San Francisco Time
1 Hour 49 Minutes 





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

--------------060309000000090802080605-- From harald@alvestrand.no Thu Sep 19 05:53:46 2013 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 7304521F9385 for ; Thu, 19 Sep 2013 05:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBeghT+Qr8tF for ; Thu, 19 Sep 2013 05:53:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CE73821F9396 for ; Thu, 19 Sep 2013 05:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0201E39E1B7 for ; Thu, 19 Sep 2013 14:53:33 +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 8DzwSOrRW7kh for ; Thu, 19 Sep 2013 14:53:32 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1] (unknown [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6324939E04F for ; Thu, 19 Sep 2013 14:53:32 +0200 (CEST) Message-ID: <523AF421.7000807@alvestrand.no> Date: Thu, 19 Sep 2013 14:54:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] JSEP-04: Nits and niggles 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, 19 Sep 2013 12:53:46 -0000 I'm sure we'll have lots of things to discuss about JSEP. I just thought I'd get these out of the way. - Usage of MSID. In addition to the a=msid: lines, the session-level generation procedure needs to say that a line "a=msid-semantic:WMS " is added to the session-level description, containing the IDs of the MediaStreams that are signalled. - a=ssrc lines. The spec (5.2.1 second list last bullet) simply says "an a=ssrc line". But RFC 5576 specifies that all ssrc lines contain an attribute. Suggestion: define one that does no harm (role=primary?) - recycling of m= lines. The section in 5.2.2 (subsequent offers) that talks about this doesn't mention that the media in the m-line has to match, although section 5.3.1 (initial answer) actually talks about it. I'm assuming that's an oversight. I'd suggest pulling the language about "selecting an appropriate m-line for a track" out in a separate subsection, so that we have one place to point to for this. Out of time, let's get these ones out of the way for -05.... From michael@voip.co.uk Thu Sep 19 08:40:26 2013 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 763A821F964C for ; Thu, 19 Sep 2013 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.207 X-Spam-Level: X-Spam-Status: No, score=-5.207 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5Evf7Olfq9s for ; Thu, 19 Sep 2013 08:40:20 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with SMTP id 5646121F8F9A for ; Thu, 19 Sep 2013 08:40:19 -0700 (PDT) Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUjsa4zAXSp2HJ0QeMtBCLiHTwoXdhVxz@postini.com; Thu, 19 Sep 2013 08:40:19 PDT Received: by mail-wi0-f170.google.com with SMTP id cb5so8035366wib.3 for ; Thu, 19 Sep 2013 08:40:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=QrDq9aJ10lpHJwf2u4zlzRTrQzMA52BmR+y5aJpJXHw=; b=YNLcQm/Y1OOvnGFtA2rvwN6Dj0bMjZ4AGZhc5sU5Liu36iBJykclYEd40kgYmU7+Np XStraE72SGImFxzCR+FHAYCec/EWxNKkFYV7h1VWwB0G/E8WeBtvLqBgNzgLoOGKknQ3 AuSW03fr4D/V46+fJhV8QdGn9nbRiE+HWnrxqTbWLdtjUVK1myhTGrVAPI1vpIBmtILS uNTLkJJiZXLV7T66B+FQTXWw5f94jOcigTuxA5dOiCAg32fLN++GUMOeW9j35LKr/jg9 TkKfpA2Gjoi/3XbQbUSBEPFU75yUUcC6lQpElCDKgyod70uNOEGfdUnRkoZwCU0xJ27f 7BxQ== X-Gm-Message-State: ALoCoQnV93g812P1dcAJzL9wOxCbVLNDEuXnmEMxF4n9fFe/oNyC6kmY6KD83kmyd3Tz4js797GOuwnSSLZEEUGhmqzIgWqqURyQKG7/Qu7X9T/2HbYLldr+RsPi6oTzzVV8M5Ye1cw0WBfrMCxiOPu07Qcsv6yERw== X-Received: by 10.180.182.68 with SMTP id ec4mr12122237wic.40.1379605218001; Thu, 19 Sep 2013 08:40:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.182.68 with SMTP id ec4mr12122233wic.40.1379605217935; Thu, 19 Sep 2013 08:40:17 -0700 (PDT) Received: by 10.194.93.34 with HTTP; Thu, 19 Sep 2013 08:40:17 -0700 (PDT) Date: Thu, 19 Sep 2013 16:40:17 +0100 Message-ID: From: Michael Procter To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] jsep-04 questions about phrasing 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, 19 Sep 2013 15:40:26 -0000 Hi, Section 5.2.2 Subsequent Offers This section starts with the sentence "When createOffer is called a second (or later) time,". As far as I can tell, the rest of this section applies both to subsequent offers created by the original offerer and also offers created by the original answerer. In this second case, createOffer has never been called. I would suggest something like "When createOffer is called after the initial offer/answer exchange,". Section 5.2.2 11th bullet: o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the remote description. Is this necessary? Can't we offer new codecs in a subsequent offer? RFC3264 Sec 8.3.2 permits new codecs to be offered, old ones to be removed etc, with the only constraint being to not reuse dynamic payload types. Finally, the two example SDPs both contain "s=-" whereas section 5.2.1 encourages "s= " instead. Personally, I prefer the hyphen, but consistency is probably more important. Regards, Michael From gsalguei@cisco.com Thu Sep 19 09:20:14 2013 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 0C91021F99E1; Thu, 19 Sep 2013 09:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16g0FutdFak4; Thu, 19 Sep 2013 09:20:03 -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 EE02A21F9473; Thu, 19 Sep 2013 09:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2309; q=dns/txt; s=iport; t=1379607603; x=1380817203; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=78pf1f4rXg9h4+xiOCLrgVnae7zD9vKkd/pE+K5XbXo=; b=bGlstCdVpnN9ceKE/WvjihDXTLARfeoBmUjsR4MW0cMyGb253PcVBEn9 CK+nZKWlipJhdQk4Y/6Wp2zeZiisUx93WeYz8Bf0l3qIjUw6RI0TitXGA iB/Gg0OZ6kakUbf96vwP59E0u1PnlGgKgQ3EGDNGKQfgE2N9e4uwtVJxA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIQjO1KtJV2c/2dsb2JhbABbgwc4TMEygSIWdIIlAQEBAwEBAQE3NAQMCwIBCBgeECcLJQIEARIJh3QGBwW6F480NQWDHoEAA5d8gS+LFoUwgyQ X-IronPort-AV: E=Sophos;i="4.90,937,1371081600"; d="scan'208";a="261984266" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2013 16:20:02 +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 r8JGK1Jo031813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 16:20:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 11:20:01 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "clue@ietf.org" , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt Thread-Index: AQHOtUhFDQQt1kchvUGOM9R/xaYmXpnNPZxE Date: Thu, 19 Sep 2013 16:20:00 +0000 Message-ID: <6EDBE2F4-6722-45EB-A83E-8FDC51DD6633@cisco.com> References: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> In-Reply-To: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.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, 19 Sep 2013 16:20:15 -0000 [Please forgive the cross-post...] Significant changes have been made to the draft, please provide feedback or= comment on its usefulness @AVTEXT Cheers,=20 Gonzalo > On Sep 19, 2013, at 10:55 AM, "internet-drafts@ietf.org" wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : A Taxonomy of Grouping Semantics and Mechanisms for = Real-Time Transport Protocol (RTP) Sources > Author(s) : Jonathan Lennox > Kevin Gross > Suhas Nandakumar > Gonzalo Salgueiro > Bo Burman > Filename : draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt > Pages : 40 > Date : 2013-09-19 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. >=20 > This document is still very rough, but is submitted in the hopes of > making future discussion productive. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxono= my >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-lennox-raiarea-rtp-grouping-taxo= nomy-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From christer.holmberg@ericsson.com Thu Sep 19 09:26:27 2013 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 D6AB321F8BFD for ; Thu, 19 Sep 2013 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=-2.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93qbIHOSn-7L for ; Thu, 19 Sep 2013 09:26:21 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C7C8821F841D for ; Thu, 19 Sep 2013 09:26:20 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-3d-523b25a60d53 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B4.99.25272.6A52B325; Thu, 19 Sep 2013 18:26:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 18:24:50 +0200 From: Christer Holmberg To: Suhas Nandakumar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] m=section recycling and a=mid Thread-Index: AQHOtI5OlzgN5l68MU+Yf86f9mtTsJnNP/0Z Date: Thu, 19 Sep 2013 16:24:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A7F29ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje4yVesgg20vjSzW/mtnt9g5t4PZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpY+P0aa0GvSsX23x9ZGxivynYxcnJICJhI vFj5nxXCFpO4cG89WxcjF4eQwFFGiYe7V7JCOEsYJdrnNjF2MXJwsAlYSHT/0wZpEBEIlPix 9ygTiC0sYCyx8NkvFoi4icSuuWvYIGwjiTsfHzCC2CwCqhJrfs4EW8Yr4CvRsL4TrFdIIECi /+1aMJsTaOb2bTfZQWxGoIO+n1oDFmcWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKcpqEgKLE 8n45iPJ8iXsHWqFWCUqcnPmEZQKjyCwkk2YhKZuFpAwiridxY+oUNghbW2LZwtfMELauxIx/ h1iQxRcwsq9i5ChOLU7KTTcy2MQIjJ2DW35b7GC8/NfmEKM0B4uSOO8WvTOBQgLpiSWp2amp BalF8UWlOanFhxiZODilGhhnmh6QzCqu2n9fm2XDzK8/phTt6Thqd3uuoOuJ9wxft7/l8v4l dmbKmjuzo+N2Lirerh2wy/Rc51krAzXXeblpVkL8mWfKf8u5Ct4T/NOrYOG0IeKrVM+x14LR gRJ/7c7PurFqC4tsWEnqsovVa/j+NWw+Mjl6VeihsMxEbqtZEk+ePP8SwzRfiaU4I9FQi7mo OBEA/3wCVGsCAAA= Subject: Re: [rtcweb] m=section recycling and a=mid 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, 19 Sep 2013 16:26:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A7F29ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suhas, The mid attribute itself does not add an m- line to a BUNDLE group. The att= ribute value also needs to be listed in the group:BUNDLE attribute mid list= . So, if you want to re-use an m- line and mid attribute, but you don't want = the m- line to be in the BUNDLE group, simply remove the mid from the mid l= ist. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Suhas = Nandakumar [suhasietf@gmail.com] Sent: Wednesday, 18 September 2013 7:44 PM To: rtcweb@ietf.org Subject: [rtcweb] m=3Dsection recycling and a=3Dmid After thinking about it a bit, I think there are some side effects associat= ed with changing/not changing mid attribute of a re-cycled m=3D section and= it being part of a BUNDLE group or not.. example say , we have these video m=3Dsection part of BUNDLE group as below a=3Dgroup:BUNDLE 1, 2 m=3Dvideo ..... a=3Dmid:1 a=3Dinactive m=3Dvideo ..... a=3Dmid:2 a=3Dsendrecv Now If JS user adds a new video track and he wants it to be out of BUNDLE. = If we recycle first video m=3Dsection and dont change mid attribute, we en= d up BUNDLing even if the user dint want to On the other hand, if we allowed mid value to be changed, we might end up U= NBundling a video stream , when the user did want to BUNDLE them So allowing a mid value to be changed or not should be tied to what the JS = API is asking on behalf of the user Any thoughts ? Cheers Suhas --_000_7594FB04B1934943A5C02806D1A2204B1C4A7F29ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Suhas,

 

The mid attribute itself does not add an m- line to a BUNDLE group. The = attribute value also needs to be listed in the group:BUNDLE attribute mid l= ist.

 

So, if you want to re-use an m- line and mid attribute, but you don't wa= nt the m- line to be in the BUNDLE group, simply remove the mid from the mi= d list.

 

Regards,

 

Christer

 

From: rtcweb-bounces@ietf.org [rtcweb-boun= ces@ietf.org] on behalf of Suhas Nandakumar [suhasietf@gmail.com]
Sent: Wednesday, 18 September 2013 7:44 PM
To: rtcweb@ietf.org
Subject: [rtcweb] m=3Dsection recycling and a=3Dmid

After thinking about it a bit, I think there are some side= effects associated with changing/not changing mid attribute of a re-cycled= m=3D section and it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part of BUNDLE group as below&nb= sp;
a=3Dgroup:BUNDLE 1, 2

m=3Dvideo .....
a=3Dmid:1 
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2 
a=3Dsendrecv

Now If JS user adds a new video track and he wants it to be out of BUN= DLE. If we recycle first video m=3Dsection and dont change mid attribute, &= nbsp;we end up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be changed, we might end= up UNBundling a video stream , when the user did want to BUNDLE them

So allowing a mid value to be changed or not should be tied to what th= e JS API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas


--_000_7594FB04B1934943A5C02806D1A2204B1C4A7F29ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Sep 19 09:36:02 2013 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 6029E21F9635 for ; Thu, 19 Sep 2013 09:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.538 X-Spam-Level: X-Spam-Status: No, score=-4.538 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkKakoXbZEsw for ; Thu, 19 Sep 2013 09:35:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD8D21F960D for ; Thu, 19 Sep 2013 09:35:55 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-d8-523b27e87b7f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.57.22048.8E72B325; Thu, 19 Sep 2013 18:35:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 18:35:52 +0200 From: Christer Holmberg To: Suhas Nandakumar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] m=section recycling and a=mid Thread-Index: AQHOtI5OlzgN5l68MU+Yf86f9mtTsJnNP/0ZgAADHRE= Date: Thu, 19 Sep 2013 16:35:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A7F58@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A7F58ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje4Ldesgg2+3DSzW/mtnt9g5t4PZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpoePWBsaDfs+Ljyy7mBsb/tl2MnBwSAiYS z9qXMUPYYhIX7q1n62Lk4hASOMwosalvHwuEs4RRYv36a0AOBwebgIVE9z9tkAYRgUCJH3uP MoHYwgLGEguf/WKBiJtI7Jq7hg3CtpI4+WA2WJxFQFXi8tX37CA2r4CvxKP1q5kh5k9ilLiy 8g1YA6eAn8THC7vAGhiBLvp+ag3YAmYBcYlbT+YzQVwqILFkz3moq0UlXj7+xwpym4SAosTy fjmI8nyJlWcesUDsEpQ4OfMJywRGkVlIJs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/ DrEgiy9gZF/FyJ6bmJmTXm6+iREYOwe3/DbYwbjpvtghRmkOFiVx3s16ZwKFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MC4z0dyxoWGW1i3HigOZRpMeZSkvi9OZs2HOyUK3qrj/X1XurzRd 1Gr38PcfHZXdFd6fC5RifOUKDnLG/6jxm3z22iqZ5Veff/R+MO3f9bi7ARebDr39bD75xCYB 76l7txdvW7/S4ZhbyUeVyZYt5ps2vt6763VsQ8k5BuYFzpt+2NfUdu9q5V6jxFKckWioxVxU nAgAYiC1wGsCAAA= Subject: Re: [rtcweb] m=section recycling and a=mid 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, 19 Sep 2013 16:36:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A7F58ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Below is some suggested BUNDLE text: 6.4.5. Moving A Media Description Out Of A BUNDLE Group When an Offerer generates an Offer, in which an "m=3D" line is moved out of a BUNDLE group, the Offerer MUST assign a unique address to the moved "m=3D" line. In addition, the Offerer MUST NOT anymore include a mid value, representing the "m=3D" line, in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group. Section 11.4 shows an example of an Offer used to move an "m=3D" line out of a BUNDLE group. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, 19 September 2013 7:24 PM To: Suhas Nandakumar; rtcweb@ietf.org Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid Hi Suhas, The mid attribute itself does not add an m- line to a BUNDLE group. The att= ribute value also needs to be listed in the group:BUNDLE attribute mid list= . So, if you want to re-use an m- line and mid attribute, but you don't want = the m- line to be in the BUNDLE group, simply remove the mid from the mid l= ist. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Suhas = Nandakumar [suhasietf@gmail.com] Sent: Wednesday, 18 September 2013 7:44 PM To: rtcweb@ietf.org Subject: [rtcweb] m=3Dsection recycling and a=3Dmid After thinking about it a bit, I think there are some side effects associat= ed with changing/not changing mid attribute of a re-cycled m=3D section and= it being part of a BUNDLE group or not.. example say , we have these video m=3Dsection part of BUNDLE group as below a=3Dgroup:BUNDLE 1, 2 m=3Dvideo ..... a=3Dmid:1 a=3Dinactive m=3Dvideo ..... a=3Dmid:2 a=3Dsendrecv Now If JS user adds a new video track and he wants it to be out of BUNDLE. = If we recycle first video m=3Dsection and dont change mid attribute, we en= d up BUNDLing even if the user dint want to On the other hand, if we allowed mid value to be changed, we might end up U= NBundling a video stream , when the user did want to BUNDLE them So allowing a mid value to be changed or not should be tied to what the JS = API is asking on behalf of the user Any thoughts ? Cheers Suhas --_000_7594FB04B1934943A5C02806D1A2204B1C4A7F58ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below is some suggested BUNDLE text:

 

6.4.5.  Moving A Media Description Out Of A BU= NDLE Group
 
   When an Offerer generates an Offer, in= which an "m=3D" line is moved
   out of a BUNDLE group, the Offerer MUS= T assign a unique address to
   the moved "m=3D" line.  In addition, the Offerer MUST NOT anymore
   include a mi= d value, representing the "m=3D" line, in the SDP=
   group:= BUNDLE attribute mid list associated with the BUNDLE group.=
 
   Section 11.4 shows an example of an Of= fer used to move an "m=3D" line
   out of a BUNDLE group.

 

Regards,

 

Christer

 

From: rtcweb-bounces@ietf.org [rtcweb-boun= ces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.co= m]
Sent: Thursday, 19 September 2013 7:24 PM
To: Suhas Nandakumar; rtcweb@ietf.org
Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid

Hi Suhas,

 

The mid attribute itself does not add an m- line to a BUNDLE group. The = attribute value also needs to be listed in the group:BUNDLE attribute mid l= ist.

 

So, if you want to re-use an m- line and mid attribute, but you don't wa= nt the m- line to be in the BUNDLE group, simply remove the mid from the mi= d list.

 

Regards,

 

Christer

 

From: rtcweb-bounces@ietf.org [rtcweb-boun= ces@ietf.org] on behalf of Suhas Nandakumar [suhasietf@gmail.com]
Sent: Wednesday, 18 September 2013 7:44 PM
To: rtcweb@ietf.org
Subject: [rtcweb] m=3Dsection recycling and a=3Dmid

After thinking about it a bit, I think there are some side= effects associated with changing/not changing mid attribute of a re-cycled= m=3D section and it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part of BUNDLE group as below&nb= sp;
a=3Dgroup:BUNDLE 1, 2

m=3Dvideo .....
a=3Dmid:1 
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2 
a=3Dsendrecv

Now If JS user adds a new video track and he wants it to be out of BUN= DLE. If we recycle first video m=3Dsection and dont change mid attribute, &= nbsp;we end up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be changed, we might end= up UNBundling a video stream , when the user did want to BUNDLE them

So allowing a mid value to be changed or not should be tied to what th= e JS API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas


--_000_7594FB04B1934943A5C02806D1A2204B1C4A7F58ESESSMB209erics_-- From fluffy@cisco.com Thu Sep 19 10:26:54 2013 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 318C121F964C for ; Thu, 19 Sep 2013 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veXiRMpExeXb for ; Thu, 19 Sep 2013 10:26:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A159F21F98EE for ; Thu, 19 Sep 2013 10:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=917; q=dns/txt; s=iport; t=1379611608; x=1380821208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J0zW5ayOJNRVJ7Vh2n/K/e24wlCl8U8MlLNtmx8IGC8=; b=hd01i2LT60LQDr24pOV0+TADLETMex6CDNSOFtKGhdEV8G1Fvx0ZIz5U MQKv1hAhCSbJNTmJJfzd0FSSl53loQkBgeYIa4acA57PaobOsx/fEvLSZ onSe46YtUMFyh7qUQMlPw9j1aXRPvLr4vHuhOSNdtGDqinaOfl/gqo3A7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJAyO1KtJV2Y/2dsb2JhbABbgwc4UsBiSoEiFnSCJQEBAQMBAQEBawsFCwIBCBgKJCEGCyUCBA4FCIdpAwkGDLA0DYleBIx7gjkCMQeDHoEAA4kAjROOK4UzgySCKg X-IronPort-AV: E=Sophos;i="4.90,938,1371081600"; d="scan'208";a="261806892" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2013 17:26:48 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8JHQmQW031861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 17:26:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 12:26:48 -0500 From: "Cullen Jennings (fluffy)" To: Suhas Nandakumar Thread-Topic: [rtcweb] how to control which track plays in a video tag Thread-Index: AQHOtV1qkxTQZpKAjkKP4VCSBKGS4A== Date: Thu, 19 Sep 2013 17:26:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.72.97] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C32317CECAFCF42A6520D3E655DAB34@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] how to control which track plays in a video tag 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, 19 Sep 2013 17:26:54 -0000 OMG - that was bad. I meant to send this to webrtc list. I apologize and I = will have some chair give me a proper lecture on mailing list use. Please s= end any replies to webrtc list.=20 On Sep 18, 2013, at 9:32 AM, Suhas Nandakumar wrote: > Shouldn't this be dealt with a W3C API, say videoelem.src =3D mediastream= .trackAt(0)=20 >=20 >=20 > On Wed, Sep 18, 2013 at 9:01 AM, Cullen Jennings (fluffy) wrote: >=20 > The issue got raised if there is multiple video tracks in a media stream,= how do you control which video track gets played in a video stream > _______________________________________________ > 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 suhasietf@gmail.com Thu Sep 19 11:48:07 2013 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 2F0AA21F84B7 for ; Thu, 19 Sep 2013 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PymvaJbZaqUH for ; Thu, 19 Sep 2013 11:48:06 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 24FC021F9223 for ; Thu, 19 Sep 2013 11:48:05 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so8431587wib.10 for ; Thu, 19 Sep 2013 11:48:05 -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=1KJ5oeVsnQkRd70pXGbIJgbZfIQ6ui8eam15IqnrdKg=; b=QX7T7f9WmSocCwIXgfYIhV5uosrNRGeZJHGmCBXdeEySu/p+Hf1Wa0m3K6+13CnJXW qtAgZcPX4gSy//yQLEaLx5mqHbetRU/Wn6x8m9dLqGTky2eChgdj6knne55feckPknwr ZKOyBgxpaxtptrlv56nOxWnvcjrgyxRoBbw/jrQBnkg9sMbY18Wm44LVEYi25O8riKFj Ir+Gvb7ot/PTcDSLK5L6ZNiA/5l2ueeVEgE/IhtqkQTJlFUvCQhwwO8CJc9e7VViFfVM Cfpue6IYkcd1pjUEIwm9j1wYV75AuEbeDOvIvxNg5f/kXO0wlPUKAY1LxsfRQXaaqaIL B1+Q== MIME-Version: 1.0 X-Received: by 10.194.200.100 with SMTP id jr4mr2551931wjc.37.1379616485210; Thu, 19 Sep 2013 11:48:05 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Thu, 19 Sep 2013 11:48:05 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se> Date: Thu, 19 Sep 2013 11:48:05 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bb03e1e8706a804e6c0fe88 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] m=section recycling and a=mid 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, 19 Sep 2013 18:48:07 -0000 --047d7bb03e1e8706a804e6c0fe88 Content-Type: text/plain; charset=ISO-8859-1 Hello Christer Completely agree with you My point with the above examples was "recycling of m=line should take into account its existing BUNDLE membership and JS user's preference on requiring the added media track to be BUNDLED or not" This would imply, as suggested by you, - remove the mid from a=group:BUNDLE line if the JS user doesn't want the new track to be BUNDLEd - or if the mid value is changed, then add the new mid value to the BUNDLE group if the JS user want's the new track to be BUNDLED - or just retain the mid value and its BUNDLE membership for the new track, if it is going to be BUNDLEd Cheers Suhas On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Suhas, > > > > The mid attribute itself does not add an m- line to a BUNDLE group. The > attribute value also needs to be listed in the group:BUNDLE attribute mid > list. > > > > So, if you want to re-use an m- line and mid attribute, but you don't want > the m- line to be in the BUNDLE group, simply remove the mid from the mid > list. > > > > Regards, > > > > Christer > > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Suhas Nandakumar [suhasietf@gmail.com] > *Sent:* Wednesday, 18 September 2013 7:44 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] m=section recycling and a=mid > > After thinking about it a bit, I think there are some side effects > associated with changing/not changing mid attribute of a re-cycled m= > section and it being part of a BUNDLE group or not.. > > example > > say , we have these video m=section part of BUNDLE group as below > a=group:BUNDLE 1, 2 > > m=video ..... > a=mid:1 > a=inactive > > m=video ..... > a=mid:2 > a=sendrecv > > Now If JS user adds a new video track and he wants it to be out of > BUNDLE. If we recycle first video m=section and dont change mid attribute, > we end up BUNDLing even if the user dint want to > > On the other hand, if we allowed mid value to be changed, we might end > up UNBundling a video stream , when the user did want to BUNDLE them > > So allowing a mid value to be changed or not should be tied to what the > JS API is asking on behalf of the user > > > Any thoughts ? > > Cheers > Suhas > > > --047d7bb03e1e8706a804e6c0fe88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Christer

=A0 Completely agree wit= h you

My point with the above examples was=A0

=A0 "recycling of m=3Dline should take into accou= nt its existing BUNDLE membership and JS user's preference on requiring= the added media track to be BUNDLED or not"

This would imply, as suggested by you,

=A0 - remove the mid from a=3Dgroup:BUNDLE line if the JS user doe= sn't want the new track to be BUNDLEd

=A0- or = if the mid value is changed, then add the new mid value to the BUNDLE group= if the JS user want's the new track to be BUNDLED

- or just retain the mid value and its BUNDLE membershi= p for the new track, if it is going to be BUNDLEd

=
Cheers
Suhas







On Thu, Sep 19, 2013 at 9:24 AM, Chri= ster Holmberg <christer.holmberg@ericsson.com> = wrote:

Hi Suhas,

=A0

The mid attribute itself does not add an m- line to a BUNDLE group. The = attribute value also needs to be listed in the group:BUNDLE attribute mid l= ist.

=A0

So, if you want to re-use an m- line and mid attribute, but you don'= t want the m- line to be in the BUNDLE group, simply remove the mid from th= e mid list.

=A0

Regards,

=A0

Christer

=A0

Fro= m: rtcweb-= bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Suhas Nandakumar [suhasietf@gmail.com]<= br> Sent: Wednesday, 18 September 2013 7:44 PM
To: rtcweb@ietf= .org
Subject: [rtcweb] m=3Dsection recycling and a=3Dmid

After thinking about it a bit, I think there are some side= effects associated with changing/not changing mid attribute of a re-cycled= m=3D section and it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part of BUNDLE group as below=A0=
a=3Dgroup:BUNDLE 1, 2

m=3Dvideo .....
a=3Dmid:1=A0
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2=A0
a=3Dsendrecv

Now If JS user adds a new video track and he wants it to be out of BUN= DLE. If we recycle first video m=3Dsection and dont change mid attribute, = =A0we end up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be changed, we might end= up UNBundling a video stream , when the user did want to BUNDLE them

So allowing a mid value to be changed or not should be tied to what th= e JS API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas



--047d7bb03e1e8706a804e6c0fe88-- From christer.holmberg@ericsson.com Thu Sep 19 11:52:25 2013 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 C8C2C21F94FF for ; Thu, 19 Sep 2013 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Cwga6fBYH1 for ; Thu, 19 Sep 2013 11:52:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6062421F949F for ; Thu, 19 Sep 2013 11:52:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-0a-523b47dfd98a Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 75.74.16099.FD74B325; Thu, 19 Sep 2013 20:52:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 20:52:15 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [rtcweb] m=section recycling and a=mid Thread-Index: AQHOtI5OlzgN5l68MU+Yf86f9mtTsJnNP/0ZgAAG7ICAACKcCw== Date: Thu, 19 Sep 2013 18:52:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A800EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje59d+sgg47nphZr/7WzW+yc28Hs wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGV8nfiFreCGQ8X8I2fZGhj3m3YxcnJICJhI nFj1nA3CFpO4cG89kM3FISRwmFHixYpD7BDOEkaJ8323mboYOTjYBCwkuv9pgzSICGhJrF48 lwnEZhZQl7iz+Bw7iC0sYCyx8NkvFogaE4ldc9ewgbSKCDhJTHiuCxJmEVCV6Pz7nRXE5hXw lZg9qwesXEjgJqPEtCvhIDanQKDEtAlrmEFsRqDbvp9aA7VKXOLWk/lMEDcLSCzZc54ZwhaV ePn4HyuErShxdfpyqPp8iX83HrBA7BKUODnzCcsERtFZSEbNQlI2C0kZRFxP4sbUKWwQtrbE soWvmSFsXYkZ/w6xIIsvYGRfxciem5iZk15uuIkRGFEHt/zW3cF46pzIIUZpDhYlcd5NemcC hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAGakS+Y7W+dF/40XyzDWVN717OvzBzpm25uU7O jBse648xXzq655jDUhFe8fQdMQtkDwU7M0/e7XcqXkJG5gD/AgWBot7gKQIPnc85/3JibA5x 1msqV/6+/nq+w9zZe/mSOzSPbr7tMn3Ka6Z/nDPe90uHLkp5uOTs1wOXd03sqPNLW7RIl+GB EktxRqKhFnNRcSIAYxFZPnYCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] m=section recycling and a=mid 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, 19 Sep 2013 18:52:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4A800EESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct. Regards, Christer ________________________________ From: Suhas Nandakumar [suhasietf@gmail.com] Sent: Thursday, 19 September 2013 9:48 PM To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid Hello Christer Completely agree with you My point with the above examples was "recycling of m=3Dline should take into account its existing BUNDLE membe= rship and JS user's preference on requiring the added media track to be BUN= DLED or not" This would imply, as suggested by you, - remove the mid from a=3Dgroup:BUNDLE line if the JS user doesn't want t= he new track to be BUNDLEd - or if the mid value is changed, then add the new mid value to the BUNDLE= group if the JS user want's the new track to be BUNDLED - or just retain the mid value and its BUNDLE membership for the new track,= if it is going to be BUNDLEd Cheers Suhas On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg > wrote: Hi Suhas, The mid attribute itself does not add an m- line to a BUNDLE group. The att= ribute value also needs to be listed in the group:BUNDLE attribute mid list= . So, if you want to re-use an m- line and mid attribute, but you don't want = the m- line to be in the BUNDLE group, simply remove the mid from the mid l= ist. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Suhas Nandakumar = [suhasietf@gmail.com] Sent: Wednesday, 18 September 2013 7:44 PM To: rtcweb@ietf.org Subject: [rtcweb] m=3Dsection recycling and a=3Dmid After thinking about it a bit, I think there are some side effects associat= ed with changing/not changing mid attribute of a re-cycled m=3D section and= it being part of a BUNDLE group or not.. example say , we have these video m=3Dsection part of BUNDLE group as below a=3Dgroup:BUNDLE 1, 2 m=3Dvideo ..... a=3Dmid:1 a=3Dinactive m=3Dvideo ..... a=3Dmid:2 a=3Dsendrecv Now If JS user adds a new video track and he wants it to be out of BUNDLE. = If we recycle first video m=3Dsection and dont change mid attribute, we en= d up BUNDLing even if the user dint want to On the other hand, if we allowed mid value to be changed, we might end up U= NBundling a video stream , when the user did want to BUNDLE them So allowing a mid value to be changed or not should be tied to what the JS = API is asking on behalf of the user Any thoughts ? Cheers Suhas --_000_7594FB04B1934943A5C02806D1A2204B1C4A800EESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Correct.

 

Regards,

 

Christer

From: Suhas Nandakumar [suhasietf@gmail.co= m]
Sent: Thursday, 19 September 2013 9:48 PM
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid

Hello Christer

  Completely agree with you

My point with the above examples was 

  "recycling of m=3Dline should take into account its existi= ng BUNDLE membership and JS user's preference on requiring the added media = track to be BUNDLED or not"

This would imply, as suggested by you,

  - remove the mid from a=3Dgroup:BUNDLE line if the JS user does= n't want the new track to be BUNDLEd

 - or if the mid value is changed, then add the new mid value to = the BUNDLE group if the JS user want's the new track to be BUNDLED

- or just retain the mid value and its BUNDLE membership for the new t= rack, if it is going to be BUNDLEd


Cheers
Suhas







On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi Suhas,

 

The mid attribute itself does not add an m- line to a BUNDLE group. The = attribute value also needs to be listed in the group:BUNDLE attribute mid l= ist.

 

So, if you want to re-use an m- line and mid attribute, but you don't wa= nt the m- line to be in the BUNDLE group, simply remove the mid from the mi= d list.

 

Regards,

 

Christer

 

Fr= om: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Suhas Nandakumar [= suhasietf@gmail.co= m]
Sent: Wednesday, 18 September 2013 7:44 PM
To: rtcweb@ietf= .org
Subject: [rtcweb] m=3Dsection recycling and a=3Dmid

After thinking about it a bit, I think there are some side= effects associated with changing/not changing mid attribute of a re-cycled= m=3D section and it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part of BUNDLE group as below&nb= sp;
a=3Dgroup:BUNDLE 1, 2

m=3Dvideo .....
a=3Dmid:1 
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2 
a=3Dsendrecv

Now If JS user adds a new video track and he wants it to be out of BUN= DLE. If we recycle first video m=3Dsection and dont change mid attribute, &= nbsp;we end up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be changed, we might end= up UNBundling a video stream , when the user did want to BUNDLE them

So allowing a mid value to be changed or not should be tied to what th= e JS API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas



--_000_7594FB04B1934943A5C02806D1A2204B1C4A800EESESSMB209erics_-- From suhasietf@gmail.com Thu Sep 19 13:55:41 2013 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 DF5D621F8640 for ; Thu, 19 Sep 2013 13:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k33khiXfXJS for ; Thu, 19 Sep 2013 13:55:39 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1921F8887 for ; Thu, 19 Sep 2013 13:55:30 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so8590705wes.15 for ; Thu, 19 Sep 2013 13:55:29 -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=YQ1BpIhKQtOA2pyof2eCs6w9Fdt0jGRCaztDKuSh4fw=; b=SFzHVyR5qlRLRsjmWqTR+q6WLO1YPuvPE/KTQfVjP79PVEwe5zcQG+Pk08uunCaCJW M3NQJmgdPVRlBR2VbP6YYoiTSCoyYFDv7x3Qvfr/49mZVX9YzP4996GBGQd5bToKg5J1 5GIMh9DtfZhxH1AjosKULY1uC19sZ31/LkAla0TDKXf/+6Ysx/qDiEgkYqgbfYS9PU5p ml98uL+RYJmiqYGHCIxWadvD7T0tqdZUp2YbjYnaLBBqQDeF1h5iESQm7o6ZMh34SNZw jEegiuwJCJ0dlG8vqwJYvhQxC1j7gIj398ZOmB7dlHJPZ1A0vZk7Y9x1+b84by/HJq/V 5bgg== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr2882218wib.13.1379624129743; Thu, 19 Sep 2013 13:55:29 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Thu, 19 Sep 2013 13:55:29 -0700 (PDT) In-Reply-To: <523AF421.7000807@alvestrand.no> References: <523AF421.7000807@alvestrand.no> Date: Thu, 19 Sep 2013 13:55:29 -0700 Message-ID: From: Suhas Nandakumar To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8f2353a72d50c904e6c2c64e Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-04: Nits and niggles 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, 19 Sep 2013 20:55:42 -0000 --e89a8f2353a72d50c904e6c2c64e Content-Type: text/plain; charset=ISO-8859-1 Regarding a=ssrc comment above, The text from RFC5576 says this Each "ssrc" media attribute specifies a single source-level attribute for the given . For each source mentioned in SDP, the source-level attribute "cname", defined in Section 6.1 , MUST be provided. Any number of other source-level attributes for the source MAY also be provided. given the above, would it be cname attribute for a given ssrc that should be mandated at the minimum ? Cheers Suhas On Thu, Sep 19, 2013 at 5:54 AM, Harald Alvestrand wrote: > I'm sure we'll have lots of things to discuss about JSEP. I just thought > I'd get these out of the way. > > - Usage of MSID. In addition to the a=msid: lines, the session-level > generation procedure needs to say that a line "a=msid-semantic:WMS " is > added to the session-level description, containing the IDs of the > MediaStreams that are signalled. > > - a=ssrc lines. The spec (5.2.1 second list last bullet) simply says "an > a=ssrc line". But RFC 5576 specifies that all ssrc lines contain an > attribute. Suggestion: define one that does no harm (role=primary?) > > - recycling of m= lines. The section in 5.2.2 (subsequent offers) that > talks about this doesn't mention that the media in the m-line has to match, > although section 5.3.1 (initial answer) actually talks about it. I'm > assuming that's an oversight. > > I'd suggest pulling the language about "selecting an appropriate m-line > for a track" out in a separate subsection, so that we have one place to > point to for this. > > Out of time, let's get these ones out of the way for -05.... > > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8f2353a72d50c904e6c2c64e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding a=3Dssrc comment above,
The text from = RFC5576 says this=A0

Each "ssrc"=
; media attribute specifies a single source-level attribute
   for the given <ssrc-id>.  For each source mentioned in SDP, the
   source-level attribute "cname", defined in Section 6.1, MUST be
   provided.  Any number of other source-level attributes for the source
   MAY also be provided.


<=
/pre>

given the above, would it be cname =
attribute for a given ssrc that should be mandated at the minimum ?<=
/font>






Cheers
Suhas




On Thu, Sep 19, 2013 at 5:54 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
I'm sure we'll have lots of things to discuss about JSEP. I just th= ought I'd get these out of the way.

- Usage of MSID. In addition to the a=3Dmsid: lines, the session-level gene= ration procedure needs to say that a line "a=3Dmsid-semantic:WMS <i= d>" is added to the session-level description, containing the IDs o= f the MediaStreams that are signalled.

- a=3Dssrc lines. The spec (5.2.1 second list last bullet) simply says &quo= t;an a=3Dssrc line". But RFC 5576 specifies that all ssrc lines contai= n an attribute. Suggestion: define one that does no harm (role=3Dprimary?)<= br>
- recycling of m=3D lines. The section in 5.2.2 (subsequent offers) that ta= lks about this doesn't mention that the media in the m-line has to matc= h, although section 5.3.1 (initial answer) actually talks about it. I'm= assuming that's an oversight.

I'd suggest pulling the language about "selecting an appropriate m= -line for a track" out in a separate subsection, so that we have one p= lace to point to for this.

Out of time, let's get these ones out of the way for -05....



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

--e89a8f2353a72d50c904e6c2c64e-- From harald@alvestrand.no Thu Sep 19 15:18:33 2013 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 B123B21F88FB for ; Thu, 19 Sep 2013 15:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.217 X-Spam-Level: X-Spam-Status: No, score=-110.217 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8f57PZl08PO for ; Thu, 19 Sep 2013 15:18:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A580721F87BB for ; Thu, 19 Sep 2013 15:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41EC039E1B7; Fri, 20 Sep 2013 00:18:25 +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 ylgwS9KAUVgx; Fri, 20 Sep 2013 00:18:24 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1] (unknown [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2974E39E04F; Fri, 20 Sep 2013 00:18:24 +0200 (CEST) Message-ID: <523B7886.2080201@alvestrand.no> Date: Fri, 20 Sep 2013 00:19:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Suhas Nandakumar References: <523AF421.7000807@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080804050409020005090004" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-04: Nits and niggles 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, 19 Sep 2013 22:18:33 -0000 This is a multi-part message in MIME format. --------------080804050409020005090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/19/2013 10:55 PM, Suhas Nandakumar wrote: > Regarding a=ssrc comment above, > The text from RFC5576 says this > > Each "ssrc" media attribute specifies a single source-level attribute > for the given . For each source mentioned in SDP, the > source-level attribute "cname", defined inSection 6.1 , MUST be > provided. Any number of other source-level attributes for the source > MAY also be provided. > given the above, would it be cname attribute for a given ssrc that should be mandated at the minimum ? Thanks, that makes sense to me. Updating JSEP to say "add a line with a=ssrc cname=" sounds like something that does what we want and is consistent with 5576. > > > > Cheers > Suhas > > > On Thu, Sep 19, 2013 at 5:54 AM, Harald Alvestrand > > wrote: > > I'm sure we'll have lots of things to discuss about JSEP. I just > thought I'd get these out of the way. > > - Usage of MSID. In addition to the a=msid: lines, the > session-level generation procedure needs to say that a line > "a=msid-semantic:WMS " is added to the session-level > description, containing the IDs of the MediaStreams that are > signalled. > > - a=ssrc lines. The spec (5.2.1 second list last bullet) simply > says "an a=ssrc line". But RFC 5576 specifies that all ssrc lines > contain an attribute. Suggestion: define one that does no harm > (role=primary?) > > - recycling of m= lines. The section in 5.2.2 (subsequent offers) > that talks about this doesn't mention that the media in the m-line > has to match, although section 5.3.1 (initial answer) actually > talks about it. I'm assuming that's an oversight. > > I'd suggest pulling the language about "selecting an appropriate > m-line for a track" out in a separate subsection, so that we have > one place to point to for this. > > Out of time, let's get these ones out of the way for -05.... > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------080804050409020005090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/19/2013 10:55 PM, Suhas Nandakumar wrote:
Regarding a=ssrc comment above,
The text from RFC5576 says this  

Each "ssrc" media attribute specifies a single source-level attribute
   for the given <ssrc-id>.  For each source mentioned in SDP, the
   source-level attribute "cname", defined in Section 6.1, MUST be
   provided.  Any number of other source-level attributes for the source
   MAY also be provided.

          

          
given the above, would it be cname attribute for a given ssrc that should be mandated at the minimum ?

        

      

    

    

    Thanks, that makes sense to me. Updating JSEP to
      say "add a line with a=ssrc cname=<cname>" sounds like
      something that does what we want and is consistent with 5576.

    

      

        

          



          




          
Cheers

          
Suhas

          

          

        

      

      

        

        

        
On Thu, Sep 19, 2013 at 5:54 AM, Harald
          Alvestrand <harald@alvestrand.no>
          wrote:

          

            I'm sure we'll have lots of things to discuss about JSEP. I
            just thought I'd get these out of the way.

            

            - Usage of MSID. In addition to the a=msid: lines, the
            session-level generation procedure needs to say that a line
            "a=msid-semantic:WMS <id>" is added to the
            session-level description, containing the IDs of the
            MediaStreams that are signalled.

            

            - a=ssrc lines. The spec (5.2.1 second list last bullet)
            simply says "an a=ssrc line". But RFC 5576 specifies that
            all ssrc lines contain an attribute. Suggestion: define one
            that does no harm (role=primary?)

            

            - recycling of m= lines. The section in 5.2.2 (subsequent
            offers) that talks about this doesn't mention that the media
            in the m-line has to match, although section 5.3.1 (initial
            answer) actually talks about it. I'm assuming that's an
            oversight.

            

            I'd suggest pulling the language about "selecting an
            appropriate m-line for a track" out in a separate
            subsection, so that we have one place to point to for this.

            

            Out of time, let's get these ones out of the way for -05....

            

            

            

            _______________________________________________

            rtcweb mailing list

            rtcweb@ietf.org

            https://www.ietf.org/mailman/listinfo/rtcweb

          

        

        

      

    

    

  


--------------080804050409020005090004--

From harald@alvestrand.no  Thu Sep 19 15:22:38 2013
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 3580721F8948 for ; Thu, 19 Sep 2013 15:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.698
X-Spam-Level: 
X-Spam-Status: No, score=-108.698 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq2j9SVqkCmN for ; Thu, 19 Sep 2013 15:22:34 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B795C21F893E for ; Thu, 19 Sep 2013 15:22:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFD3D39E1B7 for ; Fri, 20 Sep 2013 00:22:31 +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 MratdqsbNtLJ for ; Fri, 20 Sep 2013 00:22:30 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1] (unknown [IPv6:2001:470:de0a:27:903a:6934:230b:9fc1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 903A639E04F for ; Fri, 20 Sep 2013 00:22:30 +0200 (CEST)
Message-ID: <523B797C.7040603@alvestrand.no>
Date: Fri, 20 Sep 2013 00:23:56 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se>,  <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080704040205040904050802"
Subject: Re: [rtcweb] m=section recycling and a=mid
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, 19 Sep 2013 22:22:38 -0000

This is a multi-part message in MIME format.
--------------080704040205040904050802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I suggest that changing the MID value can be very painful, since it 
modifies the mapping between m-line index and MID.

Is there any other spec that describes changing the MID value?

If not, I'd suggest that we explicitly forbid changing the MID value. If 
we want to add or remove an M-line from a bundle, we should update the 
bundles instead.


On 09/19/2013 08:52 PM, Christer Holmberg wrote:
>
> Correct.
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Suhas Nandakumar [suhasietf@gmail.com]
> *Sent:* Thursday, 19 September 2013 9:48 PM
> *To:* Christer Holmberg
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] m=section recycling and a=mid
>
> Hello Christer
>
>   Completely agree with you
>
> My point with the above examples was
>
>   "recycling of m=line should take into account its existing BUNDLE 
> membership and JS user's preference on requiring the added media track 
> to be BUNDLED or not"
>
> This would imply, as suggested by you,
>
>   - remove the mid from a=group:BUNDLE line if the JS user doesn't 
> want the new track to be BUNDLEd
>
>  - or if the mid value is changed, then add the new mid value to the 
> BUNDLE group if the JS user want's the new track to be BUNDLED
>
> - or just retain the mid value and its BUNDLE membership for the new 
> track, if it is going to be BUNDLEd
>
>
> Cheers
> Suhas
>
>
>
>
>
>
>
> On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg 
>  > wrote:
>
>     Hi Suhas,
>
>     The mid attribute itself does not add an m- line to a BUNDLE
>     group. The attribute value also needs to be listed in the
>     group:BUNDLE attribute mid list.
>
>     So, if you want to re-use an m- line and mid attribute, but you
>     don't want the m- line to be in the BUNDLE group, simply remove
>     the mid from the mid list.
>
>     Regards,
>
>     Christer
>
>     ------------------------------------------------------------------------
>     *From:* rtcweb-bounces@ietf.org 
>     [rtcweb-bounces@ietf.org ] on
>     behalf of Suhas Nandakumar [suhasietf@gmail.com
>     ]
>     *Sent:* Wednesday, 18 September 2013 7:44 PM
>     *To:* rtcweb@ietf.org 
>     *Subject:* [rtcweb] m=section recycling and a=mid
>
>     After thinking about it a bit, I think there are some side effects
>     associated with changing/not changing mid attribute of a re-cycled
>     m= section and it being part of a BUNDLE group or not..
>
>     example
>
>     say , we have these video m=section part of BUNDLE group as below
>     a=group:BUNDLE 1, 2
>
>     m=video .....
>     a=mid:1
>     a=inactive
>
>     m=video .....
>     a=mid:2
>     a=sendrecv
>
>     Now If JS user adds a new video track and he wants it to be out of
>     BUNDLE. If we recycle first video m=section and dont change mid
>     attribute,  we end up BUNDLing even if the user dint want to
>
>     On the other hand, if we allowed mid value to be changed, we might
>     end up UNBundling a video stream , when the user did want to
>     BUNDLE them
>
>     So allowing a mid value to be changed or not should be tied to
>     what the JS API is asking on behalf of the user
>
>
>     Any thoughts ?
>
>     Cheers
>     Suhas
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------080704040205040904050802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I suggest that changing the MID value
      can be very painful, since it modifies the mapping between m-line
      index and MID.

      

      Is there any other spec that describes changing the MID value?

      

      If not, I'd suggest that we explicitly forbid changing the MID
      value. If we want to add or remove an M-line from a bundle, we
      should update the bundles instead.

      

      

      On 09/19/2013 08:52 PM, Christer Holmberg wrote:

    

    

      
      
      

        
Correct.

        
 

        
Regards,

        
 

        
Christer

        

          

          
From: Suhas
              Nandakumar [suhasietf@gmail.com]

              Sent: Thursday, 19 September 2013 9:48 PM

              To: Christer Holmberg

              Cc: rtcweb@ietf.org

              Subject: Re: [rtcweb] m=section recycling and a=mid

            

          

          

            
Hello Christer
              


              

              
  Completely agree with you

              


              

              
My point with the above examples was 

              


              

              
  "recycling of m=line should take into account its
                existing BUNDLE membership and JS user's preference on
                requiring the added media track to be BUNDLED or not"

              


              

              
This would imply, as suggested by you,

              


              

              
  - remove the mid from a=group:BUNDLE line if the JS
                user doesn't want the new track to be BUNDLEd

              


              

              
 - or if the mid value is changed, then add the new
                mid value to the BUNDLE group if the JS user want's the
                new track to be BUNDLED

              


              

              
- or just retain the mid value and its BUNDLE
                membership for the new track, if it is going to be
                BUNDLEd

              


              

              


              

              
Cheers

              
Suhas

              


              

              


              

              


              

              


              

              


              

            

            


              

              
On Thu, Sep 19, 2013 at 9:24 AM,
                Christer Holmberg 
                  <christer.holmberg@ericsson.com>
                wrote:

                

                  

                    

                      
Hi Suhas,

                      
 

                      
The mid attribute itself does not add an m-
                        line to a BUNDLE group. The attribute value also
                        needs to be listed in the group:BUNDLE attribute
                        mid list.

                      
 

                      
So, if you want to re-use an m- line and mid
                        attribute, but you don't want the m- line to be
                        in the BUNDLE group, simply remove the mid from
                        the mid list.

                      
 

                      
Regards,

                      
 

                      
Christer

                      
 

                      

                        

                        
From: 
                              rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org]
                            on behalf of Suhas Nandakumar [suhasietf@gmail.com]

                            Sent: Wednesday, 18 September 2013
                            7:44 PM

                            To: rtcweb@ietf.org

                            Subject: [rtcweb] m=section recycling
                            and a=mid

                          

                        

                        

                          

                            

                              
After thinking about it a
                                bit, I think there are some side effects
                                associated with changing/not changing
                                mid attribute of a re-cycled m= section
                                and it being part of a BUNDLE group or
                                not..
                                


                                

                                
example

                                


                                

                                
say , we have these video m=section
                                  part of BUNDLE group as below 

                                
a=group:BUNDLE 1, 2

                                


                                

                                
m=video .....

                                
a=mid:1 

                                
a=inactive

                                


                                

                                

                                  
m=video .....

                                  
a=mid:2 

                                  
a=sendrecv

                                  


                                  

                                  
Now If JS user adds a new video
                                    track and he wants it to be out of
                                    BUNDLE. If we recycle first video
                                    m=section and dont change mid
                                    attribute,  we end up BUNDLing even
                                    if the user dint want to

                                  


                                  

                                  
On the other hand, if we allowed
                                    mid value to be changed, we might
                                    end up UNBundling a video stream ,
                                    when the user did want to BUNDLE
                                    them

                                  


                                  

                                  
So allowing a mid value to be
                                    changed or not should be tied to
                                    what the JS API is asking on behalf
                                    of the user

                                

                                


                                

                                


                                

                                
Any thoughts ?

                                


                                

                                
Cheers

                                
Suhas

                                


                                

                                


                                

                              

                            

                          

                        

                      

                    

                  

                

              

              

            

          

        

      

      

      

      

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


    

    

  


--------------080704040205040904050802--

From suhasietf@gmail.com  Thu Sep 19 15:25:13 2013
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 5F6F021F89A5 for ; Thu, 19 Sep 2013 15:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.11
X-Spam-Level: 
X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-1.111,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emHy2jEn6rpP for ; Thu, 19 Sep 2013 15:25:12 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21721F898A for ; Thu, 19 Sep 2013 15:25:11 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id ex4so8731350wid.14 for ; Thu, 19 Sep 2013 15:25: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=JRg7/6IkHWnjI/u6J95QhXIWnk8DxEoQKkGhw59LNGs=; b=cgdnUZlV4Ii5S8maxV/IUNOhSfLFeTWEXmvwMpLP/uvLczQTecuS3orlPRylsXgjBU HDJiZSJwwakLmwhJLNG3+ljrk5uUQy2mrlCshm3/ci34jk3ui1nNNEMXFaJzW4BTg7ST k5j5i8CIrcZmjkB9tHGasvF4RrKPxDHwSnc7zpQvSwVelEFuDaqL+4dVyEA1t9qMATqW bd68Y9GJQctYThg0A8VVCJb5JL7It/NH54nHfcJh7IiLK+KG/UUHNylaYJlAn12JpuAj t7e/Wj0p212JFSF7vzltS9NjIR2bOx3NTHeOgwXh0c80NcZKnjXwyajpCuXjSVpA/jav MZvQ==
MIME-Version: 1.0
X-Received: by 10.180.73.65 with SMTP id j1mr278804wiv.10.1379629509506; Thu, 19 Sep 2013 15:25:09 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Thu, 19 Sep 2013 15:25:09 -0700 (PDT)
In-Reply-To: <523B797C.7040603@alvestrand.no>
References:  <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se> <523B797C.7040603@alvestrand.no>
Date: Thu, 19 Sep 2013 15:25:09 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=f46d04389087d5f9c504e6c406be
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] m=section recycling and a=mid
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, 19 Sep 2013 22:25:13 -0000

--f46d04389087d5f9c504e6c406be
Content-Type: text/plain; charset=ISO-8859-1

+1


On Thu, Sep 19, 2013 at 3:23 PM, Harald Alvestrand wrote:

>  I suggest that changing the MID value can be very painful, since it
> modifies the mapping between m-line index and MID.
>
> Is there any other spec that describes changing the MID value?
>
> If not, I'd suggest that we explicitly forbid changing the MID value. If
> we want to add or remove an M-line from a bundle, we should update the
> bundles instead.
>
>
>
> On 09/19/2013 08:52 PM, Christer Holmberg wrote:
>
>  Correct.
>
>
>
> Regards,
>
>
>
> Christer
>  ------------------------------
> *From:* Suhas Nandakumar [suhasietf@gmail.com]
> *Sent:* Thursday, 19 September 2013 9:48 PM
> *To:* Christer Holmberg
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] m=section recycling and a=mid
>
>  Hello Christer
>
>    Completely agree with you
>
>  My point with the above examples was
>
>    "recycling of m=line should take into account its existing BUNDLE
> membership and JS user's preference on requiring the added media track to
> be BUNDLED or not"
>
>  This would imply, as suggested by you,
>
>    - remove the mid from a=group:BUNDLE line if the JS user doesn't want
> the new track to be BUNDLEd
>
>   - or if the mid value is changed, then add the new mid value to the
> BUNDLE group if the JS user want's the new track to be BUNDLED
>
>  - or just retain the mid value and its BUNDLE membership for the new
> track, if it is going to be BUNDLEd
>
>
>  Cheers
> Suhas
>
>
>
>
>
>
>
> On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>>  Hi Suhas,
>>
>>
>>
>> The mid attribute itself does not add an m- line to a BUNDLE group. The
>> attribute value also needs to be listed in the group:BUNDLE attribute mid
>> list.
>>
>>
>>
>> So, if you want to re-use an m- line and mid attribute, but you don't
>> want the m- line to be in the BUNDLE group, simply remove the mid from the
>> mid list.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>  ------------------------------
>> *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of
>> Suhas Nandakumar [suhasietf@gmail.com]
>> *Sent:* Wednesday, 18 September 2013 7:44 PM
>> *To:* rtcweb@ietf.org
>> *Subject:* [rtcweb] m=section recycling and a=mid
>>
>>   After thinking about it a bit, I think there are some side effects
>> associated with changing/not changing mid attribute of a re-cycled m=
>> section and it being part of a BUNDLE group or not..
>>
>>  example
>>
>>  say , we have these video m=section part of BUNDLE group as below
>> a=group:BUNDLE 1, 2
>>
>>  m=video .....
>> a=mid:1
>> a=inactive
>>
>>  m=video .....
>> a=mid:2
>> a=sendrecv
>>
>>  Now If JS user adds a new video track and he wants it to be out of
>> BUNDLE. If we recycle first video m=section and dont change mid attribute,
>>  we end up BUNDLing even if the user dint want to
>>
>>  On the other hand, if we allowed mid value to be changed, we might end
>> up UNBundling a video stream , when the user did want to BUNDLE them
>>
>>  So allowing a mid value to be changed or not should be tied to what the
>> JS API is asking on behalf of the user
>>
>>
>>  Any thoughts ?
>>
>>  Cheers
>> Suhas
>>
>>
>>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--f46d04389087d5f9c504e6c406be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1


On Thu, Sep 19, 2013 at 3:23 PM, Harald Alvestrand <harald@=
alvestrand.no> wrote:



 =20
   =20
 =20
  

    
I suggest that changing the MID value
      can be very painful, since it modifies the mapping between m-line
      index and MID.

      

      Is there any other spec that describes changing the MID value?

      

      If not, I'd suggest that we explicitly forbid changing the MID
      value. If we want to add or remove an M-line from a bundle, we
      should update the bundles instead.


      

      

      On 09/19/2013 08:52 PM, Christer Holmberg wrote:

    

    

     =20
     =20
      

        
Correct.

        
=A0

        
Regards,

        
=A0

        
Christer

        

          

          
From: Suhas
              Nandakumar [suhasietf@gmail.com]

              Sent: Thursday, 19 September 2013 9:48 PM

              To: Christer Holmberg

              Cc: rtcweb@ietf.org

              Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmi=
d

            

          

          

            
Hello Christer
              


              

              
=A0 Completely agree with you

              


              

              
My point with the above examples was=A0

              


              

              
=A0 "recycling of m=3Dline should take into account=
 its
                existing BUNDLE membership and JS user's preference on
                requiring the added media track to be BUNDLED or not"<=
/div>
              


              

              
This would imply, as suggested by you,

              


              

              
=A0 - remove the mid from a=3Dgroup:BUNDLE line if the J=
S
                user doesn't want the new track to be BUNDLEd

              


              

              
=A0- or if the mid value is changed, then add the new
                mid value to the BUNDLE group if the JS user want's the
                new track to be BUNDLED

              


              

              
- or just retain the mid value and its BUNDLE
                membership for the new track, if it is going to be
                BUNDLEd

              


              

              


              

              
Cheers

              
Suhas

              


              

              


              

              


              

              


              

              


              

            

            


              

              
On Thu, Sep 19, 2013 at 9:24 AM,
                Christer Holmberg 
                  <christer.holmberg@ericsson.com>
                wrote:

                

                  

                    

                      
Hi Suhas,

                      
=A0

                      
The mid attribute itself does not add an m-
                        line to a BUNDLE group. The attribute value also
                        needs to be listed in the group:BUNDLE attribute
                        mid list.

                      
=A0

                      
So, if you want to re-use an m- line and mid
                        attribute, but you don't want the m- line to be
                        in the BUNDLE group, simply remove the mid from
                        the mid list.

                      
=A0

                      
Regards,

                      
=A0

                      
Christer

                      
=A0

                      

                        

                        
From: 
                              rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org]
                            on behalf of Suhas Nandakumar [suhasietf@gmail.com]

                            Sent: Wednesday, 18 September 2013
                            7:44 PM

                            To: rtcweb@ietf.org

                            Subject: [rtcweb] m=3Dsection recycling
                            and a=3Dmid

                          

                        

                        

                          

                            

                              
After thinking about it a
                                bit, I think there are some side effects
                                associated with changing/not changing
                                mid attribute of a re-cycled m=3D section
                                and it being part of a BUNDLE group or
                                not..
                                


                                

                                
example

                                


                                

                                
say , we have these video m=3Dsection
                                  part of BUNDLE group as below=A0

                                
a=3Dgroup:BUNDLE 1, 2

                                


                                

                                
m=3Dvideo .....

                                
a=3Dmid:1=A0

                                
a=3Dinactive

                                


                                

                                

                                  
m=3Dvideo .....

                                  
a=3Dmid:2=A0

                                  
a=3Dsendrecv

                                  


                                  

                                  
Now If JS user adds a new video
                                    track and he wants it to be out of
                                    BUNDLE. If we recycle first video
                                    m=3Dsection and dont change mid
                                    attribute, =A0we end up BUNDLing even
                                    if the user dint want to

                                  


                                  

                                  
On the other hand, if we allowed
                                    mid value to be changed, we might
                                    end up UNBundling a video stream ,
                                    when the user did want to BUNDLE
                                    them

                                  


                                  

                                  
So allowing a mid value to be
                                    changed or not should be tied to
                                    what the JS API is asking on behalf
                                    of the user

                                

                                


                                

                                


                                

                                
Any thoughts ?

                                


                                

                                
Cheers

                                
Suhas

                                


                                

                                


                                

                              

                            

                          

                        

                      

                    

                  

                

              

              

            

          

        

      

      

      

      

      
_______________________________________________
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





--f46d04389087d5f9c504e6c406be--

From magnus.westerlund@ericsson.com  Thu Sep 19 23:01:50 2013
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 395C221F878F for ; Thu, 19 Sep 2013 23:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.212
X-Spam-Level: 
X-Spam-Status: No, score=-105.212 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4hflMZMVhTd for ; Thu, 19 Sep 2013 23:01:45 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1421F846E for ; Thu, 19 Sep 2013 23:01:44 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-93-523be4c5bde7
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D8.2D.22048.5C4EB325; Fri, 20 Sep 2013 08:01:42 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 08:01:38 +0200
Message-ID: <523BE4DB.5030800@ericsson.com>
Date: Fri, 20 Sep 2013 08:02:03 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "rtcweb@ietf.org" , Harald Alvestrand , =?windows-1252?Q?=22Stefan_H=E5kansson_LK_=28LU/EAB=29=22?= 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje6xJ9ZBBicvMlucuHGa2WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAldEz/StLwWTuinsTdjM2MK7m7GLk5JAQMJE4 fGEZM4QtJnHh3nq2LkYuDiGBw4wSU08tYoVwljNK3H1/kwmkildAW6JjyjqwDhYBVYlr/+ey gdhsAhYSN380gtmiAsES7du/skHUC0qcnPmEBWSQiMB6RonPD+cwgiSEBdwlfl+cww6xWlJi 26JjYDazgIHEkUVzWCFseYnmrbPBlgkBLW5o6mCdwMg/C8ncWUhaZiFpWcDIvIqRPTcxMye9 3HwTIzDIDm75bbCDcdN9sUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg XFPkwNH59N/U+WWm55f4Z1U9XHf5zFfbj4t2hBddDs9ZIli3XVLnWBgz6+KFb05/nRITWHZF LWb+/k92wZz1z9zN++709FtuWaN/Tr7Lb+NZqZ/5954YZCgdj6y3l56z52bfS8k94o75Op61 71tSY/eGFU9XbCpZu6os+yrHCQ2GuqCzHYoflViKMxINtZiLihMBetVWLQACAAA=
Subject: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
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, 20 Sep 2013 06:01:50 -0000

WG,

In the JSEP call I commented regarding a=imageattr open issue that we
had an original agreement from over a year ago (Vancouver) to go with
Harald's proposal in then
http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt

This is documented in the minutes:
http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb


However, I did forget to note that there has been discussion on this
issue after that between Harald Alvestrand and Stefan Håkansson
primarily on the W3C list

http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html

Where they are seriously discussing only using WebRTC API for this.

It is in the context of
https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution/

Thus I would like to point out that there appear to be some indication
of desire move away from the consensus last year.

Thus it appears that this topic may require some further discussion.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From christer.holmberg@ericsson.com  Thu Sep 19 23:47:47 2013
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 46FC821F8790 for ; Thu, 19 Sep 2013 23:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.235
X-Spam-Level: 
X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0naLYaFmXwC for ; Thu, 19 Sep 2013 23:47:42 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5323021F8443 for ; Thu, 19 Sep 2013 23:47:41 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-49-523bef8b40b0
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.A2.22048.B8FEB325; Fri, 20 Sep 2013 08:47:40 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 08:47:38 +0200
From: Christer Holmberg 
To: Suhas Nandakumar , Harald Alvestrand 
Thread-Topic: [rtcweb] m=section recycling and a=mid
Thread-Index: AQHOtI5OlzgN5l68MU+Yf86f9mtTsJnNP/0ZgAAG7ICAACKcC4AAGbIAgAAAV4CAAK3l0A==
Date: Fri, 20 Sep 2013 06:47:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A82DF@ESESSMB209.ericsson.se>
References:  <7594FB04B1934943A5C02806D1A2204B1C4A7F29@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4A800E@ESESSMB209.ericsson.se> <523B797C.7040603@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A82DFESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvjW7Pe+sgg+dtPBbH+rrYLNb+a2e3 2Dm3g9mB2ePKhCusHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxtrLUgWrJjNW/Pmh38C4 s4Gxi5GTQ0LAROLs/XssELaYxIV769m6GLk4hAQOM0rsbX/PBOEsYZRY9PI7excjBwebgIVE 9z9tkAYRgTCJzncb2EBsZgF1iTuLz7GD2MICxhILn/1igagxkdg1dw0bTH3/sU1gi1kEVCU6 Dj5kArF5BXwlDi/dCrW4k1ni1qqnYM2cAoESHXtmgg1lBLru+6k1TBDLxCVuPZnPBHG1gMSS PeeZIWxRiZeP/7GC3CkhoCixvF8Oojxf4uP5JSwQuwQlTs58wjKBUXQWkkmzkJTNQlIGEdeR WLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXm29iBMbZwS2/DXYwbrovdohRmoNF SZx3s96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MDPpvzqjo/fR5F57vHey43r5EceFH xpjdf9VnxXoFlil8uSWYLtBlq1Af5823WnSRituyGimf6ypv1h1rWZeZvrglyFuC29o3YPq5 uJ/2n48e37k29xZ3zLczvAbBXQlrggOv34mTuGwg0CNYNF/lNbPu5kMXyk7MWh/D0Zxc+69X +ufX5xJKLMUZiYZazEXFiQBDHg8EgQIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] m=section recycling and a=mid
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, 20 Sep 2013 06:47:47 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4A82DFESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Suhas Nandakumar
Sent: 20. syyskuuta 2013 1:25
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid

+1

On Thu, Sep 19, 2013 at 3:23 PM, Harald Alvestrand > wrote:
I suggest that changing the MID value can be very painful, since it modifie=
s the mapping between m-line index and MID.

Is there any other spec that describes changing the MID value?

If not, I'd suggest that we explicitly forbid changing the MID value. If we=
 want to add or remove an M-line from a bundle, we should update the bundle=
s instead.



On 09/19/2013 08:52 PM, Christer Holmberg wrote:

Correct.



Regards,



Christer

________________________________
From: Suhas Nandakumar [suhasietf@gmail.com]
Sent: Thursday, 19 September 2013 9:48 PM
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid
Hello Christer

  Completely agree with you

My point with the above examples was

  "recycling of m=3Dline should take into account its existing BUNDLE membe=
rship and JS user's preference on requiring the added media track to be BUN=
DLED or not"

This would imply, as suggested by you,

  - remove the mid from a=3Dgroup:BUNDLE line if the JS user doesn't want t=
he new track to be BUNDLEd

 - or if the mid value is changed, then add the new mid value to the BUNDLE=
 group if the JS user want's the new track to be BUNDLED

- or just retain the mid value and its BUNDLE membership for the new track,=
 if it is going to be BUNDLEd


Cheers
Suhas






On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg > wrote:

Hi Suhas,



The mid attribute itself does not add an m- line to a BUNDLE group. The att=
ribute value also needs to be listed in the group:BUNDLE attribute mid list=
.



So, if you want to re-use an m- line and mid attribute, but you don't want =
the m- line to be in the BUNDLE group, simply remove the mid from the mid l=
ist.



Regards,



Christer



________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounc=
es@ietf.org] on behalf of Suhas Nandakumar =
[suhasietf@gmail.com]
Sent: Wednesday, 18 September 2013 7:44 PM
To: rtcweb@ietf.org
Subject: [rtcweb] m=3Dsection recycling and a=3Dmid
After thinking about it a bit, I think there are some side effects associat=
ed with changing/not changing mid attribute of a re-cycled m=3D section and=
 it being part of a BUNDLE group or not..

example

say , we have these video m=3Dsection part of BUNDLE group as below
a=3Dgroup:BUNDLE 1, 2

m=3Dvideo .....
a=3Dmid:1
a=3Dinactive

m=3Dvideo .....
a=3Dmid:2
a=3Dsendrecv

Now If JS user adds a new video track and he wants it to be out of BUNDLE. =
If we recycle first video m=3Dsection and dont change mid attribute,  we en=
d up BUNDLing even if the user dint want to

On the other hand, if we allowed mid value to be changed, we might end up U=
NBundling a video stream , when the user did want to BUNDLE them

So allowing a mid value to be changed or not should be tied to what the JS =
API is asking on behalf of the user


Any thoughts ?

Cheers
Suhas





_______________________________________________

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


--_000_7594FB04B1934943A5C02806D1A2204B1C4A82DFESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











+1<=
/p>

 <=
/p>

From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Suhas Nandakumar

Sent: 20. syyskuuta 2013 1:25

To: Harald Alvestrand

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid


 




+1






 




On Thu, Sep 19, 2013 at 3:23 PM, Harald Alvestrand &=
lt;harald@alvestr=
and.no> wrote:






I suggest that changing the MID value can be very pa=
inful, since it modifies the mapping between m-line index and MID.



Is there any other spec that describes changing the MID value?



If not, I'd suggest that we explicitly forbid changing the MID value. If we=
 want to add or remove an M-line from a bundle, we should update the bundle=
s instead.












On 09/19/2013 08:52 PM, Christer Holmberg wrote:
















Correct.


 


Regards,


 


Christer












From: Suhas Nandakumar [suhasietf@gmail.com]

Sent: Thursday, 19 September 2013 9:48 PM

To: Christer Holmberg

Cc: rtcweb@ietf=
.org

Subject: Re: [rtcweb] m=3Dsection recycling and a=3Dmid<=
/o:p>








Hello Christer 




 






  Completely agree with you






 






My point with the above examples was 






 






  "recycling of m=3Dline should take into =
account its existing BUNDLE membership and JS user's preference on requirin=
g the added media track to be BUNDLED or not"






 






This would imply, as suggested by you,





 






  - remove the mid from a=3Dgroup:BUNDLE line i=
f the JS user doesn't want the new track to be BUNDLEd






 






 - or if the mid value is changed, then add the=
 new mid value to the BUNDLE group if the JS user want's the new track to b=
e BUNDLED






 






- or just retain the mid value and its BUNDLE member=
ship for the new track, if it is going to be BUNDLEd






 






 






Cheers






Suhas






 






 






 






 






 








 




On Thu, Sep 19, 2013 at 9:24 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:






Hi Suhas,


 


The mid attribute itself does not add an m- line to a BUNDLE=
 group. The attribute value also needs to be listed in the group:BUNDLE att=
ribute mid list.


 


So, if you want to re-use an m- line and mid attribute, but =
you don't want the m- line to be in the BUNDLE group, simply remove the mid=
 from the mid list.


 


Regards,


 


Christer


 












From:
rtcweb-bounces=
@ietf.org [rtcweb-bounces@ietf.org] on behalf of Suhas Nandakumar [suhasietf@gmail.com]

Sent: Wednesday, 18 September 2013 7:44 PM

To: rtcweb@ietf=
.org

Subject: [rtcweb] m=3Dsection recycling and a=3Dmid












After thinking about it a bit, I think there are som=
e side effects associated with changing/not changing mid attribute of a re-=
cycled m=3D section and it being part of a BUNDLE group or not..





 






example






 






say , we have these video m=3Dsection part of BUNDLE=
 group as below 






a=3Dgroup:BUNDLE 1, 2






 






m=3Dvideo .....






a=3Dmid:1 






a=3Dinactive






 








m=3Dvideo .....






a=3Dmid:2 






a=3Dsendrecv






 






Now If JS user adds a new video track and he wants i=
t to be out of BUNDLE. If we recycle first video m=3Dsection and dont chang=
e mid attribute,  we end up BUNDLing even if the user dint want to






 






On the other hand, if we allowed mid value to be cha=
nged, we might end up UNBundling a video stream , when the user did want to=
 BUNDLE them






 






So allowing a mid value to be changed or not should =
be tied to what the JS API is asking on behalf of the user








 






 






Any thoughts ?






 






Cheers






Suhas






 






 




















 










 






_______________________________________________


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




 








--_000_7594FB04B1934943A5C02806D1A2204B1C4A82DFESESSMB209erics_--

From harald@alvestrand.no  Fri Sep 20 00:25:28 2013
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 BF7A621F89FF for ; Fri, 20 Sep 2013 00:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level: 
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAw5Uy6U71s2 for ; Fri, 20 Sep 2013 00:25:24 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F0BA421F8443 for ; Fri, 20 Sep 2013 00:25:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 688DA39E1A6 for ; Fri, 20 Sep 2013 09:25: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 kCrru3VGmeWx for ; Fri, 20 Sep 2013 09:25:20 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BC44739E0D9 for ; Fri, 20 Sep 2013 09:25:20 +0200 (CEST)
Message-ID: <523BF860.1090105@alvestrand.no>
Date: Fri, 20 Sep 2013 09:25:20 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <523BE4DB.5030800@ericsson.com>
In-Reply-To: <523BE4DB.5030800@ericsson.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
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, 20 Sep 2013 07:25:28 -0000

On 09/20/2013 08:02 AM, Magnus Westerlund wrote:
> WG,
>
> In the JSEP call I commented regarding a=imageattr open issue that we
> had an original agreement from over a year ago (Vancouver) to go with
> Harald's proposal in then
> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt
>
> This is documented in the minutes:
> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb
>
>
> However, I did forget to note that there has been discussion on this
> issue after that between Harald Alvestrand and Stefan Håkansson
> primarily on the W3C list
>
> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html
>
> Where they are seriously discussing only using WebRTC API for this.
>
> It is in the context of
> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution/
>
> Thus I would like to point out that there appear to be some indication
> of desire move away from the consensus last year.

My thinking is that there are 3 points on the spectrum of solutions:

- Constraints at source only (the approach most thoroughly described in
draft-alvestrand-constraints-resolution).

- Constraints at destination can be sigalled in SDP, and acted on at
source (described in draft-alvestrand-rtcweb-resolution). This spec
could not be pursued as long as the "Plan X" discussions were still
unsettled, but now it should really be "a piece of cake".

- Defining a new way of signalling. This was the approach rejected in
Vancouver.

Formalistically, if the IETF decides to offer a well defined mechanism
for negotiating resolution through SDP, the W3C will certainly take up
the discussion on whether or not we should connect the API to that
functionality.

Happy to discuss more.


From internet-drafts@ietf.org  Fri Sep 20 00:33:31 2013
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 A630121F89FF; Fri, 20 Sep 2013 00:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2snd+wLxY7vD; Fri, 20 Sep 2013 00:33:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7621F84D0; Fri, 20 Sep 2013 00:33:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.71.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130920073331.2144.40500.idtracker@ietfa.amsl.com>
Date: Fri, 20 Sep 2013 00:33:31 -0700
Cc: rtcweb@ietf.org
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Sep 2013 07:33:31 -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           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Ram Mohan Ravindranath
                          Tirumaleswar Reddy
	Filename        : draft-ietf-rtcweb-stun-consent-freshness-00.txt
	Pages           : 7
	Date            : 2013-09-19

Abstract:
   Verification of peer consent before sending traffic is necessary in
   WebRTC deployments to ensure that a malicious JavaScript cannot use
   the browser as a platform for launching attacks.  A related problem
   is session liveness.  WebRTC application may want to detect
   connection failure and take appropriate action.

   This document describes how a WebRTC browser can verify peer consent
   to continue sending traffic and detect connection failure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ietf-secretariat-reply@ietf.org  Fri Sep 20 00:48:27 2013
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 E019C21F8C3E for ; Fri, 20 Sep 2013 00:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRIMofy-9ocA for ; Fri, 20 Sep 2013 00:48:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDCA21F8C7C for ; Fri, 20 Sep 2013 00:48:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.71.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130920074827.27426.48610.idtracker@ietfa.amsl.com>
Date: Fri, 20 Sep 2013 00:48:27 -0700
From: IETF Secretariat 
Subject: [rtcweb] Milestones changed for rtcweb WG
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Sep 2013 07:48:28 -0000

Changed milestone "Send STUN Usage for Consent Freshness to IESG for
publication as proposed standard", added
draft-ietf-rtcweb-stun-consent-freshness to milestone.

URL: http://datatracker.ietf.org/wg/rtcweb/charter/

From christer.holmberg@ericsson.com  Fri Sep 20 00:51:53 2013
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 3323A21F8A38 for ; Fri, 20 Sep 2013 00:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.715
X-Spam-Level: 
X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[AWL=0.534,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIxX5Wqd8dM8 for ; Fri, 20 Sep 2013 00:51:46 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 986CC21F89FF for ; Fri, 20 Sep 2013 00:51:44 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-bc-523bfe8a0df1
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 71.2F.03802.A8EFB325; Fri, 20 Sep 2013 09:51:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 09:51:38 +0200
From: Christer Holmberg 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.txt
Thread-Index: AQHOtdO3VyArQTGsZUKmwLiEhG8nLZnOPdbA
Date: Fri, 20 Sep 2013 07:51:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A83EA@ESESSMB209.ericsson.se>
References: <20130920073331.2144.40500.idtracker@ietfa.amsl.com>
In-Reply-To: <20130920073331.2144.40500.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW7XP+sggyfbzSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvnJ/9kL9gtWnG/8xdLAeJO3i5GTQ0LARGLu56VsELaYxIV7 64FsLg4hgcOMEkfm3GSHcJYwSsy7/wfI4eBgE7CQ6P6nDdIgIqAucfnhBXYQW1ggWKLj3lcm iHiIxJqjnWwQtpHE+zW9zCA2i4CqRPfD98wgY3gFfCXWH4oCCQsJOEh0zJ/LCGJzCjhKHF5+ kwXEZgS65/upNWAjmQXEJW49mc8EcaeAxJI955khbFGJl4//sYKMlBBQlFjeLwdRriOxYPcn NghbW2LZwtdg5bwCghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAkD+4 5bfqDsY750QOMUpzsCiJ827WOxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHy3fz8K+e6 rDc9EPvi82hW7uuwiMq38x1uR786Nftr1U5f/0XXtv9+dPZ1dW0zg5vJle6eaS8rbwjMtHxz aNe88KKM7aX15VUK735kBO7a9y3i6dZd03001Svn5pRYKP4yjv8n+mM6t+mCLsPaU5071l7g eRvDP5/13LKAI69VjrG53lGd/sdYiaU4I9FQi7moOBEAVqVVD0cCAAA=
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-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, 20 Sep 2013 07:51:53 -0000

Hi,

The draft doesn't mention the case when one entity (e.g. a gateway) is ICE =
lite. Eventhough ICE already specifies that an ICE lite entity does not sen=
d STUN requests, I think it would be good to cover it also for consent refr=
eshness.

Regards,

Christer

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 internet-drafts@ietf.org
Sent: 20. syyskuuta 2013 10:34
To: i-d-announce@ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.t=
xt


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           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Ram Mohan Ravindranath
                          Tirumaleswar Reddy
	Filename        : draft-ietf-rtcweb-stun-consent-freshness-00.txt
	Pages           : 7
	Date            : 2013-09-19

Abstract:
   Verification of peer consent before sending traffic is necessary in
   WebRTC deployments to ensure that a malicious JavaScript cannot use
   the browser as a platform for launching attacks.  A related problem
   is session liveness.  WebRTC application may want to detect
   connection failure and take appropriate action.

   This document describes how a WebRTC browser can verify peer consent
   to continue sending traffic and detect connection failure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-00


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From mperumal@cisco.com  Fri Sep 20 01:24:46 2013
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 6CA3F21F8B35 for ; Fri, 20 Sep 2013 01:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O06I74CHH8bE for ; Fri, 20 Sep 2013 01:24:35 -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 6C7E621F8A7B for ; Fri, 20 Sep 2013 01:24:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2888; q=dns/txt; s=iport; t=1379665475; x=1380875075; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RX+bCGnWIFfOtKwe+pLpMxWaBYJPP5H22shIptIHCQ8=; b=WYdQra+6txSc/8CSHBmLK2HaViZpDx15XujJw2UUTdWY1J4fYZwbF9Yl hsYA2trNRCD3vT+mOkMre98o2PbVxnR/m5OSAhKCJ5qvgzHNdIgFbJyV2 +kFqQ8G0SLS9d4ApWjBjzTQJO9nWZkXfDWBb2XPModVirLP1JFiKdsZks o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFALUFPFKtJV2d/2dsb2JhbABbgwc4UsBsSoEZFnSCJQEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh3sMunaPNjgGgxiBAAOZK5BGgySCKg
X-IronPort-AV: E=Sophos;i="4.90,941,1371081600"; d="scan'208";a="259290589"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 20 Sep 2013 08:24:26 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8K8ONkp012794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 08:24:23 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.35]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 03:24:23 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: Christer Holmberg , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.txt
Thread-Index: AQHOtdO3VyArQTGsZUKmwLiEhG8nLZnOPdbAgAAJotA=
Date: Fri, 20 Sep 2013 08:24:23 +0000
Message-ID: 
References: <20130920073331.2144.40500.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1C4A83EA@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A83EA@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [72.163.208.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-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, 20 Sep 2013 08:24:46 -0000

Sure, noted.

This was a resubmit of the -04 individual draft as a WG draft, with minor c=
hanges. We'll cover the ICE-lite scenario in the next revision..

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O=
f Christer Holmberg
|Sent: Friday, September 20, 2013 1:22 PM
|To: rtcweb@ietf.org
|Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness=
-00.txt
|
|Hi,
|
|The draft doesn't mention the case when one entity (e.g. a gateway) is ICE=
 lite. Eventhough ICE
|already specifies that an ICE lite entity does not send STUN requests, I t=
hink it would be good to
|cover it also for consent refreshness.
|
|Regards,
|
|Christer
|
|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O=
f internet-drafts@ietf.org
|Sent: 20. syyskuuta 2013 10:34
|To: i-d-announce@ietf.org
|Cc: rtcweb@ietf.org
|Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.=
txt
|
|
|A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
| This draft is a work item of the Real-Time Communication in WEB-browsers =
Working Group of the IETF.
|
|	Title           : STUN Usage for Consent Freshness
|	Author(s)       : Muthu Arul Mozhi Perumal
|                          Dan Wing
|                          Ram Mohan Ravindranath
|                          Tirumaleswar Reddy
|	Filename        : draft-ietf-rtcweb-stun-consent-freshness-00.txt
|	Pages           : 7
|	Date            : 2013-09-19
|
|Abstract:
|   Verification of peer consent before sending traffic is necessary in
|   WebRTC deployments to ensure that a malicious JavaScript cannot use
|   the browser as a platform for launching attacks.  A related problem
|   is session liveness.  WebRTC application may want to detect
|   connection failure and take appropriate action.
|
|   This document describes how a WebRTC browser can verify peer consent
|   to continue sending traffic and detect connection failure.
|
|
|The IETF datatracker status page for this draft is:
|https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness
|
|There's also a htmlized version available at:
|http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-00
|
|
|Please note that it may take a couple of minutes from the time of submissi=
on until the htmlized
|version and diff are available at tools.ietf.org.
|
|Internet-Drafts are also available by anonymous FTP at:
|ftp://ftp.ietf.org/internet-drafts/
|
|_______________________________________________
|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 kevindempsey70@gmail.com  Fri Sep 20 01:27:52 2013
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 5710221F8B9C for ; Fri, 20 Sep 2013 01:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCOke4vkV5rQ for ; Fri, 20 Sep 2013 01:27:48 -0700 (PDT)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4721F8B04 for ; Fri, 20 Sep 2013 01:27:44 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id o14so330409lbi.4 for ; Fri, 20 Sep 2013 01:27:28 -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=MDbuiaJsWJAY9WXpv5mLhW18aaz9KUdUSOw9zP2xg6k=; b=UvGFpdtYAQ341yjHdpc17QfkbsZrDFnl2pd629531ttBWWpVJ2hJeda4e699VyKUcj 2qhHdEzrHTemwlDXvYHSpnEIrBzTby97wZReeL73qHU2YxGlUbGjH0dwDGJl5v4MRiJ4 VCMGuToWTjwydwYzgXyz8RMV2q3g21Yb3TCVrchQzm7w77AKvWpeZNX3sH3lT/NTR2dE nkIomuPLze6cOgMCyp0rF8gLTAUFj359VqQhGAtKp6M/N+0WxAGVh8wZjK91eYgfiJQq n7VvYipY6AVABD84xTpBk5A8pJbJaYUtufLs7i5VN61fwGosA/ReDtVtKX2YwAfhNeVL Ro3A==
MIME-Version: 1.0
X-Received: by 10.112.77.134 with SMTP id s6mr655304lbw.38.1379665648692; Fri, 20 Sep 2013 01:27:28 -0700 (PDT)
Received: by 10.114.181.226 with HTTP; Fri, 20 Sep 2013 01:27:28 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>
Date: Fri, 20 Sep 2013 09:27:28 +0100
Message-ID: 
From: Kevin Dempsey 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=001a11c3dfbae6326004e6cc706e
Cc: "Cullen Jennings \(fluffy@cisco.com\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 08:27:52 -0000

--001a11c3dfbae6326004e6cc706e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

For Q.3, doesn't RFC 5764 say the proto field for DTLS-SRTP should be "
UDP/TLS/RTP/SAVPF"


On 19 September 2013 11:08, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,****
>
> ** **
>
> Section 5.2.1:****
>
> -----------------****
>
> ** **
>
> *Q_1:      o- line  initial value - deviation*
>
> ** **
>
> What is the reason for recommending a  zero value in the
> initial Offer, when the RFC says SHOULD use an NTP format timestamp? ****
>
> ** **
>
> I don=92t have any strong feelings, but in general: whenever we deviate f=
rom
> the =93base=94 SDP procedures I think we should justify why.****
>
> ** **
>
> ** **
>
> *Q_2:      o- line  initial value - forking*
>
> ** **
>
> When a new PeerConnection is created due to forking, the 
> value must be based (incremented) on the value associated with the =93mot=
her=94
> PeerConnection, for which the initial Offer of the whole communication
> session was created.****
>
> ** **
>
> ** **
>
> *Q_3:      RTP*
>
> ** **
>
> The text says:****
>
> ** **
>
> =93The  field MUST be set to "RTP/SAVPF". =93****
>
> ** **
>
> But, that of course only applies to RTP based streams (not the data
> channel). Also, in general, it needs to be clear what information needs t=
o
> be in every m- line, and what information is protocol specific. I would
> suggest to have a =93General=94 sub-section, a =93RTP=94 sub-section, etc=
.****
>
> ** **
>
> ** **
>
> *Q_4:      BUNDLE*
>
> ** **
>
> The text says:****
>
> ** **
>
> =93If a m=3D section is not being bundled into another m=3D section, it M=
UST****
>
>                 generate a unique set of ICE credentials and gather its
> own set of****
>
>                 candidates.  Otherwise, it MUST use the same ICE
> credentials and****
>
>                 candidates that were used in the m=3D section that it is
> being bundled****
>
>                 into.=94****
>
> ** **
>
> As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?****
>
> ** **
>
> I don=92t object to that =96 I just want to clarify, as it has impacts on=
 the
> text in the BUNDLE spec :)****
>
> ** **
>
> ** **
>
> Section 5.2.2:****
>
> -----------------****
>
> ** **
>
> ** **
>
> *Q_5:      Offer when in =93local-offer=94*
>
> ** **
>
> The text says:****
>
> ** **
>
> =93If the initial offer was applied using setLocalDescription, but an****
>
>                 answer from the remote side has not yet been applied,
> meaning the****
>
>                 PeerConnection is still in the "local-offer" state, the
> steps for****
>
>                 generating an initial offer should be followed,=94****
>
> ** **
>
> I don=92t understand this. Why would you create a new Offer while you are
> waiting for an Answer to the previously sent Offer? ****
>
> ** **
>
> Also, when setRemote() is called, to which Offer does it apply?****
>
> ** **
>
> * *
>
> *Q_6:      BUNDLE*
>
> ** **
>
> We=92ll probably also need some text about BUNDLE.****
>
> ** **
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c3dfbae6326004e6cc706e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


For Q.3, doesn't RFC 5764 say the proto field for DTLS=
-SRTP should be "UDP/TL=
S/RTP/SAVPF"



On 19 September 2013 11:08, Christer Holmberg <christer.holmb=
erg@ericsson.com> wrote:












Hi,


=A0


Section 5.2.1:


-----------------


=A0


Q_1:=A0=A0=A0=A0=A0 o- line <sess-version> =
initial value - deviation


=A0


What is the reason for recommending a <sess-versi=
on> zero value in the initial Offer, when the RFC says SHOULD use an NTP=
 format timestamp?



=A0


I don=92t have any strong feelings, but in general: =
whenever we deviate from the =93base=94 SDP procedures I think we should ju=
stify why.


=A0


=A0


Q_2:=A0=A0=A0=A0=A0 o- line <sess-version> =
initial value - forking


=A0


When a new PeerConnection is created due to forking,=
 the <sess-version> value must be based (incremented) on the value as=
sociated with the =93mother=94 PeerConnection, for which the initial Offer =
of the whole communication session was created.



=A0


=A0


Q_3:=A0=A0=A0=A0=A0 RTP


=A0


The text says:


=A0


=93The <proto> fi=
eld MUST be set to "RTP/SAVPF". =93


=A0


But, that of course only applies to RTP based stream=
s (not the data channel). Also, in general, it needs to be clear what infor=
mation needs to be in every m- line, and what information is protocol speci=
fic. I would suggest to have a =93General=94
 sub-section, a =93RTP=94 sub-section, etc.


=A0


=A0


Q_4: =A0=A0=A0=A0 BUNDLE


=A0


The text says:


=A0


=93If a m=3D section is=
 not being bundled into another m=3D section, it MUST


=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 generate=
 a unique set of ICE credentials and gather its own set of

=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 candidat=
es.=A0 Otherwise, it MUST use the same ICE credentials and

=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 candidat=
es that were used in the m=3D section that it is being bundled


=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 into.=94=



=A0


As, when BUNDLE is used, the initial Offer will cont=
ain identical ICE candidates, does that mean that we will also include iden=
tical address information in the initial Offer?


=A0


I don=92t object to that =96 I just want to clarify,=
 as it has impacts on the text in the BUNDLE spec :)


=A0


=A0


Section 5.2.2:


-----------------


=A0


=A0


Q_5:=A0=A0=A0=A0=A0 Offer when in =93local-offer=
=94


=A0


The text says:


=A0


=93If the initial offer=
 was applied using setLocalDescription, but an


=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 answer f=
rom the remote side has not yet been applied, meaning the


=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PeerConn=
ection is still in the "local-offer" state, the steps for<=
u>


=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 generati=
ng an initial offer should be followed,=94


=A0


I don=92t understand this. Why would you create a ne=
w Offer while you are waiting for an Answer to the previously sent Offer?



=A0


Also, when setRemote() is called, to which Offer doe=
s it apply?


=A0


=A0


Q_6:=A0=A0=A0=A0=A0 BUNDLE


=A0


We=92ll probably also need some text about BUNDLE.


=A0


=A0


Regards,


=A0


Christer


=A0







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c3dfbae6326004e6cc706e--

From christer.holmberg@ericsson.com  Fri Sep 20 01:31:30 2013
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 0467D21F8E85 for ; Fri, 20 Sep 2013 01:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BR0WnjObys9 for ; Fri, 20 Sep 2013 01:31:24 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 628C021F8E97 for ; Fri, 20 Sep 2013 01:31:24 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-cc-523c07daf50b
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 55.CD.25272.AD70C325; Fri, 20 Sep 2013 10:31:23 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 10:31:02 +0200
From: Christer Holmberg 
To: "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-00.txt
Thread-Index: AQHOtdO3VyArQTGsZUKmwLiEhG8nLZnOPdbAgAAJotCAAARUMA==
Date: Fri, 20 Sep 2013 08:31:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A84CE@ESESSMB209.ericsson.se>
References: <20130920073331.2144.40500.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1C4A83EA@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje5tdpsggw9P2SzufJrDarH2Xzu7 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxc/d+5oJXEhWre3cyNTD2inQxcnJICJhI HLg/jQXCFpO4cG89WxcjF4eQwFFGib7db9khnCWMEpP2NjN1MXJwsAlYSHT/0wZpEBFIlXjc OJ0RxBYWCJbouPeVCSIeIrHmaCcbhO0k0dxyjhXEZhFQlfj9cxI7iM0r4Cvxaus5Zoj5xxkl Vj95xQyS4ARK7Dl4FqyZEeii76fWgA1lFhCXuPVkPhPEpQISS/acZ4awRSVePv7HCnKbhICi xPJ+OYhyHYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkEydhaRlFpKWWUhaFjCyrGLkKE4t TspNNzLYxAiMhoNbflvsYLz81+YQozQHi5I47xa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGHN5Osqy6/n7yy66+yp1vc4RS5LN62pKZj3NcPK5dIJjsVfQZ85F3b+565Mvx3pdzeav y37UUNqRdzTAOTa36b1j3+8vKUzVXClMJ5/9O+i8gPPRzDU/elgXSsmkbPPr3C1+8nuL8rSb We88fzMw2RQ5tsu8KNI/fnL57zqbp4nlNic8G9KVWIozEg21mIuKEwGdQ7SvVAIAAA==
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-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, 20 Sep 2013 08:31:30 -0000

Thanks!

-----Original Message-----
From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20
Sent: 20. syyskuuta 2013 11:24
To: Christer Holmberg; rtcweb@ietf.org
Subject: RE: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-=
00.txt

Sure, noted.

This was a resubmit of the -04 individual draft as a WG draft, with minor c=
hanges. We'll cover the ICE-lite scenario in the next revision..

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
|Behalf Of Christer Holmberg
|Sent: Friday, September 20, 2013 1:22 PM
|To: rtcweb@ietf.org
|Subject: Re: [rtcweb] I-D Action:=20
|draft-ietf-rtcweb-stun-consent-freshness-00.txt
|
|Hi,
|
|The draft doesn't mention the case when one entity (e.g. a gateway) is=20
|ICE lite. Eventhough ICE already specifies that an ICE lite entity does=20
|not send STUN requests, I think it would be good to cover it also for cons=
ent refreshness.
|
|Regards,
|
|Christer
|
|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
|Behalf Of internet-drafts@ietf.org
|Sent: 20. syyskuuta 2013 10:34
|To: i-d-announce@ietf.org
|Cc: rtcweb@ietf.org
|Subject: [rtcweb] I-D Action:=20
|draft-ietf-rtcweb-stun-consent-freshness-00.txt
|
|
|A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
| This draft is a work item of the Real-Time Communication in WEB-browsers =
Working Group of the IETF.
|
|	Title           : STUN Usage for Consent Freshness
|	Author(s)       : Muthu Arul Mozhi Perumal
|                          Dan Wing
|                          Ram Mohan Ravindranath
|                          Tirumaleswar Reddy
|	Filename        : draft-ietf-rtcweb-stun-consent-freshness-00.txt
|	Pages           : 7
|	Date            : 2013-09-19
|
|Abstract:
|   Verification of peer consent before sending traffic is necessary in
|   WebRTC deployments to ensure that a malicious JavaScript cannot use
|   the browser as a platform for launching attacks.  A related problem
|   is session liveness.  WebRTC application may want to detect
|   connection failure and take appropriate action.
|
|   This document describes how a WebRTC browser can verify peer consent
|   to continue sending traffic and detect connection failure.
|
|
|The IETF datatracker status page for this draft is:
|https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne
|ss
|
|There's also a htmlized version available at:
|http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-00
|
|
|Please note that it may take a couple of minutes from the time of=20
|submission until the htmlized version and diff are available at tools.ietf=
.org.
|
|Internet-Drafts are also available by anonymous FTP at:
|ftp://ftp.ietf.org/internet-drafts/
|
|_______________________________________________
|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 harald@alvestrand.no  Fri Sep 20 03:11:05 2013
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 42BAC21F91BF for ; Fri, 20 Sep 2013 03:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.368
X-Spam-Level: 
X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2soH3SHu0jhJ for ; Fri, 20 Sep 2013 03:11:00 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5D2921F91F2 for ; Fri, 20 Sep 2013 03:10:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E47D39E0CE for ; Fri, 20 Sep 2013 12:10:57 +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 LNexzbZRn2ZQ for ; Fri, 20 Sep 2013 12:10:56 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1003:d74f:d593:c954] (unknown [IPv6:2001:470:de0a:27:1003:d74f:d593:c954]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7DF5639E068 for ; Fri, 20 Sep 2013 12:10:56 +0200 (CEST)
Message-ID: <523C1F86.8040408@alvestrand.no>
Date: Fri, 20 Sep 2013 12:12:22 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030400040603030202080209"
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 10:11:05 -0000

This is a multi-part message in MIME format.
--------------030400040603030202080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/20/2013 10:27 AM, Kevin Dempsey wrote:
>
>     *Q_4:      BUNDLE*
>
>     The text says:
>
>     "If a m= section is not being bundled into another m= section, it MUST
>
>                     generate a unique set of ICE credentials and
>     gather its own set of
>
>                     candidates. Otherwise, it MUST use the same ICE
>     credentials and
>
>                     candidates that were used in the m= section that
>     it is being bundled
>
>                     into."
>
>     As, when BUNDLE is used, the initial Offer will contain identical
>     ICE candidates, does that mean that we will also include identical
>     address information in the initial Offer?
>
>     I don't object to that -- I just want to clarify, as it has
>     impacts on the text in the BUNDLE spec :)
>
>

I think we should be careful here to specify that BUNDLE is used 
according to the BUNDLE spec, and that any description given here is 
non-normative.

Over to MMUSIC....

--------------030400040603030202080209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/20/2013 10:27 AM, Kevin Dempsey
      wrote:

    

    
 
      

        

          

            

              

                
Q_4:      BUNDLE

                
 

                
The text says:

                
 

                
“If a m=
                  section is not being bundled into another m= section,
                  it MUST

                
                generate a unique
                  set of ICE credentials and gather its own set of

                
                candidates. 
                  Otherwise, it MUST use the same ICE credentials and

                
                candidates that
                  were used in the m= section that it is being bundled

                
                into.”

                
 

                
As, when BUNDLE is used, the
                  initial Offer will contain identical ICE candidates,
                  does that mean that we will also include identical
                  address information in the initial Offer?

                
 

                
I don’t object to that – I just
                  want to clarify, as it has impacts on the text in the
                  BUNDLE spec :)

                

              

            

          

        

      

    

    

    I think we should be careful here to specify that BUNDLE is used
    according to the BUNDLE spec, and that any description given here is
    non-normative.

    

    Over to MMUSIC....

  


--------------030400040603030202080209--

From christer.holmberg@ericsson.com  Fri Sep 20 03:21:03 2013
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 A442121F89FF for ; Fri, 20 Sep 2013 03:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.7
X-Spam-Level: 
X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lVYtpfnpBeH for ; Fri, 20 Sep 2013 03:20:57 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92EDB21F8414 for ; Fri, 20 Sep 2013 03:20:56 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-c3-523c2186fa8d
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 75.22.22048.6812C325; Fri, 20 Sep 2013 12:20:54 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 12:20:52 +0200
From: Christer Holmberg 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOtds+oqyPOXXX30KyTFCuXf+qS5nORo0AgAAjfGA=
Date: Fri, 20 Sep 2013 10:20:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A8710@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>  <523C1F86.8040408@alvestrand.no>
In-Reply-To: <523C1F86.8040408@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A8710ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW6bok2QwaxPwhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLOnr3PUnDNreLWjdmMDYx9dl2MnBwSAiYS /SdXM0HYYhIX7q1n62Lk4hASOMwocerXXmYIZwmjRN+EyUAZDg42AQuJ7n/aIA0iAsESvc/f M4LYwgLREo9WTGSDiMdI7Dr/hQWkXETASqL1nA9ImEVAVaLp+AxWkDCvgK/E3Xm5ENO3M0pc fn4V7AZOAV2JWd86WEBsRqB7vp9aAxZnFhCXuPVkPtSdAhJL9pxnhrBFJV4+/gc2U0JAUWJ5 vxxEeb5E771DYCW8AoISJ2c+YZnAKDILyaRZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBj JmTxBYzsqxjZcxMzc9LLzTcxAuPm4JbfBjsYN90XO8QozcGiJM67We9MoJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQZGpguFCmyPV/sJq7l7MLDKzffxtFJNbXGZoTLfjal5G/OPc0nrJmX8 k4rxS3czf/s0q9z0nbSCxj+epW4JqkxJZnsPr5xcduzd4WUdzO9Xtq2z3dbgdIpJWaBa+8h/ kygliz86p9fO36TbM0tg9cKJ16wnpPHlNiku+nL8Jpe0e17zfPEdu5uVWIozEg21mIuKEwFo cCenaQIAAA==
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 10:21:04 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4A8710ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I really hope BUNDLE will be used as described in BUNDLE. At least that sho=
uld be our starting point. If we want to change something, it shall be just=
ified and discussed, before put into a document.

In addition, in the example flow in JSEP, BUNDLE IS used with different add=
resses, so an alignment will be needed in any case.

Regards,

Christer

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: 20. syyskuuta 2013 13:12
To: rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (1=
9th september)

On 09/20/2013 10:27 AM, Kevin Dempsey wrote:

Q_4:      BUNDLE

The text says:

"If a m=3D section is not being bundled into another m=3D section, it MUST
                generate a unique set of ICE credentials and gather its own=
 set of
                candidates.  Otherwise, it MUST use the same ICE credential=
s and
                candidates that were used in the m=3D section that it is be=
ing bundled
                into."

As, when BUNDLE is used, the initial Offer will contain identical ICE candi=
dates, does that mean that we will also include identical address informati=
on in the initial Offer?

I don't object to that - I just want to clarify, as it has impacts on the t=
ext in the BUNDLE spec :)


I think we should be careful here to specify that BUNDLE is used according =
to the BUNDLE spec, and that any description given here is non-normative.

Over to MMUSIC....

--_000_7594FB04B1934943A5C02806D1A2204B1C4A8710ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I really hope BUNDLE will=
 be used as described in BUNDLE. At least that should be our starting point=
. If we want to change something, it shall be justified
 and discussed, before put into a document.


 <=
/p>

In addition, in the examp=
le flow in JSEP, BUNDLE IS used with different addresses, so an alignment w=
ill be needed in any case.


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>





From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ie=
tf.org]
On Behalf Of Harald Alvestrand

Sent: 20. syyskuuta 2013 13:12

To: rtcweb@ietf.org

Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5=
.2.2 (19th september)






 




On 09/20/2013 10:27 AM, Kevin Dempsey wrote:






  












Q_4:      BUNDLE


 


The text says:


 



“If a m=3D section is not being bundled into another m=3D section, it=
 MUST


            =
;    generate a unique set of ICE credentials and gather its=
 own set of


            =
;    candidates.  Otherwise, it MUST use the same ICE c=
redentials and


            =
;    candidates that were used in the m=3D section that it i=
s being bundled


            =
;    into.”


 


As, when BUNDLE is used, the initial Offer will contain identical =
ICE candidates, does that mean that we will also include identical address =
information in the initial Offer?


 


I don’t object to that – I just want to clarify, as it=
 has impacts on the text in the BUNDLE spec :)


 
















I think we should be careful here to specify that BUNDLE is used according =
to the BUNDLE spec, and that any description given here is non-normative.


Over to MMUSIC....






--_000_7594FB04B1934943A5C02806D1A2204B1C4A8710ESESSMB209erics_--

From harald@alvestrand.no  Fri Sep 20 03:37:05 2013
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 9D6F821F92B8 for ; Fri, 20 Sep 2013 03:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.398
X-Spam-Level: 
X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2O9Udi22YCA for ; Fri, 20 Sep 2013 03:37:00 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0121F92C2 for ; Fri, 20 Sep 2013 03:36:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D15FD39E085; Fri, 20 Sep 2013 12:36: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 k489mmP6zgtb; Fri, 20 Sep 2013 12:36:53 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1003:d74f:d593:c954] (unknown [IPv6:2001:470:de0a:27:1003:d74f:d593:c954]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 115A239E068; Fri, 20 Sep 2013 12:36:53 +0200 (CEST)
Message-ID: <523C259B.5000705@alvestrand.no>
Date: Fri, 20 Sep 2013 12:38:19 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>  <523C1F86.8040408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C4A8710@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A8710@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040600030805050300090102"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 10:37:05 -0000

This is a multi-part message in MIME format.
--------------040600030805050300090102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/20/2013 12:20 PM, Christer Holmberg wrote:
>
> I really hope BUNDLE will be used as described in BUNDLE. At least 
> that should be our starting point. If we want to change something, it 
> shall be justified and discussed, before put into a document.
>
> In addition, in the example flow in JSEP, BUNDLE IS used with 
> different addresses, so an alignment will be needed in any case.
>
>

Since we're all tracking moving objects, I think we have to write text 
as best we can, and just point out which parts are normative and which 
parts are not.

In this particular case, using MUST language for whether or not ICE 
credentials are the same or different is inappropriate for this spec; 
instead it should say something like "The BUNDLE spec says that it MUST 
generate".

Then we just make sure it gets right before BUNDLE is published.


--------------040600030805050300090102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/20/2013 12:20 PM, Christer
      Holmberg wrote:

    

    

      
      
      
      

        
I
            really hope BUNDLE will be used as described in BUNDLE. At
            least that should be our starting point. If we want to
            change something, it shall be justified and discussed,
            before put into a document.

        
 

        
In
            addition, in the example flow in JSEP, BUNDLE IS used with
            different addresses, so an alignment will be needed in any
            case.

        
 

        

      

    

    

    Since we're all tracking moving objects, I think we have to write
    text as best we can, and just point out which parts are normative
    and which parts are not.

    

    In this particular case, using MUST language for whether or not ICE
    credentials are the same or different is inappropriate for this
    spec; instead it should say something like "The BUNDLE spec says
    that it MUST generate".

    

    Then we just make sure it gets right before BUNDLE is published.

    

  


--------------040600030805050300090102--

From christer.holmberg@ericsson.com  Fri Sep 20 03:47:30 2013
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 D4DEC21F9346 for ; Fri, 20 Sep 2013 03:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.711
X-Spam-Level: 
X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.537,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQsiQJrGEpZb for ; Fri, 20 Sep 2013 03:47:24 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EE1C421F9323 for ; Fri, 20 Sep 2013 03:47:23 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-35-523c27ba9ccd
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 09.06.22048.AB72C325; Fri, 20 Sep 2013 12:47:23 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 12:47:22 +0200
From: Christer Holmberg 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOtds+oqyPOXXX30KyTFCuXf+qS5nORo0AgAAjfGD//+PEgIAAIgMw
Date: Fri, 20 Sep 2013 10:47:21 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A8798@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>  <523C1F86.8040408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C4A8710@ESESSMB209.ericsson.se> <523C259B.5000705@alvestrand.no>
In-Reply-To: <523C259B.5000705@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A8798ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje5udZsgg993WS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGW0nPvEWLDZpWJx02TGBsZJNl2MnBwSAiYS N85OYISwxSQu3FvP1sXIxSEkcJhRYs+2D0wQzhJGifXr9rJ0MXJwsAlYSHT/0wZpEBHQkXi4 v4EJxGYWUJe4s/gcO4gtLBAt8WjFRDaImhiJXee/sEDYbhLXTz9hAxnDIqAqMbnJGSTMK+Ar cXRBL9TeeUwS+95NBevlFNCV2LPrJZjNCHTc91NroHaJS9x6Mp8J4mgBiSV7zjND2KISLx// YwWZLyGgKLG8Xw6iPF/iwIXXLBC7BCVOznzCMoFRdBaSSbOQlM1CUgYR15FYsPsTG4StLbFs 4WtmGPvMgcdMyOILGNlXMbLnJmbmpJebb2IERtTBLb8NdjBuui92iFGag0VJnHez3plAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwuBeH9sZYbVT+Ea1xkanJf8NUuZqNJa3zNF9N/txsa Jcx09/lbiIdkrN198X61tWvgp775H75lPDlxucBxv+OtRXbTXyfzWX3jv7nmfbL5ygUrlLes 4lj55C6rwNOWGf49IutZFrXYH/Ba5H1aa3t9y0LXrOtKZot5D4bxyD5d7/ZwhaazppwSS3FG oqEWc1FxIgD3okQvdgIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 10:47:30 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4A8798ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

The reason I asked is because one of the open issues in BUNDLE is whether i=
dentical ICE credentials (and identical address properties) are allowed in =
the initial Offer, and one of the JSEP authors has been against that :)

But, in general I do agree with you. Whenever we reference procedures defin=
ed elsewhere, we shall reference those.

And, in this case, BUNDLE has a section on ICE, so we should reference thos=
e. And, if we have any issues with the BUNDLE ICE procedures, we should bri=
ng it to MMUSIC, before making deviations "on the fly"...

Regards,

Christer

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 20. syyskuuta 2013 13:38
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (1=
9th september)

On 09/20/2013 12:20 PM, Christer Holmberg wrote:
I really hope BUNDLE will be used as described in BUNDLE. At least that sho=
uld be our starting point. If we want to change something, it shall be just=
ified and discussed, before put into a document.

In addition, in the example flow in JSEP, BUNDLE IS used with different add=
resses, so an alignment will be needed in any case.


Since we're all tracking moving objects, I think we have to write text as b=
est we can, and just point out which parts are normative and which parts ar=
e not.

In this particular case, using MUST language for whether or not ICE credent=
ials are the same or different is inappropriate for this spec; instead it s=
hould say something like "The BUNDLE spec says that it MUST generate".

Then we just make sure it gets right before BUNDLE is published.

--_000_7594FB04B1934943A5C02806D1A2204B1C4A8798ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

The reason I asked is bec=
ause one of the open issues in BUNDLE is whether identical ICE credentials =
(and identical address properties) are allowed in the initial
 Offer, and one of the JSEP authors has been against that :)


 <=
/p>

But, in general I do agre=
e with you. Whenever we reference procedures defined elsewhere, we shall re=
ference those.


 <=
/p>

And, in this case, BUNDLE=
 has a section on ICE, so we should reference those. And, if we have any is=
sues with the BUNDLE ICE procedures, we should bring it
 to MMUSIC, before making deviations “on the fly”…


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>





From: Harald Alvestrand [mailto:harald@alvestrand.no]


Sent: 20. syyskuuta 2013 13:38

To: Christer Holmberg

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5=
.2.2 (19th september)






 




On 09/20/2013 12:20 PM, Christer Holmberg wrote:






I really hope BUNDLE will=
 be used as described in BUNDLE. At least that should be our starting point=
. If we want to change something, it shall be justified
 and discussed, before put into a document.


 <=
/p>

In addition, in the examp=
le flow in JSEP, BUNDLE IS used with different addresses, so an alignment w=
ill be needed in any case.


 <=
/p>





Since we're all tracking moving objects, I think we have to write text as b=
est we can, and just point out which parts are normative and which parts ar=
e not.



In this particular case, using MUST language for whether or not ICE credent=
ials are the same or different is inappropriate for this spec; instead it s=
hould say something like "The BUNDLE spec says that it MUST generate&q=
uot;.



Then we just make sure it gets right before BUNDLE is published.=







--_000_7594FB04B1934943A5C02806D1A2204B1C4A8798ESESSMB209erics_--

From stefan.lk.hakansson@ericsson.com  Fri Sep 20 03:57:21 2013
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 193FF21F9371 for ; Fri, 20 Sep 2013 03:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.349
X-Spam-Level: 
X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRnlD4AN9NiQ for ; Fri, 20 Sep 2013 03:57:14 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3A21F92CD for ; Fri, 20 Sep 2013 03:57:13 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-87-523c2a07b5ca
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.12.16099.70A2C325; Fri, 20 Sep 2013 12:57:11 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 12:57:11 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
Thread-Index: AQHOtcbevxz1HDDILk+MiGgkFV/wNw==
Date: Fri, 20 Sep 2013 10:57:10 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
References: <523BE4DB.5030800@ericsson.com> <523BF860.1090105@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjS67lk2QQdsMPYtjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBmnn85mKZgtXvFxvkED41bhLkZODgkBE4kT +04xQdhiEhfurWfrYuTiEBI4zCjxa+9HKGcJo8TWFxeZQarYBAIltu5bwAZiiwjoSDzc3wDW zSygLnFn8Tl2EFtYIExi95qtTBA14RI9bTfZIWw9iZ0tO8HiLAKqEu97/4LN5BXwlZhy/ABY jZCAj8Tv+ZMYQWxGoIu+n1oDNV9c4taT+VCXCkgs2XOeGcIWlXj5+B8rhK0o0f60gRGiXk/i xtQpbBC2tsSyha+hdglKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAmPh 4JbfujsYT50TOcQozcGiJM67Se9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG0bBpnQlp bo8n6mrJRk+rmp9x5e1Zif5lG9Tyn86tm5Br/VIjR+VoGeOtPS+2/Jg2Ncr1BcfyTcy5nOJG eXdYfp45z7X5sobC3Hl8J1eFL7n2eXJwXOQC6Z3bRH1lj3UdOHNPVODy5TeXD75y+thScF3e fkmzKGdO6f1pj4ojtTd0Mgh8v3EkU4mlOCPRUIu5qDgRADCRJvRTAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
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, 20 Sep 2013 10:57:21 -0000

On 2013-09-20 09:25, Harald Alvestrand wrote:=0A=
> On 09/20/2013 08:02 AM, Magnus Westerlund wrote:=0A=
>> WG,=0A=
>>=0A=
>> In the JSEP call I commented regarding a=3Dimageattr open issue that we=
=0A=
>> had an original agreement from over a year ago (Vancouver) to go with=0A=
>> Harald's proposal in then=0A=
>> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt=0A=
>>=0A=
>> This is documented in the minutes:=0A=
>> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb=0A=
>>=0A=
>>=0A=
>> However, I did forget to note that there has been discussion on this=0A=
>> issue after that between Harald Alvestrand and Stefan H=E5kansson=0A=
>> primarily on the W3C list=0A=
>>=0A=
>> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html=0A=
>>=0A=
>> Where they are seriously discussing only using WebRTC API for this.=0A=
>>=0A=
>> It is in the context of=0A=
>> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution=
/=0A=
>>=0A=
>> Thus I would like to point out that there appear to be some indication=
=0A=
>> of desire move away from the consensus last year.=0A=
>=0A=
> My thinking is that there are 3 points on the spectrum of solutions:=0A=
>=0A=
> - Constraints at source only (the approach most thoroughly described in=
=0A=
> draft-alvestrand-constraints-resolution).=0A=
>=0A=
> - Constraints at destination can be sigalled in SDP, and acted on at=0A=
> source (described in draft-alvestrand-rtcweb-resolution). This spec=0A=
> could not be pursued as long as the "Plan X" discussions were still=0A=
> unsettled, but now it should really be "a piece of cake".=0A=
=0A=
My personal view is still that SDP is the wrong level for carrying this =0A=
kind of signaling (resolution, and perhaps further down the road =0A=
pause/resume related signaling). Each update requires an O/A, and locks =0A=
out other changes to the session. And since the SDPs must be handled by =0A=
the application (that is responsible for sending them over and applying =0A=
them) I wonder if there is any advantage compared to just having an API =0A=
on the sending side. If the receiving application wants another =0A=
resolution sent, it could just tell the sending application so, rather =0A=
than going through a createOffer/setLocal/ send-offer =0A=
/receive-answer/setRemote cycle.=0A=
=0A=
>=0A=
> - Defining a new way of signalling. This was the approach rejected in=0A=
> Vancouver.=0A=
>=0A=
> Formalistically, if the IETF decides to offer a well defined mechanism=0A=
> for negotiating resolution through SDP, the W3C will certainly take up=0A=
> the discussion on whether or not we should connect the API to that=0A=
> functionality.=0A=
>=0A=
> Happy to discuss more.=0A=
>=0A=
> _______________________________________________=0A=
> rtcweb mailing list=0A=
> rtcweb@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
=0A=

From karl.stahl@intertex.se  Fri Sep 20 08:43:52 2013
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 498F321F9C2C for ; Fri, 20 Sep 2013 08:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae2eplzXkVAM for ; Fri, 20 Sep 2013 08:43:47 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1921A21F9C22 for ; Fri, 20 Sep 2013 08:43:44 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309201743420713; Fri, 20 Sep 2013 17:43:42 +0200
From: "Karl Stahl" 
To: "'Cullen Jennings \(fluffy\)'" , 
References: 
In-Reply-To: 
Date: Fri, 20 Sep 2013 17:43:42 +0200
Message-ID: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOqYsejEiO9JuZoEu3yxpSVyhr2JnO1vuQ
Content-Language: sv
Subject: [rtcweb]  TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 20 Sep 2013 15:43:52 -0000

For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets =
the
TURN server address from the web application, or gets it configured by a =
LAN
admin via an =93admin policy template=94. =20

However, there is a need (motivations below) for the TURN server address =
to
be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, =
and
the OTT channel in mobiles have their own method I=92ve been told). =
Simply
put, just as you often get your IP-address, DNS address, etc. =
automatically
from the network access, you should also get the TURN server address.

I suggest the following is added to the end of use case (which today is
about multiple TURN servers)
3.2.4.  Simple Video Communication Service, global service provider
3.2.4.1.  Description
...
"A network service provider must be able to automatically supply a TURN
server addresses to the browser when accessing a network. The address =
may
come via DHCP or a similar mechanism (maybe RA - Router Advertisement - =
for
IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or =
whatever
method the mobile OTT channels use). The mechanism should be similar to
automatically getting the IP-address, DNS address, etc.. and need =
extensions
to current recommendations/standards.=20

There are several reasons for a network service provider to supply a =
TURN
server as part of his offered access:
- to keep media paths short, specifically not sending media outside its =
own
network to some distant application provided TURN server
- to support mobility, i.e. you may want to move from a LAN with a
configured TURN server to accessing via WiFi or 3G/4G OTT channels=20
- to offer a media path with better quality (than best effort data =
traffic).
Getting =93WebRTC-ready=94 access and we look forward to telepresence =
for
everyone.

An enterprise network that want to keep a restrictive firewall not =
allowing
UDP traffic, could provide a real-time path using a TURN server =
paralleling
the firewall, instead of tunneling RTP through always open http or https
ports resulting in RTP media over TCP =96 with severe quality problems =
from
TCP retransmissions of dropped packets. The TURN server address is most
easily provided in the same way as the IP address and DNS address. (That
would also put the right party in control =96 The network provider =
decides
what is allowed on his network.)

This browser should select which available TURN server address to use in =
the
following priority order, where ICE could be used to try several:

1) TURN server address configured in the browser by the user (special =
cases,
normally not used)=20
2) TURN server address configured by the network administrator via an =
=93admin
policy template=94
3) TURN server address supplied by DHCP or similar automatic network =
method=20
4) TURN server address being supplied by the web application"

Two new requirements can be extracted:
"   ----------------------------------------------------------------
   F40     The browser must support retrieving TURN server addresses via
DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, =
an
addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method =
the
mobile OTT channels use). The mechanism should be similar to =
automatically
getting the IP-address, DNS address, etc..
   ----------------------------------------------------------------
   F42     This browser should select which available TURN server =
address to
use in the following priority order, where ICE could be used to try =
several:

1) TURN server address configured in the browser by the user (special =
cases,
normally not used)=20
2) TURN server address configured by the network administrator via an =
=93admin
policy template=94
3) TURN server address supplied by DHCP or similar automatic network =
method=20
4) TURN server address being supplied by the web application  =20
----------------------------------------------------------------"

I suppose this also will add to:
5.  IANA Considerations
   TBD

/Karl


-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Cullen
Jennings (fluffy)
Skickat: den 4 september 2013 18:24
Till: rtcweb@ietf.org
=C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11


We would like to start a working group last call of
draft-ietf-rtcweb-use-cases-and-requirements-11.

Please send comments by the end of the day on September 21.=20

Thank you,=20

The chairs =85.




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


From andrew.hutton@siemens-enterprise.com  Fri Sep 20 10:09:14 2013
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 5466121F940D for ; Fri, 20 Sep 2013 10:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level: 
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3iARX4WQES4 for ; Fri, 20 Sep 2013 10:09:10 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id EC1DA21F9301 for ; Fri, 20 Sep 2013 10:09:09 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4511223F04E7 for ; Fri, 20 Sep 2013 19:09:05 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 19:08:51 +0200
From: "Hutton, Andrew" 
To: "rtcweb@ietf.org" 
Thread-Topic: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOtiPaXQ5oJjZhuEGvvne6h5dDp5nO23kA
Date: Fri, 20 Sep 2013 17:08:50 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3D0@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] FW: [pntaw] New version of	draft-hutton-rtcweb-nat-firewall-considerations
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, 20 Sep 2013 17:09:14 -0000

Hi All,

We have submitted draft-hutton-rtcweb-nat-firewall-considerations-02 in whi=
ch we have tried to take account of the feedback we have received over the =
last couple of months.

Comments should be sent to the PNTAW list.

Regards
Andy



-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of internet-drafts@ietf.org
Sent: 20 September 2013 15:33
To: i-d-announce@ietf.org
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxi=
es
	Author(s)       : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-02.txt
	Pages           : 12
	Date            : 2013-09-20

Abstract:
   This document describes mechanism to enable media stream
   establishment for Real-Time Communication in WEB-browsers (WebRTC) in
   the presence of network address translators, firewalls and HTTP
   proxies.  HTTP proxy and firewall deployed in many private network
   domains introduce obstacles to the successful establishment of media
   stream via WebRTC.  This document examines some of these deployment
   scenarios and develops requirements on the web browsers designed to
   provide the best possible chance of media connectivity between WebRTC
   peers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considera=
tions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-=
02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-hutton-rtcweb-nat-firewall-conside=
rations-02


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
pntaw mailing list
pntaw@ietf.org
https://www.ietf.org/mailman/listinfo/pntaw

From andrew.hutton@siemens-enterprise.com  Fri Sep 20 10:58:07 2013
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 56E5D21F9CED for ; Fri, 20 Sep 2013 10:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfIQhTiS-v6i for ; Fri, 20 Sep 2013 10:57:57 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AAAFD21F9CE9 for ; Fri, 20 Sep 2013 10:57:56 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C67DF23F0542; Fri, 20 Sep 2013 19:57:53 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 19:57:39 +0200
From: "Hutton, Andrew" 
To: Magnus Westerlund , "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" 
Thread-Topic: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8g
Date: Fri, 20 Sep 2013 17:57:38 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>
References:  <5238446D.8050700@ericsson.com>
In-Reply-To: <5238446D.8050700@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 20 Sep 2013 17:58:07 -0000

On: 17 September 2013 13:01 Magnus Westerlund Wrote:
> 3.2.3.1.  Description
>=20
>    This use-case is almost identical to the Simple Video Communication
>    Service use-case (Section 3.2.1).  The difference is that one of the
>    users is behind a FW that only allows http traffic.
>=20
> If a firewall only allows HTTP traffic, then can we really assume that
> the firewall administrator per default will accept WebRTC Media and
> Data
> traffic?
>=20
> I am far from certain of this, and think on a requirement level needs
> to
> express a situation where the firewall administrator allows WebRTC
> across its FW, or at least can easily configure a rule to block it.
> Thus
> resulting in that any solution for this needs to be easily identifiable
> and possible to block.
>=20

Stefan already stated that this use case will be changed to take account of=
 my comments in http://www.ietf.org/mail-archive/web/rtcweb/current/msg0826=
4.html. So the "only allows HTTP traffic" is going to be removed and change=
d to describe the use case when the firewall requires traffic to flow via a=
 HTTP Proxy.=20

We also have a use case when a network specific TURN server is deployed (3.=
2.5.1).

In both cases I agree that a network administrator must have a way to block=
 webrtc but there are various ways of achieving this including just configu=
ring the browser not to do webrtc, normal HTTP black/white lists, and also =
I can imagine solutions based on putting something in the HTTP Connect sent=
 to the proxy so the proxy can block it.=20

So I agree that it must be possible to block webrtc traffic but we need to =
careful not to specify the solution in the use case. =20

Andy



From fluffy@cisco.com  Fri Sep 20 11:22:49 2013
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 96AD421F9D65 for ; Fri, 20 Sep 2013 11:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level: 
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUhbMkW+fiLd for ; Fri, 20 Sep 2013 11:22:44 -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 D971B21F9D71 for ; Fri, 20 Sep 2013 11:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3947; q=dns/txt; s=iport; t=1379701360; x=1380910960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NDYuW7pyh++RpfIdh0SgcWJ6CS/+H8IS3fr5QnnWnC0=; b=O03co+Z24Hwb7gB1PG3Gw7/Y9DvmmHexL8tdyFzjcNYdaD15tW4f8LSi QJEjvrh/b6sZQJtb7dmBAuUKfkx2Vrvd4bdw9N3kpDbY49IN2RlaEhi1n 4/yLbiovBS82phvqRiCpn+Gdj3ZGSlDX41YbcBRbTKZH7RfcqAGrK5Ay+ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFACyRPFKtJV2d/2dsb2JhbABbgwc4UsB+SoEaFnSCJQEBAQMBAQEBawsFCwIBCCIkJwslAQEEDgUIh3cGDLpaBI8yAjEHgx6BAAOpcoFmgT6CKg
X-IronPort-AV: E=Sophos;i="4.90,946,1371081600"; d="scan'208";a="262599889"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 20 Sep 2013 18:22:38 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8KIMb6L024756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 18:22:37 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 13:22:37 -0500
From: "Cullen Jennings (fluffy)" 
To: Christer Holmberg 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: Ac61H8SXeXXAffdpQLKis+JdCZjjDABOIgUA
Date: Fri, 20 Sep 2013 18:22:36 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.94.194]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <91E2450E15968B42B0C1C0A725D89034@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 18:22:49 -0000

Good points - proposed resolutions inline =85

On Sep 19, 2013, at 3:08 AM, Christer Holmberg  wrote:

> Hi,
>=20
> Section 5.2.1:
> -----------------
>=20
> Q_1:      o- line  initial value - deviation
>=20
> What is the reason for recommending a  zero value in the in=
itial Offer, when the RFC says SHOULD use an NTP format timestamp?
>=20
> I don=92t have any strong feelings, but in general: whenever we deviate f=
rom the =93base=94 SDP procedures I think we should justify why.

Lets use NTP=20

>=20
>=20
> Q_2:      o- line  initial value - forking
>=20
> When a new PeerConnection is created due to forking, the  v=
alue must be based (incremented) on the value associated with the =93mother=
=94 PeerConnection, for which the initial Offer of the whole communication =
session was created.


uh, that is old text sorry. I'm proposing the principal that any time the S=
DP changes (including new candidate lines) the version gets larger.=20

>=20
>=20
> Q_3:      RTP
>=20
> The text says:
>=20
> =93The  field MUST be set to "RTP/SAVPF". =93
>=20
> But, that of course only applies to RTP based streams (not the data chann=
el). Also, in general, it needs to be clear what information needs to be in=
 every m- line, and what information is protocol specific. I would suggest =
to have a =93General=94 sub-section, a =93RTP=94 sub-section, etc.

Yep - I think this should be offers are created with RTP/SAVPF for audio an=
d video and system can reeve offers with SAVPF or SAVP
>=20
>=20
> Q_4:      BUNDLE
>=20
> The text says:
>=20
> =93If a m=3D section is not being bundled into another m=3D section, it M=
UST
>                generate a unique set of ICE credentials and gather its ow=
n set of
>                candidates.  Otherwise, it MUST use the same ICE credentia=
ls and
>                candidates that were used in the m=3D section that it is b=
eing bundled
>                into.=94
>=20
> As, when BUNDLE is used, the initial Offer will contain identical ICE can=
didates, does that mean that we will also include identical address informa=
tion in the initial Offer?

no the initial offer will not have identical stuff other than on lines that=
 "bundle-only" and we still need to add more text on this but idea is to ma=
ke just like what is in united-plan

>=20
> I don=92t object to that =96 I just want to clarify, as it has impacts on=
 the text in the BUNDLE spec :)
>=20
>=20
> Section 5.2.2:
> -----------------
>=20
>=20
> Q_5:      Offer when in =93local-offer=94
>=20
> The text says:
>=20
> =93If the initial offer was applied using setLocalDescription, but an
>                answer from the remote side has not yet been applied, mean=
ing the
>                PeerConnection is still in the "local-offer" state, the st=
eps for
>                generating an initial offer should be followed,=94
>=20
> I don=92t understand this. Why would you create a new Offer while you are=
 waiting for an Answer to the previously sent Offer?

Justin has asked for this in the case when the offer has not been sent to a=
nyone else. This is not going to be useful for typical systems trying to ha=
ve SIP or Jingle compatible flow but who knows =85

>=20
> Also, when setRemote() is called, to which Offer does it apply?

The most recent one. And the JS app would have to make sure it passed the w=
rite one or you run high odds of getting completely broken behavior.=20

>=20
>=20
> Q_6:      BUNDLE
>=20
> We=92ll probably also need some text about BUNDLE.
>=20

yep - but plan is to match up with unified plan=20

>=20
> Regards,
>=20
> Christer
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From harald@alvestrand.no  Fri Sep 20 14:16:02 2013
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 B3FD821F9E62 for ; Fri, 20 Sep 2013 14:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.422
X-Spam-Level: 
X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLlUCxSXUfjI for ; Fri, 20 Sep 2013 14:15:58 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 467BB21F9E51 for ; Fri, 20 Sep 2013 14:15:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D61C039E110 for ; Fri, 20 Sep 2013 23:15:55 +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 XUqabRXGBE4S for ; Fri, 20 Sep 2013 23:15:54 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1003:d74f:d593:c954] (unknown [IPv6:2001:470:de0a:27:1003:d74f:d593:c954]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BCD0139E0CE for ; Fri, 20 Sep 2013 23:15:54 +0200 (CEST)
Message-ID: <523CBB62.6000007@alvestrand.no>
Date: Fri, 20 Sep 2013 23:17:22 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
In-Reply-To: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 20 Sep 2013 21:16:02 -0000

I'm very hesitant to add more requirements that translate to "new 
protocol needs to be developed, implemented and deployed across the 
network before the requirement is useful".

In this case, it's "only" a DHCP option, but what new DHCP options do we 
have that have become widely used in the last 10 years?

On 09/20/2013 05:43 PM, Karl Stahl wrote:
> For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets the
> TURN server address from the web application, or gets it configured by a LAN
> admin via an “admin policy template”.
>
> However, there is a need (motivations below) for the TURN server address to
> be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, and
> the OTT channel in mobiles have their own method I’ve been told). Simply
> put, just as you often get your IP-address, DNS address, etc. automatically
> from the network access, you should also get the TURN server address.
>
> I suggest the following is added to the end of use case (which today is
> about multiple TURN servers)
> 3.2.4.  Simple Video Communication Service, global service provider
> 3.2.4.1.  Description
> ...
> "A network service provider must be able to automatically supply a TURN
> server addresses to the browser when accessing a network. The address may
> come via DHCP or a similar mechanism (maybe RA - Router Advertisement - for
> IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whatever
> method the mobile OTT channels use). The mechanism should be similar to
> automatically getting the IP-address, DNS address, etc.. and need extensions
> to current recommendations/standards.
>
> There are several reasons for a network service provider to supply a TURN
> server as part of his offered access:
> - to keep media paths short, specifically not sending media outside its own
> network to some distant application provided TURN server
> - to support mobility, i.e. you may want to move from a LAN with a
> configured TURN server to accessing via WiFi or 3G/4G OTT channels
> - to offer a media path with better quality (than best effort data traffic).
> Getting “WebRTC-ready” access and we look forward to telepresence for
> everyone.
>
> An enterprise network that want to keep a restrictive firewall not allowing
> UDP traffic, could provide a real-time path using a TURN server paralleling
> the firewall, instead of tunneling RTP through always open http or https
> ports resulting in RTP media over TCP – with severe quality problems from
> TCP retransmissions of dropped packets. The TURN server address is most
> easily provided in the same way as the IP address and DNS address. (That
> would also put the right party in control – The network provider decides
> what is allowed on his network.)
>
> This browser should select which available TURN server address to use in the
> following priority order, where ICE could be used to try several:
>
> 1) TURN server address configured in the browser by the user (special cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an “admin
> policy template”
> 3) TURN server address supplied by DHCP or similar automatic network method
> 4) TURN server address being supplied by the web application"
>
> Two new requirements can be extracted:
> "   ----------------------------------------------------------------
>     F40     The browser must support retrieving TURN server addresses via
> DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, an
> addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the
> mobile OTT channels use). The mechanism should be similar to automatically
> getting the IP-address, DNS address, etc..
>     ----------------------------------------------------------------
>     F42     This browser should select which available TURN server address to
> use in the following priority order, where ICE could be used to try several:
>
> 1) TURN server address configured in the browser by the user (special cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an “admin
> policy template”
> 3) TURN server address supplied by DHCP or similar automatic network method
> 4) TURN server address being supplied by the web application
> ----------------------------------------------------------------"
>
> I suppose this also will add to:
> 5.  IANA Considerations
>     TBD
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen
> Jennings (fluffy)
> Skickat: den 4 september 2013 18:24
> Till: rtcweb@ietf.org
> Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
> We would like to start a working group last call of
> draft-ietf-rtcweb-use-cases-and-requirements-11.
>
> Please send comments by the end of the day on September 21.
>
> Thank you,
>
> The chairs ….
>
>
>
>
> _______________________________________________
> 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 karl.stahl@intertex.se  Fri Sep 20 15:11:40 2013
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 0F3CB21F9E6C for ; Fri, 20 Sep 2013 15:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level: 
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX+97XezgEtp for ; Fri, 20 Sep 2013 15:11:35 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id E02E621F9E51 for ; Fri, 20 Sep 2013 15:11:34 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309210011316490; Sat, 21 Sep 2013 00:11:31 +0200
From: "Karl Stahl" 
To: "'Hutton, Andrew'" , "'Magnus Westerlund'" , "'Cullen Jennings	\(fluffy\)'" , , 
References: 	<5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>
Date: Sat, 21 Sep 2013 00:11:30 +0200
Message-ID: <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmA=
Content-Language: sv
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 20 Sep 2013 22:11:40 -0000

I want to point out that all methods suggested for RTP media through
firewalls that do not allow UDP traffic, by using "always open" https =
port
443 (or http port 80) result in tunneling RTP media over TCP. That gives
with severe quality problems from TCP retransmissions of dropped media
packet packets. Do we really want that for WebRTC?

A quality wise better solution is already pointed out in use case =
3.2.5.1
mentioned below:
"An enterprise that uses a RTCWEB based web application for =
communication
desires to audit all RTCWEB based application session used from inside =
the
company towards any external peer. To be able to do this they deploy a =
TURN
server that straddle the boundary
between the internal network and the external"
=20
I suggest the following is added to that use case:
"Such TURN server allows a media path, separated from the usually data
crowded enterprise Internet access, offering superior quality. This is a
better way to enable WebRTC on a network behind a restrictive firewall =
not
allowing UDP traffic, instead of tunneling RTP through always open http =
or
https ports resulting in RTP media over TCP =96 with severe quality =
problems
from TCP retransmissions of dropped packets.=20

Such network administrator provided auditing TURN server would also put =
the
right party in control =96 The network administrator decides what is =
allowed
on his network."

Why should a network administrator that wants to block webrtc media, =
have to
do more than just closing his firewall for UDP, like below suggested
"configuring the browser not to do webrtc, normal HTTP black/white =
lists,
and solutions based on putting something in the HTTP Connect sent to the
proxy so the proxy can block it"?

Another thing in the second half of the same use case 3.2.5.1:=20
Are NAT/firewalls inside the enterprise network assumed? If not, I think =
the
second half can be deleted.

" In cases where employees are using RTCWEB applications provided by an
   external service provider they still want to have the traffic to stay
   inside their internal network and in addition not load the straddling
   TURN server, "

ICE establishes a direct connection in this case, not using any TURN =
server
at all, doesn=92t it? This is then not a problem.

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Hutton,
Andrew
Skickat: den 20 september 2013 19:58
Till: Magnus Westerlund; Cullen Jennings (fluffy); rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: Re: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11

On: 17 September 2013 13:01 Magnus Westerlund Wrote:
> 3.2.3.1.  Description
>=20
>    This use-case is almost identical to the Simple Video Communication
>    Service use-case (Section 3.2.1).  The difference is that one of =
the
>    users is behind a FW that only allows http traffic.
>=20
> If a firewall only allows HTTP traffic, then can we really assume that =

> the firewall administrator per default will accept WebRTC Media and=20
> Data traffic?
>=20
> I am far from certain of this, and think on a requirement level needs=20
> to express a situation where the firewall administrator allows WebRTC=20
> across its FW, or at least can easily configure a rule to block it.
> Thus
> resulting in that any solution for this needs to be easily=20
> identifiable and possible to block.
>=20

Stefan already stated that this use case will be changed to take account =
of
my comments in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So =
the
"only allows HTTP traffic" is going to be removed and changed to =
describe
the use case when the firewall requires traffic to flow via a HTTP =
Proxy.=20

We also have a use case when a network specific TURN server is deployed
(3.2.5.1).

In both cases I agree that a network administrator must have a way to =
block
webrtc but there are various ways of achieving this including just
configuring the browser not to do webrtc, normal HTTP black/white lists, =
and
also I can imagine solutions based on putting something in the HTTP =
Connect
sent to the proxy so the proxy can block it.=20

So I agree that it must be possible to block webrtc traffic but we need =
to
careful not to specify the solution in the use case. =20

Andy


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


From christer.holmberg@ericsson.com  Fri Sep 20 15:17:36 2013
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 3211A21F9E8D for ; Fri, 20 Sep 2013 15:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level: 
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.564,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC0-mWkUvKjU for ; Fri, 20 Sep 2013 15:17:29 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 671F921F9A1C for ; Fri, 20 Sep 2013 15:17:28 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-42-523cc9771d37
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.A0.03802.779CC325; Sat, 21 Sep 2013 00:17:27 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Sat, 21 Sep 2013 00:17:27 +0200
From: Christer Holmberg 
To: "Cullen Jennings (fluffy)" 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnPLVCA
Date: Fri, 20 Sep 2013 22:17:26 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A8EA4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW75SZsggxd/TS06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXzvf8xYMEGq4szn60wNjN+Euxg5OSQETCQe nTrNBmGLSVy4tx7I5uIQEjjMKLG6dz47hLOEUWLq5Y+sXYwcHGwCFhLd/7RBGkQEDCWa9sxj ArGZBdQl7iw+xw5SIiwQLfHgdhlESYzErvNfWEDCIgJGEotn8oOYLAKqEvvuK4JU8Ar4Srxa dxpq6wRGifaPF5hBEpxAia/r/4Odxgh02vdTa6A2iUt8OHidGeJkAYkle85D2aISLx//Y4Ww lSQalzxhhajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkb2 3MTMnPRyo02MwOg4uOW36g7GO+dEDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRkCU3eBNf47bJco1T4r7Hpsydpie8dVrVPPX98761G+xrahZcvN9iY2/U0jxhJa3s E/NVHSZdWqDuHGUsuNownudfcrnBce6ON9zl52pOTZsRZH9J6ViBptfPW/vtKmbMvVtee3h6 wofNk9vrqmStLlTMWsk22eGR584O23MJx84/l2/Z1vdGiaU4I9FQi7moOBEAFED71lwCAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 22:17:37 -0000

Hi Cullen,

>> Q_2:      o- line  initial value - forking
>>=20
>> When a new PeerConnection is created due to forking, the  =
value must be based (incremented) on the value associated with the "mother"=
 PeerConnection, for which the initial Offer of the whole communication ses=
sion was created.
>
> uh, that is old text sorry. I'm proposing the principal that any time the=
 SDP changes (including new candidate lines) the version gets larger.=20

Yes. But keep in mind that this is an Offer created for a new PeerConnectio=
n.=20


----------------

=20
>> Q_4:      BUNDLE
>>=20
>> The text says:
>>=20
>> "If a m=3D section is not being bundled into another m=3D section, it MU=
ST
>>                generate a unique set of ICE credentials and gather its o=
wn set of
>>                candidates.  Otherwise, it MUST use the same ICE credenti=
als and
>>                candidates that were used in the m=3D section that it is =
being bundled
>>                into."
>>=20
>> As, when BUNDLE is used, the initial Offer will contain identical ICE ca=
ndidates, does that mean that we will also include identical address inform=
ation in the initial Offer?
>
> no the initial offer will not have identical stuff other than on lines th=
at "bundle-only" and we still need to add more text on this but idea is to =
make just like what is in united-plan

Regarding the details (usage of port zero etc) of "bundle-only", that is st=
ill something we have to agree upon. But, that discussion belongs to MMUSIC=
 (and, I believe there is a thread about that already :)

But again, in the case of forking, when a new PeerConnection is created, I =
think we should allow identical stuff in the initial Offer of that PeerConn=
ection. Because, the remote party has already indicated support of BUNDLE, =
in the Answer that was sent for the "mother" PeerConnection, so the initial=
 Offer for the new PeerConnection will be the second Offer for the remote p=
arty.

At some point, we are going to have to add much more details about forking,=
 in the case multiple PeerConnections are used. It is not enough to only sa=
y "create a new PeerConnection" :)


----------------


>> Section 5.2.2:
>> -----------------
>>=20
>>=20
>> Q_5:      Offer when in "local-offer"
>>=20
>> The text says:
>>=20
>> "If the initial offer was applied using setLocalDescription, but an
>>                answer from the remote side has not yet been applied, mea=
ning the
>>                PeerConnection is still in the "local-offer" state, the s=
teps for
>>                generating an initial offer should be followed,"
>>=20
>> I don't understand this. Why would you create a new Offer while you are =
waiting for an Answer to the previously sent Offer?
>
> Justin has asked for this in the case when the offer has not been sent to=
 anyone else. This is not going to be useful for typical systems trying to =
have SIP or Jingle compatible flow but who knows ...

Again, we have consensus to base JSEP on 3264. And, if we are going to devi=
ate from 3264, I'd like to have some discussion and justification for that.=
=20

I'd also have a section somewhere which summarizes *all* 3264 deviations th=
at JSEP makes.


Regards,

Christer

From bernard_aboba@hotmail.com  Fri Sep 20 17:09:50 2013
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 0EF8821F9F40 for ; Fri, 20 Sep 2013 17:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.484
X-Spam-Level: 
X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLJwsccRx0Hc for ; Fri, 20 Sep 2013 17:09:44 -0700 (PDT)
Received: from blu0-omc1-s21.blu0.hotmail.com (blu0-omc1-s21.blu0.hotmail.com [65.55.116.32]) by ietfa.amsl.com (Postfix) with ESMTP id 282F121F85E6 for ; Fri, 20 Sep 2013 17:09:44 -0700 (PDT)
Received: from BLU169-W25 ([65.55.116.8]) by blu0-omc1-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 20 Sep 2013 17:09:40 -0700
X-TMN: [mh3jqD7vKvwkjLT5gHrIwlNiool+Md1C]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_4ce0a1dd-6b02-49d9-89cb-d89bc8d7abef_"
From: Bernard Aboba 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Date: Fri, 20 Sep 2013 17:09:39 -0700
Importance: Normal
In-Reply-To: <523CBB62.6000007@alvestrand.no>
References: , <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>, <523CBB62.6000007@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Sep 2013 00:09:40.0187 (UTC) FILETIME=[DDA1C2B0:01CEB65E]
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 00:09:50 -0000

--_4ce0a1dd-6b02-49d9-89cb-d89bc8d7abef_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Harald said:=20
 =20
> In this case=2C it's "only" a DHCP option=2C but what new DHCP options do=
 we=20
> have that have become widely used in the last 10 years?

[BA] And of those=2C which ones are supported by *browsers*?
=20
I do think it is useful for a browser to be able to locate a local TURN ser=
ver=2C if this is to happen it will need to be done at the application laye=
r=2C not via DHCP.=20
 		 	   		  =

--_4ce0a1dd-6b02-49d9-89cb-d89bc8d7abef_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Harald =3Bsaid: =3B
&=
nbsp=3B =3B
>=3B In this case=2C it's "only" a DHCP option=2C but =
what new DHCP options do we 
>=3B have that have become widely used in=
 the last 10 years?

[BA] And of those=2C which ones are supported by=
 *browsers*?
 =3B
I do think it is useful for a browser to be abl=
e to locate a local TURN server=2C if this is to happen it will need to be =
done at the application layer=2C not via DHCP. 
 		 	   		  

=

--_4ce0a1dd-6b02-49d9-89cb-d89bc8d7abef_--

From karl.stahl@intertex.se  Fri Sep 20 17:16:34 2013
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 7C2F521F9C68 for ; Fri, 20 Sep 2013 17:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Level: 
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_50=0.001, GB_I_INVITATION=-2, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWODny4KRZIS for ; Fri, 20 Sep 2013 17:16:28 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id E772B21F9F3A for ; Fri, 20 Sep 2013 17:16:25 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309210216239986; Sat, 21 Sep 2013 02:16:23 +0200
From: "Karl Stahl" 
To: , 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
In-Reply-To: <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
Date: Sat, 21 Sep 2013 02:16:23 +0200
Message-ID: <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmCAACsPkA==
Content-Language: sv
Subject: [rtcweb]  WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 00:16:34 -0000

While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here are
a few "telephony related" WebRTC things I think should be clarified in the
use cases. 


3.2.1.  Simple Video Communication Service
3.2.1.1.  Description
...  
The invited user might accept or reject the session. 
[Suggest adding] The invited user might accept only audio, rejecting video
(even if a camera is enabled). A user may also select to initiate an audio
session, without video.

And in API requirements:
   ----------------------------------------------------------------
   A1      The Web API must provide means for the application to ask the
browser for permission to use cameras and microphones, individually as input
devices. (One must be able to answer with voice only - declining video.)
   ----------------------------------------------------------------
Same under
6.2.  Browser Considerations
...
The browser is expected to provide mechanisms for users to revise and even
completely revoke consent to use device resources such as camera and
microphone. [Suggest adding] Specifically, a user must be given the
opportunity to only accept audio in a video call invitation.



3.2.12.  Multiparty video communication
3.2.12.1.  Description
...
[Suggest adding] It is essential that automatic adjustments of microphone
volume is disabled, or microphones not spoken into are muted. (This is a
serious problem with most soft clients (SIP clients) of today, plaguing
conferences with ever increasing noise from silent participants.)

And in API requirements:
   ----------------------------------------------------------------
   A15     The Web API must provide means for the web application to adjust
the level in audio streams.
  ----------------------------------------------------------------
   Axx     The Web API must provide means to disable any automatic volume
adjustment in the sent audio streams. (To avoid disturbing noise in
conferences - making many softclients unusable). 
   ----------------------------------------------------------------



3.2.6.  Simple Video Communication Service, access change
3.2.6.1.  Description 
...
the user has to start a trip during the session. The communication device
automatically changes to use WiFi when the Ethernet cable is removed and
then moves to cellular access to the Internet when moving out of WiFi
coverage.  The session continues even though the access method changes.

[Question] Is this some sort of roaming without network support (please
clarify)? Getting a new access will also give the client a new IP address,
won't it? How could then the session continue? The browsers will have no
signaling connection and cannot renegotiate a media connection, can they?


From marc@mocet.com  Fri Sep 20 18:33:50 2013
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 32C4321F9EE5 for ; Fri, 20 Sep 2013 18:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTlX0HiqLpdb for ; Fri, 20 Sep 2013 18:33:45 -0700 (PDT)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1474721F9F31 for ; Fri, 20 Sep 2013 18:33:38 -0700 (PDT)
Received: by mail-vb0-f53.google.com with SMTP id i3so886589vbh.12 for ; Fri, 20 Sep 2013 18:33:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RtbimZsJWJ/KjKEi0YR7o3GDOWH2yua3SGti820QYqc=; b=HtukEVwF2HEryXFdZSiuUveCAVeDz+08jkMFYCchwhpdi5f9gj/Zgt8fbHcGkgbZ+X MXiPIrxCVTUiD7Wql2J2zCTa+pVs2U4GfoJPhROw2g7dbofJPK2GBvk+L2lXOndRB/nP sWoFuNx7M1KyciBzS4/pPK1/0Vrt9NUeSfjf6Yc+VvI0Z6yTjcjoiiVir4RlMDTzlfbW sLQ9RExnG62qTzgdXq71ZB4e2Pyy9DBwdMdL3XerAqvnxwXm2Ba8y4b3STskY8nJU05r sLDuTDl1VKgiaOcnHon/yTI/Dd7Zqz49I120Njxa0Sgulv1VnwUxy1zFjGhU8hvNb+F0 EXQw==
X-Gm-Message-State: ALoCoQnlLRvZEDUOffm/ZFOdTTZEcYNjZT5HRSgvpVNalEdvS8GjTD1XvH6pB8xf0vOPgkszQ7Jj
X-Received: by 10.220.74.69 with SMTP id t5mr9233113vcj.18.1379727217864; Fri, 20 Sep 2013 18:33:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.206.113 with HTTP; Fri, 20 Sep 2013 18:32:57 -0700 (PDT)
X-Originating-IP: [76.90.21.141]
In-Reply-To: 
References:  <523CBB62.6000007@alvestrand.no> 
From: Marc Abrams 
Date: Fri, 20 Sep 2013 18:32:57 -0700
Message-ID: 
To: Bernard Aboba 
Content-Type: multipart/alternative; boundary=047d7b624cbeb5470704e6dac620
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 01:33:50 -0000

--047d7b624cbeb5470704e6dac620
Content-Type: text/plain; charset=ISO-8859-1

Hi, Bernard:

Even hard phones can use "WebRTC" and DHCP options for programming so
having a DHCP option for pointing the phone at a local TURN server makes
sense.

Marc.


On Fri, Sep 20, 2013 at 5:09 PM, Bernard Aboba wrote:

> Harald said:
>
> > In this case, it's "only" a DHCP option, but what new DHCP options do we
> > have that have become widely used in the last 10 years?
>
> [BA] And of those, which ones are supported by *browsers*?
>
> I do think it is useful for a browser to be able to locate a local TURN
> server, if this is to happen it will need to be done at the application
> layer, not via DHCP.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 

____________________
+1-949-270-0935

--047d7b624cbeb5470704e6dac620
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi, Bernard:



Even hard phones can use "WebRTC" and DHCP options for programmin=
g so having a DHCP option for pointing the phone at a local TURN server mak=
es sense.



Marc.

On Fri, Sep 20, 2013 at 5:09 PM, Bernard Aboba =
<bernard_aboba@hotmail.com> wrote:







Harald=A0said:=A0
=A0=A0
> In this case, it&=
#39;s "only" a DHCP option, but what new DHCP options do we 
&=
gt; have that have become widely used in the last 10 years?

[BA] And=
 of those, which ones are supported by *browsers*?


=A0
I do think it is useful for a browser to be able to locate a local T=
URN server, if this is to happen it will need to be done at the application=
 layer, not via DHCP. 
 		 	   		  


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 

________________=
____
+1-949-270-0935






--047d7b624cbeb5470704e6dac620--

From cowwoc@bbs.darktech.org  Sat Sep 21 10:43:20 2013
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 BEFF111E817C for ; Sat, 21 Sep 2013 10:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw0l+1NV2mBb for ; Sat, 21 Sep 2013 10:43:10 -0700 (PDT)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id D834D11E817A for ; Sat, 21 Sep 2013 10:43:07 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id jy17so1091846qeb.12 for ; Sat, 21 Sep 2013 10:43:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=e9CSIAVLUeEMCdgmsXOoRvKc+79TTP52WesSEYDfKOg=; b=jv4NKCxbPcObFZ9h/uprDBIQdNXmHlXNFLepq+7tYOm3GcaV9p1+77uoR7cW8CzwT3 sGunPR6+s4Z0ipd4M7ExkWcHB4lc4QacJfe6DJIvp3ldxqakHaniNlvx3NW0o/wA8vZW K2FrlLZYK0gYUjrFfMRh5Xqx74RAc5eJJMSsGZLh6PfXlHZo4F2LICvwaEUOh/izjLvG jKRTIpKxujsFeqQKvLMw9K+owbNtLseDWkR2UNJd91DyxhWe6smDDzzpGjAgtn35gpiN ueVNk9uc/O12SHGvSleMuZutWstiupAreZCcSCmP/D6G0a0habWaMXdTOP5cJ6VDMUD6 5IIg==
X-Gm-Message-State: ALoCoQlWfP2QTeMVwCM58i1cogAf3hs0xeRvrQQaU54QiFip8hAfTtKp3z9IPDVPxboBLR+9u6NL
X-Received: by 10.49.15.97 with SMTP id w1mr18311869qec.13.1379785387097; Sat, 21 Sep 2013 10:43:07 -0700 (PDT)
Received: from [192.168.42.14] (out-pq-242.wireless.telus.com. [216.218.29.242]) by mx.google.com with ESMTPSA id h2sm28081812qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 10:43:06 -0700 (PDT)
Message-ID: <523DDA90.6080600@bbs.darktech.org>
Date: Sat, 21 Sep 2013 13:42:40 -0400
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ted Hardie 
References:  <5238A564.2070601@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000101090908020904000101"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec Selection Plan
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, 21 Sep 2013 17:43:21 -0000

This is a multi-part message in MIME format.
--------------000101090908020904000101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 9/17/2013 4:10 PM, Ted Hardie wrote:
> On Tue, Sep 17, 2013 at 11:54 AM, cowwoc  > wrote:
>
>     Hi Ted,
>
>         Seeing as this discussion stems from licensing concerns, I
>     like to propose the following alternative:
>
>      1. Mandate a video codec whose IPR has expired. I agree that
>         video quality will degrade, which brings me to the next point.
>
>
> To propose a video codec, please write a draft before the deadline and 
> put forward the technical details you're proposing (if there are 
> profiles, for example, which profile).  Saying you want this on the 
> list isn't enough information for folks to judge the proposal.  This 
> is why we are insisting on drafts at a deadline that gives folks the 
> opportunity to review the proposal.

Ted,

     I understand, but unfortunately I don't have the bandwidth to 
author such a draft so I'm out. However, I will support anyone who 
decides go ahead (with H261, Theora, etc).

Gili

--------------000101090908020904000101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 9/17/2013 4:10 PM, Ted Hardie wrote:

    

    

      
On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <cowwoc@bbs.darktech.org>
        wrote:

        

          

            

              

                
Hi Ted,

                  

                      Seeing as this discussion stems from licensing
                  concerns, I like to propose the following alternative:

                  
    
                    
  1. Mandate a video codec whose IPR has expired. I
                      agree that video quality will degrade, which
                      brings me to the next point.
    2. 
                  

                

              

            

            


            

            
To propose a video codec, please write a draft before
              the deadline and put forward the technical details you're
              proposing (if there are profiles, for example, which
              profile).  Saying you want this on the list isn't enough
              information for folks to judge the proposal.  This is why
              we are insisting on drafts at a deadline that gives folks
              the opportunity to review the proposal.

            

          

        

      

    

    

    Ted,

    

        I understand, but unfortunately I don't have the bandwidth to
    author such a draft so I'm out. However, I will support anyone who
    decides go ahead (with H261, Theora, etc).

    

    Gili

  


--------------000101090908020904000101--

From karl.stahl@intertex.se  Sat Sep 21 14:44:45 2013
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 5EDF511E819B for ; Sat, 21 Sep 2013 14:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level: 
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.048,  BAYES_50=0.001, GB_I_INVITATION=-2, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sK8o7yj890L for ; Sat, 21 Sep 2013 14:44:40 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 21B1211E81A0 for ; Sat, 21 Sep 2013 14:44:29 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309212344265890; Sat, 21 Sep 2013 23:44:26 +0200
From: "Karl Stahl" 
To: , 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>
In-Reply-To: <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>
Date: Sat, 21 Sep 2013 23:44:27 +0200
Message-ID: <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmCAACsPkIABLYKw
Content-Language: sv
Subject: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 21:44:45 -0000

Yet another thing related to
draft-ietf-rtcweb-use-cases-and-requirements-11:
It is about payload type, PT=3D, in SDP and RTP, so I am copying MMUSIC

Network service providers have expressed an interest to know whether =
packets
carry audio or video, to be able to handle them differently in the =
network
(e.g. quality wise). PT is visible outside the encrypted payload in RTP,
however if dynamic payload types PT:96-127 are used, you cannot know =
what
the payload is without knowledge of the SDP (which we for WebRTC must =
assume
the network provider has no knowledge of).

In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I =
see
no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC.

So, can we have payload types assigned to codecs that will be =
recommended
for WebRTC (PT:35-71 are unassigned)?
Or can we at least split dynamic payload types PT:96-127 into groups for
audio and video codecs?


I relation to that simple request, one may wonder how the network anyway =
can
know what is carried in an UPD packet (the RTP header is no reserved =
field -
it could be the payload of something else).

Quality related requirements F38, A23 and A26 in the use case draft,
nowadays only seem to relate to the browsers, not assuming that =
diffserve
bits or similar are conveyed to the network. That is realistic, since =
most
operating systems don't allow quality markings (diffserve, TOS) of =
packets.
However, 3.2.1.  Simple Video Communication Service, mentions "The web
service monitors the quality of the service (focus on quality of audio =
and
video) the end-users experience.". I don't understand how "The *web =
service*
monitors" based on the listed requirements. Should it be "The *browsers*
monitors"?

What are then the possibilities for a network to classify traffic for
quality or other purposes?

3G/4G networks have DPIs (Deep Packet Inspection) - such box may guess =
what
encrypted RTP traffic is... or may not...

Real time communication protocols using ICE as a pre-protocol to =
establish
media paths give a possibility though. If the network provider offers a =
TURN
server at his access, and enforces the TURN server to be used (by eating
STUN packets), then the RTP flows set up through the TURN server could
classify and mark packets. Then it is useful to know whether it is an =
audio
or video packet by looking at the payload type.

A LAN firewall, can also include a TURN-server, that in addition to
classifying and marking packets for the transport network (if honored -
which rarely is the case on the Internet today), it can also prioritize =
and
traffic shape so the RTP traffic at least is undisturbed through a data
crowded Internet access.

A more difficult request comes from networks using bandwidth reservation
(RSVP) for quality, like mobile and cable networks. Such networks would
benefit from knowing the bandwidth used, but that is not fixes for =
advanced
codecs like the ones considered for WebRTC. One way would be to reserve
maximum bandwidth, and possibly repeat the reservation if less is =
actually
used.

/Karl


-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Karl
Stahl
Skickat: den 21 september 2013 02:16
Till: rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here =
are
a few "telephony related" WebRTC things I think should be clarified in =
the
use cases.=20


3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ... =20
The invited user might accept or reject the session.=20
[Suggest adding] The invited user might accept only audio, rejecting =
video
(even if a camera is enabled). A user may also select to initiate an =
audio
session, without video.

And in API requirements:
   ----------------------------------------------------------------
   A1      The Web API must provide means for the application to ask the
browser for permission to use cameras and microphones, individually as =
input
devices. (One must be able to answer with voice only - declining video.)
   ----------------------------------------------------------------
Same under
6.2.  Browser Considerations
...
The browser is expected to provide mechanisms for users to revise and =
even
completely revoke consent to use device resources such as camera and
microphone. [Suggest adding] Specifically, a user must be given the
opportunity to only accept audio in a video call invitation.



3.2.12.  Multiparty video communication
3.2.12.1.  Description
...
[Suggest adding] It is essential that automatic adjustments of =
microphone
volume is disabled, or microphones not spoken into are muted. (This is a
serious problem with most soft clients (SIP clients) of today, plaguing
conferences with ever increasing noise from silent participants.)

And in API requirements:
   ----------------------------------------------------------------
   A15     The Web API must provide means for the web application to =
adjust
the level in audio streams.
  ----------------------------------------------------------------
   Axx     The Web API must provide means to disable any automatic =
volume
adjustment in the sent audio streams. (To avoid disturbing noise in
conferences - making many softclients unusable).=20
   ----------------------------------------------------------------



3.2.6.  Simple Video Communication Service, access change 3.2.6.1.
Description ...
the user has to start a trip during the session. The communication =
device
automatically changes to use WiFi when the Ethernet cable is removed and
then moves to cellular access to the Internet when moving out of WiFi
coverage.  The session continues even though the access method changes.

[Question] Is this some sort of roaming without network support (please
clarify)? Getting a new access will also give the client a new IP =
address,
won't it? How could then the session continue? The browsers will have no
signaling connection and cannot renegotiate a media connection, can =
they?

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


From karl.stahl@intertex.se  Sat Sep 21 15:29:35 2013
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 6647711E81A0 for ; Sat, 21 Sep 2013 15:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.814
X-Spam-Level: 
X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.336,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi-GuwUPhPaz for ; Sat, 21 Sep 2013 15:29:30 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id C436421F9477 for ; Sat, 21 Sep 2013 15:29:28 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309220029277261; Sun, 22 Sep 2013 00:29:27 +0200
From: "Karl Stahl" 
To: , 
References:  <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
In-Reply-To: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
Date: Sun, 22 Sep 2013 00:29:26 +0200
Message-ID: <07e501ceb71a$07f766d0$17e63470$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOqYsejEiO9JuZoEu3yxpSVyhr2JnO1vuQgAH+JAA=
Content-Language: sv
Subject: [rtcweb]   [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 22:29:35 -0000

This is an ICE network infrastructure request (rather than WebRTC =
specific)
so I am copying MMUSIC.

Harald Alvestrand said:=20
> I'm very hesitant to add more requirements that translate to "new =
protocol
needs to be developed, implemented and deployed across the network =
before
the requirement is useful".
--- Who isn't? Still the need is there, especially for network providers =
to
offer TURN servers with their accesses (see below). And worse, it is not =

> "only" a DHCP option
--- it is: "DHCP or a similar mechanism (maybe RA - Router Advertisement =
-
for IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or
whatever method the mobile OTT channels use)"
--- But for the browser it is a trivial thing to implement - Just use =
the
DHCP provided TURN server address suggested.=20

The burden to get the standards done fall on others...

There were some comments seeing the need for local TURN-servers (where =
there
are other possibilities than the "automatic DHCP", see below), but I =
want to
stress the importance of allowing network providers to offer TURN =
servers
with their accesses. That is why I call it a "WebRTC-ready" broadband
access.=20

I've heard several carries expressing that they want to provide their =
own
TURN servers with their accesses. The reason has both been to avoid that
media unnecessarily is sent outside their own network to some remote =
TURN
server and for quality reasons. The quality reason is especially =
important
e.g. in cable operator networks, using bandwidth reservation (RSVP) type =
of
QoS. They need to get hold of the RTP media streams and reserve =
bandwidth
for them and can do that by enforcing a TURN server at the access to be
used, and that TURN server can classify and reserve the bandwidth. (They =
do
these things for POTS 3.5kHz voice - They certainly need it for =
telepresence
capable WebRTC.)=20

I think we should be happy and encourage carrier's interest to supply a =
high
quality path for RTC traffic, here WebRTC. (That is a different attitude
than e.g. trying to block Skype.)

/Karl


-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Karl
Stahl
Skickat: den 20 september 2013 17:44
Till: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org
=C4mne: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets =
the
TURN server address from the web application, or gets it configured by a =
LAN
admin via an =93admin policy template=94. =20

However, there is a need (motivations below) for the TURN server address =
to
be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, =
and
the OTT channel in mobiles have their own method I=92ve been told). =
Simply
put, just as you often get your IP-address, DNS address, etc. =
automatically
from the network access, you should also get the TURN server address.

I suggest the following is added to the end of use case (which today is
about multiple TURN servers) 3.2.4.  Simple Video Communication Service,
global service provider 3.2.4.1.  Description ...
"A network service provider must be able to automatically supply a TURN
server addresses to the browser when accessing a network. The address =
may
come via DHCP or a similar mechanism (maybe RA - Router Advertisement - =
for
IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or =
whatever
method the mobile OTT channels use). The mechanism should be similar to
automatically getting the IP-address, DNS address, etc.. and need =
extensions
to current recommendations/standards.=20

There are several reasons for a network service provider to supply a =
TURN
server as part of his offered access:
- to keep media paths short, specifically not sending media outside its =
own
network to some distant application provided TURN server
- to support mobility, i.e. you may want to move from a LAN with a
configured TURN server to accessing via WiFi or 3G/4G OTT channels
- to offer a media path with better quality (than best effort data =
traffic).
Getting =93WebRTC-ready=94 access and we look forward to telepresence =
for
everyone.

An enterprise network that want to keep a restrictive firewall not =
allowing
UDP traffic, could provide a real-time path using a TURN server =
paralleling
the firewall, instead of tunneling RTP through always open http or https
ports resulting in RTP media over TCP =96 with severe quality problems =
from
TCP retransmissions of dropped packets. The TURN server address is most
easily provided in the same way as the IP address and DNS address. (That
would also put the right party in control =96 The network provider =
decides
what is allowed on his network.)

This browser should select which available TURN server address to use in =
the
following priority order, where ICE could be used to try several:

1) TURN server address configured in the browser by the user (special =
cases,
normally not used)
2) TURN server address configured by the network administrator via an =
=93admin
policy template=94
3) TURN server address supplied by DHCP or similar automatic network =
method
4) TURN server address being supplied by the web application"

Two new requirements can be extracted:
"   ----------------------------------------------------------------
   F40     The browser must support retrieving TURN server addresses via
DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, =
an
addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method =
the
mobile OTT channels use). The mechanism should be similar to =
automatically
getting the IP-address, DNS address, etc..
   ----------------------------------------------------------------
   F42     This browser should select which available TURN server =
address to
use in the following priority order, where ICE could be used to try =
several:

1) TURN server address configured in the browser by the user (special =
cases,
normally not used)
2) TURN server address configured by the network administrator via an =
=93admin
policy template=94
3) TURN server address supplied by DHCP or similar automatic network =
method=20
4) TURN server address being supplied by the web application  =20
----------------------------------------------------------------"

I suppose this also will add to:
5.  IANA Considerations
   TBD

/Karl


-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Cullen
Jennings (fluffy)
Skickat: den 4 september 2013 18:24
Till: rtcweb@ietf.org
=C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11


We would like to start a working group last call of
draft-ietf-rtcweb-use-cases-and-requirements-11.

Please send comments by the end of the day on September 21.=20

Thank you,=20

The chairs =85.




_______________________________________________
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 andrew.hutton@siemens-enterprise.com  Sat Sep 21 16:14:32 2013
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 A9EB421F940D for ; Sat, 21 Sep 2013 16:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yy3bFmJXNL5 for ; Sat, 21 Sep 2013 16:14:27 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7B11E81D3 for ; Sat, 21 Sep 2013 16:14:20 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 697771EB8558; Sun, 22 Sep 2013 01:14:19 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Sun, 22 Sep 2013 01:14:04 +0200
From: "Hutton, Andrew" 
To: Bernard Aboba , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl7fMuig8voiEUG8usawnCEAN5nQ0kde
Date: Sat, 21 Sep 2013 23:14:03 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BD024F@MCHP04MSX.global-ad.net>
References: ,  <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>, <523CBB62.6000007@alvestrand.no>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.196]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 23:14:32 -0000

=0A=
The use case draft section 3.2.5.1 states=0A=
=0A=
"It mustbe possibele to configure the browsers used in the enterprise with =
 network specific STUN and TURN servers.  This should be possible to achiev=
e by autoconfiguration methods."=0A=
=0A=
I had assumed that this meant using the browser configuration scripts in th=
e same way as the browser would discover the HTTP Proxy I can see that DHCP=
 is also an option which might be useful but I am not sure whether browsers=
 would use it.=0A=
=0A=
Andy=0A=
=0A=
=0A=
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Bernar=
d Aboba [bernard_aboba@hotmail.com]=0A=
=0A=
Sent: Saturday, September 21, 2013 1:09 AM=0A=
=0A=
To: Harald Alvestrand; rtcweb@ietf.org=0A=
=0A=
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcw=
eb-use-cases-and-requirements-11=0A=
=0A=
=0A=
=0A=
=0A=
Harald said: =0A=
=0A=
  =0A=
=0A=
> In this case, it's "only" a DHCP option, but what new DHCP options do we =
=0A=
=0A=
> have that have become widely used in the last 10 years?=0A=
=0A=
=0A=
=0A=
[BA] And of those, which ones are supported by *browsers*?=0A=
=0A=
 =0A=
=0A=
I do think it is useful for a browser to be able to locate a local TURN ser=
ver, if this is to happen it will need to be done at the application layer,=
 not via DHCP.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

From marc@mocet.com  Sat Sep 21 16:26:50 2013
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 9DBEE21F8F9A for ; Sat, 21 Sep 2013 16:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJLdNIYAhWPn for ; Sat, 21 Sep 2013 16:26:46 -0700 (PDT)
Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0D21F8F29 for ; Sat, 21 Sep 2013 16:26:45 -0700 (PDT)
Received: by mail-qe0-f46.google.com with SMTP id x7so1212935qeu.33 for ; Sat, 21 Sep 2013 16:26:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:in-reply-to :references:from:to:cc:subject:content-type; bh=bkoiIEdk32kQbS8DqZmjVs43ian8UwdLPT1alZd7aXk=; b=L8WDrPnXTwxvDszTeJCHLHrQ7D4ejzDn1azhXT/JFC99cv/wiwW6P15QKTO997TSRi 6AD6b/drXbwEgLxkXUmIW/DKU77Wp7qwllbN1cRz16i0wgahpJ+dvPet7SqWNq3VxBHR tiLSRniJYsL5RAsMBlcxvcYVQ2CvlofgzCk5kPob2wzb2SX3n3QxnH2IFyf0kg25AjJL X2nS+8ZUjDnLjzGzQKv0829Hgk3TzgAtcu1c5Ll6XxoFZoyiz64hH5r9BCGMeb187pAo fQEChfoNCej1xxzGcBHDvAdnj0kyJ0UPqCk4VO1BvixyZQqvkFD+FU6y8o5Sq8bhgIrk XDqQ==
X-Gm-Message-State: ALoCoQkxHGFKqNnsem8NC4nA97VOhtavdBuDt1HMk9CBey6DUpeScKDSn3wXvz8v6hgVW3ywuJD2
X-Received: by 10.49.39.161 with SMTP id q1mr13205214qek.66.1379806004835; Sat, 21 Sep 2013 16:26:44 -0700 (PDT)
Received: from [127.0.0.1] (ec2-54-235-159-167.compute-1.amazonaws.com. [54.235.159.167]) by mx.google.com with ESMTPSA id e7sm23321986qag.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 16:26:44 -0700 (PDT)
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/)
Date: Sat, 21 Sep 2013 16:26:44 -0700 (PDT)
Message-Id: <1379806004047.ef5647a6@Nodemailer>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD024F@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD024F@MCHP04MSX.global-ad.net>
X-Orchestra-Oid: E194F19D-8659-4D12-9917-F2913A4909BD
X-Orchestra-Sig: b142b194fe90632588422a7b007a86b15ae68440
X-Orchestra-Thrid: TDA83C077-93E8-4267-9B7B-ABE4DA08331D_1446711748209621349
X-Orchestra-Thrid-Sig: fba12d473e4a060eaf9bf397ccba947efa9e4522
X-Orchestra-Account: 3f156b4f028f360b28507eaa0283b86342b8bae0
From: "Marc Abrams" 
To: "Andrew Hutton" 
Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1379806004426"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 23:26:50 -0000

------Nodemailer-0.5.0-?=_1-1379806004426
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

But phones and ATAs and other IoT devices would.




Marc=C2=A0

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
+1-949-270-0935

On Sat, Sep 21, 2013 at 4:14 PM, Hutton, Andrew
 wrote:

> The use case draft section 3.2.5.1 states
> =22It mustbe possibele to configure the browsers used in the enterprise =
with  network specific STUN and TURN servers.  This should be possible to =
achieve by autoconfiguration methods.=22
> I had assumed that this meant using the browser configuration scripts in =
the same way as the browser would discover the HTTP Proxy I can see that =
DHCP is also an option which might be useful but I am not sure whether =
browsers would use it.
> Andy
> From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of =
Bernard Aboba [bernard=5Faboba@hotmail.com]
> Sent: Saturday, September 21, 2013 1:09 AM
> To: Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
> Harald said:=20
>=20=20=20
>> In this case, it's =22only=22 a DHCP option, but what new DHCP options =
do we=20
>> have that have become widely used in the last 10 years=3F
> [BA] And of those, which ones are supported by *browsers*=3F
>=20=20
> I do think it is useful for a browser to be able to locate a local TURN =
server, if this is to happen it will need to be done at the application =
layer, not via DHCP.
> =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
------Nodemailer-0.5.0-?=_1-1379806004426
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable



But phones and ATAs and other IoT devices would.





Marc=C2=A0


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F
+1-949-270-0935



On Sat, Sep 21, 2013 at 4:14 PM=
, Hutton, Andrew <andrew.=
hutton@siemens-enterprise.com> wrote:

The use case draft section 3.2.5.1 =
states


=22It mustbe possibele to configure the browsers used in the =
enterprise with  network specific STUN and TURN servers.  This should be =
possible to achieve by autoconfiguration methods.=22


I had assumed that this meant using the browser configuration =
scripts in the same way as the browser would discover the HTTP Proxy I can =
see that DHCP is also an option which might be useful but I am not sure =
whether browsers would use it.


Andy



From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on =
behalf of Bernard Aboba [bernard=5Faboba@hotmail.com]


Sent: Saturday, September 21, 2013 1:09 AM


To: Harald Alvestrand; rtcweb@ietf.org


Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11





Harald said:=20




> In this case, it's =22only=22 a DHCP option, but what =
new DHCP options do we=20


> have that have become widely used in the last 10 years=3F




[BA] And of those, which ones are supported by =
*browsers*=3F




I do think it is useful for a browser to be able to locate =
a local TURN server, if this is to happen it will need to be done at the =
application layer, not via DHCP.







=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



------Nodemailer-0.5.0-?=_1-1379806004426--

From andrew.hutton@siemens-enterprise.com  Sat Sep 21 16:40:58 2013
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 B1C3B11E81D5 for ; Sat, 21 Sep 2013 16:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHJAFboAbmGI for ; Sat, 21 Sep 2013 16:40:54 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 21AB311E81D7 for ; Sat, 21 Sep 2013 16:40:54 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 7DB471EB855A; Sun, 22 Sep 2013 01:40:53 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Sun, 22 Sep 2013 01:40:38 +0200
From: "Hutton, Andrew" 
To: Karl Stahl , 'Magnus Westerlund' , "'Cullen Jennings	(fluffy)'" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" 
Thread-Topic: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmCAAbVQhg==
Date: Sat, 21 Sep 2013 23:40:37 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BD02D4@MCHP04MSX.global-ad.net>
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>, <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
In-Reply-To: <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.196]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 23:40:58 -0000

=0A=
See below.=0A=
=0A=
=0A=
________________________________________=0A=
From: Karl Stahl [karl.stahl@intertex.se]=0A=
Sent: Friday, September 20, 2013 11:11 PM=0A=
To: Hutton, Andrew; 'Magnus Westerlund'; 'Cullen Jennings       (fluffy)'; =
rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.or=
g=0A=
Subject: SV: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-=
11=0A=
=0A=
I want to point out that all methods suggested for RTP media through=0A=
firewalls that do not allow UDP traffic, by using "always open" https port=
=0A=
443 (or http port 80) result in tunneling RTP media over TCP. That gives=0A=
with severe quality problems from TCP retransmissions of dropped media=0A=
packet packets. Do we really want that for WebRTC?=0A=
=0A=
A quality wise better solution is already pointed out in use case 3.2.5.1=
=0A=
mentioned below:=0A=
"An enterprise that uses a RTCWEB based web application for communication=
=0A=
desires to audit all RTCWEB based application session used from inside the=
=0A=
company towards any external peer. To be able to do this they deploy a TURN=
=0A=
server that straddle the boundary=0A=
between the internal network and the external"=0A=
=0A=
[AndyH] This is not about which is the better solution it is simply describ=
ing use cases. One in which the network administrator is aware of WebRTC an=
d deploys mechanisms to deal with it and one in which there is no administr=
ator or network specific mechanism for handling WebRTC media.  I think the =
use case in which there is no network specific TURN server will be at least=
 in the near term by far the most common use case and therefore we need mec=
hanisms to deal with it and it is a valid use case.=0A=
=0A=
I suggest the following is added to that use case:=0A=
"Such TURN server allows a media path, separated from the usually data=0A=
crowded enterprise Internet access, offering superior quality. This is a=0A=
better way to enable WebRTC on a network behind a restrictive firewall not=
=0A=
allowing UDP traffic, instead of tunneling RTP through always open http or=
=0A=
https ports resulting in RTP media over TCP =96 with severe quality problem=
s=0A=
from TCP retransmissions of dropped packets.=0A=
=0A=
[AndyH] This does not sound like use case text to me it is comparing soluti=
ons to different use cases.=0A=
=0A=
Such network administrator provided auditing TURN server would also put the=
=0A=
right party in control =96 The network administrator decides what is allowe=
d=0A=
on his network."=0A=
=0A=
Why should a network administrator that wants to block webrtc media, have t=
o=0A=
do more than just closing his firewall for UDP, like below suggested=0A=
"configuring the browser not to do webrtc, normal HTTP black/white lists,=
=0A=
and solutions based on putting something in the HTTP Connect sent to the=0A=
proxy so the proxy can block it"?=0A=
=0A=
[AndyH] The use case of most concern is the one where there is no network a=
dministrator and we need WebRTC to work in those environments by default if=
 that means an administrator who is WebRTC aware has to go to a little effo=
rt to block it then I think that is ok.=0A=
=0A=
Another thing in the second half of the same use case 3.2.5.1:=0A=
Are NAT/firewalls inside the enterprise network assumed? If not, I think th=
e=0A=
second half can be deleted.=0A=
=0A=
" In cases where employees are using RTCWEB applications provided by an=0A=
   external service provider they still want to have the traffic to stay=0A=
   inside their internal network and in addition not load the straddling=0A=
   TURN server, "=0A=
=0A=
ICE establishes a direct connection in this case, not using any TURN server=
=0A=
at all, doesn=92t it? This is then not a problem.=0A=
=0A=
/Karl=0A=
=0A=
-----Ursprungligt meddelande-----=0A=
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Hutt=
on,=0A=
Andrew=0A=
Skickat: den 20 september 2013 19:58=0A=
Till: Magnus Westerlund; Cullen Jennings (fluffy); rtcweb@ietf.org;=0A=
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org=0A=
=C4mne: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-1=
1=0A=
=0A=
On: 17 September 2013 13:01 Magnus Westerlund Wrote:=0A=
> 3.2.3.1.  Description=0A=
>=0A=
>    This use-case is almost identical to the Simple Video Communication=0A=
>    Service use-case (Section 3.2.1).  The difference is that one of the=
=0A=
>    users is behind a FW that only allows http traffic.=0A=
>=0A=
> If a firewall only allows HTTP traffic, then can we really assume that=0A=
> the firewall administrator per default will accept WebRTC Media and=0A=
> Data traffic?=0A=
>=0A=
> I am far from certain of this, and think on a requirement level needs=0A=
> to express a situation where the firewall administrator allows WebRTC=0A=
> across its FW, or at least can easily configure a rule to block it.=0A=
> Thus=0A=
> resulting in that any solution for this needs to be easily=0A=
> identifiable and possible to block.=0A=
>=0A=
=0A=
Stefan already stated that this use case will be changed to take account of=
=0A=
my comments in=0A=
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So the=
=0A=
"only allows HTTP traffic" is going to be removed and changed to describe=
=0A=
the use case when the firewall requires traffic to flow via a HTTP Proxy.=
=0A=
=0A=
We also have a use case when a network specific TURN server is deployed=0A=
(3.2.5.1).=0A=
=0A=
In both cases I agree that a network administrator must have a way to block=
=0A=
webrtc but there are various ways of achieving this including just=0A=
configuring the browser not to do webrtc, normal HTTP black/white lists, an=
d=0A=
also I can imagine solutions based on putting something in the HTTP Connect=
=0A=
sent to the proxy so the proxy can block it.=0A=
=0A=
So I agree that it must be possible to block webrtc traffic but we need to=
=0A=
careful not to specify the solution in the use case.=0A=
=0A=
Andy=0A=
=0A=
=0A=
_______________________________________________=0A=
rtcweb mailing list=0A=
rtcweb@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/rtcweb=0A=
=0A=

From andrew.hutton@siemens-enterprise.com  Sat Sep 21 16:44:33 2013
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 9BECD21F9323 for ; Sat, 21 Sep 2013 16:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level: 
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KS49PxQx5g7 for ; Sat, 21 Sep 2013 16:44:29 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3B21F8E97 for ; Sat, 21 Sep 2013 16:44:24 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 68B4E23F04AB; Sun, 22 Sep 2013 01:44:23 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Sun, 22 Sep 2013 01:44:08 +0200
From: "Hutton, Andrew" 
To: Marc Abrams 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl7fMuig8voiEUG8usawnCEAN5nQ0kde///jhQCAACYIzQ==
Date: Sat, 21 Sep 2013 23:44:06 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BD02E8@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD024F@MCHP04MSX.global-ad.net>, <1379806004047.ef5647a6@Nodemailer>
In-Reply-To: <1379806004047.ef5647a6@Nodemailer>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.196]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17BD02E8MCHP04MSXglobal_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 21 Sep 2013 23:44:33 -0000

--_000_9F33F40F6F2CD847824537F3C4E37DDF17BD02E8MCHP04MSXglobal_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Agreed.

So it may be needed but the rtcweb use case draft is about browser requirem=
ents.

Andy

________________________________
From: Marc Abrams [marc@mocet.com]
Sent: Sunday, September 22, 2013 12:26 AM
To: Hutton, Andrew
Cc: rtcweb@ietf.org; Harald Alvestrand; Bernard Aboba
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcw=
eb-use-cases-and-requirements-11

But phones and ATAs and other IoT devices would.

Marc
________________
+1-949-270-0935



On Sat, Sep 21, 2013 at 4:14 PM, Hutton, Andrew > wrote:

The use case draft section 3.2.5.1 states

"It mustbe possibele to configure the browsers used in the enterprise with =
network specific STUN and TURN servers. This should be possible to achieve =
by autoconfiguration methods."

I had assumed that this meant using the browser configuration scripts in th=
e same way as the browser would discover the HTTP Proxy I can see that DHCP=
 is also an option which might be useful but I am not sure whether browsers=
 would use it.

Andy


From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Bernar=
d Aboba [bernard_aboba@hotmail.com]

Sent: Saturday, September 21, 2013 1:09 AM

To: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcw=
eb-use-cases-and-requirements-11




Harald said:



> In this case, it's "only" a DHCP option, but what new DHCP options do we

> have that have become widely used in the last 10 years?



[BA] And of those, which ones are supported by *browsers*?



I do think it is useful for a browser to be able to locate a local TURN ser=
ver, if this is to happen it will need to be done at the application layer,=
 not via DHCP.






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


--_000_9F33F40F6F2CD847824537F3C4E37DDF17BD02E8MCHP04MSXglobal_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















Agreed.  







So it may be needed but the rtcweb use case draft is about browser req=
uirements.







Andy






From: Marc Abrams [marc@mocet.com]

Sent: Sunday, September 22, 2013 12:26 AM

To: Hutton, Andrew

Cc: rtcweb@ietf.org; Harald Alvestrand; Bernard Aboba

Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ie=
tf-rtcweb-use-cases-and-requirements-11










But phones and ATAs and other IoT devices would.







Marc 


________________

+1-949-270-0935








On Sat, Sep 21, 2013 at 4:14 PM, Hutton, Andrew <and=
rew.hutton@siemens-enterprise.com> wrote:







The use case draft section 3.2.5.1 states 



"It mustbe possibele to configure the browsers used in the enterprise =
with network specific STUN and TURN servers. This should be possible to ach=
ieve by autoconfiguration methods."




I had assumed that this meant using the browser configuration scripts in th=
e same way as the browser would discover the HTTP Proxy I can see that DHCP=
 is also an option which might be useful but I am not sure whether browsers=
 would use it.




Andy 





From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Bernar=
d Aboba [bernard_aboba@hotmail.com]




Sent: Saturday, September 21, 2013 1:09 AM 



To: Harald Alvestrand; rtcweb@ietf.org 



Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcw=
eb-use-cases-and-requirements-11










Harald said: 







> In this case, it's "only" a DHCP option, but what new DHCP o=
ptions do we 



> have that have become widely used in the last 10 years? 







[BA] And of those, which ones are supported by *browsers*? 







I do think it is useful for a browser to be able to locate a local TURN ser=
ver, if this is to happen it will need to be done at the application layer,=
 not via DHCP.














_______________________________________________ 

rtcweb mailing list 

rtcweb@ietf.org 

https://www.ietf.org/mailman/listinfo/rtcweb 
















--_000_9F33F40F6F2CD847824537F3C4E37DDF17BD02E8MCHP04MSXglobal_--

From daniel@pocock.com.au  Sun Sep 22 11:16:51 2013
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 2C7CE11E8110 for ; Sun, 22 Sep 2013 11:16:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DZFoQdiqSML for ; Sun, 22 Sep 2013 11:16:46 -0700 (PDT)
Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5AA11E810B for ; Sun, 22 Sep 2013 11:16:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id 0471415203 for ; Sun, 22 Sep 2013 19:16:45 +0100 (BST)
Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6HN6K9-DOYq2 for ; Sun, 22 Sep 2013 19:16:39 +0100 (BST)
Message-ID: <523F3407.1060204@pocock.com.au>
Date: Sun, 22 Sep 2013 20:16:39 +0200
From: Daniel Pocock 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] determining mic/webcam availability on page load
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, 22 Sep 2013 18:16:51 -0000

Hi,

I'm not sure if this has been discussed before, but I think it would be
very useful for some applications to determine what hardware is
available very early, well before trying to do things like SIP
registration or making a call.

However, if I use the code below, the result is that the user is
prompted twice for permissions, once during the initial hardware
detection and later when they try to make or receive a call.

Regards,

Daniel



navigator.webkitGetUserMedia(

 {audio: true, video: true},

  function (stream) {
          var has_audio = false;
          var has_video = false;
	  if(stream.getAudioTracks().length > 0)
		  has_audio = true;
	  if(stream.getVideoTracks().length > 0)
		  has_video = true;
	  console.log("closing unused stream");
	  stream.stop();
	  delete stream;
          checksDone(has_audio, has_video);
  },

  function(err) {
	  console.log(err.name + ": " + err.message);
          checksDone(false, false);
  }

);


From harald@alvestrand.no  Sun Sep 22 22:06:06 2013
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 DC5B221F9C16 for ; Sun, 22 Sep 2013 22:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.425
X-Spam-Level: 
X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfHLaWp-M+fV for ; Sun, 22 Sep 2013 22:06:00 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 52D4521F8F61 for ; Sun, 22 Sep 2013 22:06:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3E1239E24F for ; Mon, 23 Sep 2013 07:05: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 Uv91dLI1WmLn for ; Mon, 23 Sep 2013 07:05:48 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:c879:8be:f46e:7da8] (unknown [IPv6:2001:470:de0a:27:c879:8be:f46e:7da8]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3CAFF39E058 for ; Mon, 23 Sep 2013 07:05:48 +0200 (CEST)
Message-ID: <523FCC86.8070302@alvestrand.no>
Date: Mon, 23 Sep 2013 07:07:18 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <523F3407.1060204@pocock.com.au>
In-Reply-To: <523F3407.1060204@pocock.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] determining mic/webcam availability on page load
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, 23 Sep 2013 05:06:06 -0000

On 09/22/2013 08:16 PM, Daniel Pocock wrote:
>
>
> Hi,
>
> I'm not sure if this has been discussed before, but I think it would be
> very useful for some applications to determine what hardware is
> available very early, well before trying to do things like SIP
> registration or making a call.
>
> However, if I use the code below, the result is that the user is
> prompted twice for permissions, once during the initial hardware
> detection and later when they try to make or receive a call.

This is an API issue, so it should go to public-webrtc@w3.org

But it's a solved issue in the spec, even though the implementations may 
be lagging: Use the getSourceInfos call to probe, not the getUserMedia call.


http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-1
>
> Regards,
>
> Daniel
>
>
>
> navigator.webkitGetUserMedia(
>
>   {audio: true, video: true},
>
>    function (stream) {
>            var has_audio = false;
>            var has_video = false;
> 	  if(stream.getAudioTracks().length > 0)
> 		  has_audio = true;
> 	  if(stream.getVideoTracks().length > 0)
> 		  has_video = true;
> 	  console.log("closing unused stream");
> 	  stream.stop();
> 	  delete stream;
>            checksDone(has_audio, has_video);
>    },
>
>    function(err) {
> 	  console.log(err.name + ": " + err.message);
>            checksDone(false, false);
>    }
>
> );
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From stefan.lk.hakansson@ericsson.com  Sun Sep 22 22:46:23 2013
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 E260121F9005 for ; Sun, 22 Sep 2013 22:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.824
X-Spam-Level: 
X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QZ8ktzgZOLv for ; Sun, 22 Sep 2013 22:46:19 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id AD9A121F9F50 for ; Sun, 22 Sep 2013 22:46:18 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-60-523fd5a90f72
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D0.62.25272.9A5DF325; Mon, 23 Sep 2013 07:46:17 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 23 Sep 2013 07:46:16 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] determining mic/webcam availability on page load
Thread-Index: AQHOt7/sB8mnpQh9a0CUbDNpec98Cg==
Date: Mon, 23 Sep 2013 05:46:16 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C39585F@ESESSMB209.ericsson.se>
References: <523F3407.1060204@pocock.com.au> <523FCC86.8070302@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvre7Kq/ZBBueuy1oc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4dPIKW8F+wYr2Ey+ZGxjb+LoYOTkkBEwk 5h49wA5hi0lcuLeerYuRi0NI4CijxP2fN1khnCWMEu3XPjKCVLEJBEps3beADcQWEdCReLi/ gQnEZhZQl7iz+BzYJGEBN4mjt38wQdS4S2zp+8UCYetJ/D25lBnEZhFQlZgy9ynYTF4BX4nN J3pZQWwhIPv1qX9gcxiBLvp+ag3UfHGJW0/mM0FcKiCxZM95ZghbVOLl43+sELaSxI8Nl1gg 6vUkbkydwgZha0ssW/iaGWKXoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaM4tTgpN93I YBMjMB4ObvltsYPx8l+bQ4zSHCxK4rxb9M4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC8 Y7756usX15ND7hU33edqtQiYxRopvGZxhcucTwbHHhiXxc/yuTlVpGEyj1v7thlcTI+ky1Yv m3AwYqX1Mfv86DblebvPrPNtc3j96vLpQps+1XQ55laZzW+mLXArKukXZ04+aj7JKJL7kt7y TS/dm0JqT+mv4Jx9xag3MFA69ur1tclf7nYqsRRnJBpqMRcVJwIAoutjcFUCAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] determining mic/webcam availability on page load
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, 23 Sep 2013 05:46:24 -0000

On 2013-09-23 07:06, Harald Alvestrand wrote:=0A=
> On 09/22/2013 08:16 PM, Daniel Pocock wrote:=0A=
>>=0A=
>>=0A=
>> Hi,=0A=
>>=0A=
>> I'm not sure if this has been discussed before, but I think it would be=
=0A=
>> very useful for some applications to determine what hardware is=0A=
>> available very early, well before trying to do things like SIP=0A=
>> registration or making a call.=0A=
>>=0A=
>> However, if I use the code below, the result is that the user is=0A=
>> prompted twice for permissions, once during the initial hardware=0A=
>> detection and later when they try to make or receive a call.=0A=
>=0A=
> This is an API issue, so it should go to public-webrtc@w3.org=0A=
=0A=
As this deals with access to input devices, I think the correct place is =
=0A=
actually public-media-capture@w3.org=0A=
=0A=
>=0A=
> But it's a solved issue in the spec, even though the implementations may=
=0A=
> be lagging: Use the getSourceInfos call to probe, not the getUserMedia ca=
ll.=0A=
>=0A=
>=0A=
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-1=0A=
>>=0A=
>> Regards,=0A=
>>=0A=
>> Daniel=0A=
>>=0A=
>>=0A=
>>=0A=
>> navigator.webkitGetUserMedia(=0A=
>>=0A=
>>    {audio: true, video: true},=0A=
>>=0A=
>>     function (stream) {=0A=
>>             var has_audio =3D false;=0A=
>>             var has_video =3D false;=0A=
>> 	  if(stream.getAudioTracks().length > 0)=0A=
>> 		  has_audio =3D true;=0A=
>> 	  if(stream.getVideoTracks().length > 0)=0A=
>> 		  has_video =3D true;=0A=
>> 	  console.log("closing unused stream");=0A=
>> 	  stream.stop();=0A=
>> 	  delete stream;=0A=
>>             checksDone(has_audio, has_video);=0A=
>>     },=0A=
>>=0A=
>>     function(err) {=0A=
>> 	  console.log(err.name + ": " + err.message);=0A=
>>             checksDone(false, false);=0A=
>>     }=0A=
>>=0A=
>> );=0A=
>>=0A=
>> _______________________________________________=0A=
>> rtcweb mailing list=0A=
>> rtcweb@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
> _______________________________________________=0A=
> rtcweb mailing list=0A=
> rtcweb@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
=0A=

From sergio.garcia.murillo@gmail.com  Mon Sep 23 02:13:43 2013
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 4B87E11E8175 for ; Mon, 23 Sep 2013 02:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmvPpDc4XKtQ for ; Mon, 23 Sep 2013 02:13:42 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0D11E8174 for ; Mon, 23 Sep 2013 02:13:41 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hm2so1953860wib.10 for ; Mon, 23 Sep 2013 02:13:41 -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=ROLq+B6cxT//D99LIEPTcDowvIrG2g2/brIQPq6yaGg=; b=ftJYz9Uro+/KZk3Z3LDcFqfgCMETmIic23f+MuZ6EvM7Iec1no3TkBvh5kMS8aBllc OtuamDlZuKSWCsTdw+A5oXci1GBLuVrPZ4/wWej/nMkUEMsrfT9d/KhPIkDOSurCm9AV +4PqdrUyCiinicgU/gzHkoXuOF6H34oOPsQsAGRJ8Pg8HDyhpmuyZABKCPlUYVkuimPi p/XDfvNenNsLKH3Z9+mWmdXDGFM2ROiPgwxNZYhe5W/CdQXpGc6lXVDztQgEADuShnp+ 9st7sZN7grh07NWoqJiwfvaxLuJvhNDcmcAhguPmmbucTbCsYkxA9LlG9azFmyX4eYnl 6t7g==
X-Received: by 10.194.60.73 with SMTP id f9mr29348wjr.65.1379927621247; Mon, 23 Sep 2013 02:13:41 -0700 (PDT)
Received: from [192.168.1.45] (54.Red-83-61-124.dynamicIP.rima-tde.net. [83.61.124.54]) by mx.google.com with ESMTPSA id i8sm24165047wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 02:13:40 -0700 (PDT)
Message-ID: <52400640.4010606@gmail.com>
Date: Mon, 23 Sep 2013 11:13:36 +0200
From: Sergio Garcia Murillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5238446D.8050700@ericsson.com>
In-Reply-To: <5238446D.8050700@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 23 Sep 2013 09:13:43 -0000

+1

Shouldn't we add it as a requirement also?

Best regards
Sergio
El 17/09/2013 14:00, Magnus Westerlund escribió:
> 3.2.3.1.  Description
>
>     This use-case is almost identical to the Simple Video Communication
>     Service use-case (Section 3.2.1).  The difference is that one of the
>     users is behind a FW that only allows http traffic.
>
> If a firewall only allows HTTP traffic, then can we really assume that
> the firewall administrator per default will accept WebRTC Media and Data
> traffic?
>
> I am far from certain of this, and think on a requirement level needs to
> express a situation where the firewall administrator allows WebRTC
> across its FW, or at least can easily configure a rule to block it. Thus
> resulting in that any solution for this needs to be easily identifiable
> and possible to block.


From tireddy@cisco.com  Mon Sep 23 02:28:45 2013
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 89EE521F8E85 for ; Mon, 23 Sep 2013 02:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level: 
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz4jBXyLUxih for ; Mon, 23 Sep 2013 02:28:35 -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 5F92B21F9D8B for ; Mon, 23 Sep 2013 02:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6089; q=dns/txt; s=iport; t=1379928489; x=1381138089; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fkVlJgalUv7feLVA9PlutZAG9tMbQa4l/X2Q7pW1goQ=; b=MAuohFuw35LKPYeeIXfeUHDxSVAuVZPUusdX8ibFDoGZzxKjCNA38EEV leNgQwOFyphn+cS6QMxRTcEo85l0iAScvGz9unWBrEKtJQRBrEaxU3mVd 2927lBynOl/Ac8yszCcbmAy79esCw4n+ixeAIMr/BORXcoNVmYb8hJiuJ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAEMJQFKtJXHB/2dsb2JhbABZgkNEOFLBMIEbFnSCJQEBAQMBLVELAgEIEQQBAQsdBzIUCQgCBAESCId3BrpXjzQ3AYMegQADqXOBZoE+gio
X-IronPort-AV: E=Sophos;i="4.90,961,1371081600";  d="scan'208,217";a="263275224"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 23 Sep 2013 09:28:08 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8N9S87j017943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 09:28:08 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 04:28:08 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: Bernard Aboba , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl7phpjl7nuzyEGy4R2M7L0wjJnP02fA
Date: Mon, 23 Sep 2013 09:28:07 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1907D036@xmb-rcd-x10.cisco.com>
References: ,  <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>, <523CBB62.6000007@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.39.64.227]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1907D036xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 23 Sep 2013 09:28:45 -0000

--_000_913383AAA69FF945B8F946018B75898A1907D036xmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Bernard Aboba
Sent: Saturday, September 21, 2013 5:40 AM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcw=
eb-use-cases-and-requirements-11

Harald said:

> In this case, it's "only" a DHCP option, but what new DHCP options do we
> have that have become widely used in the last 10 years?

[BA] And of those, which ones are supported by *browsers*?

I do think it is useful for a browser to be able to locate a local TURN ser=
ver, if this is to happen it will need to be done at the application layer,=
 not via DHCP.

 [TR] The other way to locate local TURN servers could be to use DNS-Based =
Service Discovery.

-Tiru.

--_000_913383AAA69FF945B8F946018B75898A1907D036xmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 








From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Bernard Aboba

Sent: Saturday, September 21, 2013 5:40 AM

To: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ie=
tf-rtcweb-use-cases-and-requirements-11






 




Harald said: 

  

> In this case, it's "only" a DHCP option, but what new DHCP o=
ptions do we 

> have that have become widely used in the last 10 years?



[BA] And of those, which ones are supported by *browsers*?

 

I do think it is useful for a browser to be able to locate a local TURN ser=
ver, if this is to happen it will need to be done at the application layer,=
 not via DHCP.



 


 [TR] The other way to locate local TURN servers could =
be to use DNS-Based Service Discovery.


 


-Tiru.










--_000_913383AAA69FF945B8F946018B75898A1907D036xmbrcdx10ciscoc_--

From cb.list6@gmail.com  Mon Sep 23 09:58:06 2013
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 3379521F9D31 for ; Mon, 23 Sep 2013 09:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTULiA7nWn5 for ; Mon, 23 Sep 2013 09:58:05 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC221F9E4D for ; Mon, 23 Sep 2013 09:58:01 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id b13so3384995wgh.35 for ; Mon, 23 Sep 2013 09:58:01 -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=k26qyE8szlb3t8qBQGy0XaIWdW7NOFr6hzZcLRuUcvs=; b=0a3lbu36H1BHH5c/By7Tz7q9bIyJXx1tqzsjPXi4g31a/nk4zPg8mgWRpSF1PlUkmg Q6DWyEooM+sBvbZiZY/W8HU1zaVUUyitU+tzgdm+7btXhE6yAGFK1DzBFPWGGiM8q9oM y3n4+KkbqM3KyHR2zQArfh3kV7xDmxJmKrN4GgnQi+EwxyCNcF4fLKvOuWLaFIw+WhHm ov22YfMFfpNK2q86uhSbzP6FdFKyQ2o45LIhVU9Xuj5GkMXj9/CKClrfnlrh4Qe+PEXF gLyEQm+C3bojC8UIX+5tqlAsJBeCCQSUZZ1tm01qd2pExqjHT4nHMJR9yIZ55Wl8rZr0 KjFQ==
MIME-Version: 1.0
X-Received: by 10.180.13.174 with SMTP id i14mr14388953wic.49.1379955481069; Mon, 23 Sep 2013 09:58:01 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Mon, 23 Sep 2013 09:58:01 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Mon, 23 Sep 2013 09:58:01 -0700 (PDT)
In-Reply-To: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Mon, 23 Sep 2013 09:58:01 -0700
Message-ID: 
From: "cb.list6" 
To: Karl Stahl 
Content-Type: multipart/alternative; boundary=001a11c227e8416da104e70feca1
Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 23 Sep 2013 16:58:06 -0000

--001a11c227e8416da104e70feca1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sep 20, 2013 8:43 AM, "Karl Stahl"  wrote:
>
> For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets
the
> TURN server address from the web application, or gets it configured by a
LAN
> admin via an =93admin policy template=94.
>
> However, there is a need (motivations below) for the TURN server address
to
> be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, and
> the OTT channel in mobiles have their own method I=92ve been told). Simpl=
y
> put, just as you often get your IP-address, DNS address, etc.
automatically
> from the network access, you should also get the TURN server address.
>
> I suggest the following is added to the end of use case (which today is
> about multiple TURN servers)
> 3.2.4.  Simple Video Communication Service, global service provider
> 3.2.4.1.  Description
> ...
> "A network service provider must be able to automatically supply a TURN
> server addresses to the browser when accessing a network. The address may
> come via DHCP or a similar mechanism (maybe RA - Router Advertisement -
for
> IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whateve=
r
> method the mobile OTT channels use). The mechanism should be similar to
> automatically getting the IP-address, DNS address, etc.. and need
extensions
> to current recommendations/standards.
>
> There are several reasons for a network service provider to supply a TURN
> server as part of his offered access:
> - to keep media paths short, specifically not sending media outside its
own
> network to some distant application provided TURN server
> - to support mobility, i.e. you may want to move from a LAN with a
> configured TURN server to accessing via WiFi or 3G/4G OTT channels

I have not read the draft but would like to make it clear that no 2g/3g/4g
provider uses dhcp over the mobile network so this dhcp solution would not
apply.

CB

> - to offer a media path with better quality (than best effort data
traffic).
> Getting =93WebRTC-ready=94 access and we look forward to telepresence for
> everyone.
>
> An enterprise network that want to keep a restrictive firewall not
allowing
> UDP traffic, could provide a real-time path using a TURN server
paralleling
> the firewall, instead of tunneling RTP through always open http or https
> ports resulting in RTP media over TCP =96 with severe quality problems fr=
om
> TCP retransmissions of dropped packets. The TURN server address is most
> easily provided in the same way as the IP address and DNS address. (That
> would also put the right party in control =96 The network provider decide=
s
> what is allowed on his network.)
>
> This browser should select which available TURN server address to use in
the
> following priority order, where ICE could be used to try several:
>
> 1) TURN server address configured in the browser by the user (special
cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an
=93admin
> policy template=94
> 3) TURN server address supplied by DHCP or similar automatic network
method
> 4) TURN server address being supplied by the web application"
>
> Two new requirements can be extracted:
> "   ----------------------------------------------------------------
>    F40     The browser must support retrieving TURN server addresses via
> DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6,
an
> addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method
the
> mobile OTT channels use). The mechanism should be similar to automaticall=
y
> getting the IP-address, DNS address, etc..
>    ----------------------------------------------------------------
>    F42     This browser should select which available TURN server address
to
> use in the following priority order, where ICE could be used to try
several:
>
> 1) TURN server address configured in the browser by the user (special
cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an
=93admin
> policy template=94
> 3) TURN server address supplied by DHCP or similar automatic network
method
> 4) TURN server address being supplied by the web application
> ----------------------------------------------------------------"
>
> I suppose this also will add to:
> 5.  IANA Considerations
>    TBD
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Cu=
llen
> Jennings (fluffy)
> Skickat: den 4 september 2013 18:24
> Till: rtcweb@ietf.org
> =C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
> We would like to start a working group last call of
> draft-ietf-rtcweb-use-cases-and-requirements-11.
>
> Please send comments by the end of the day on September 21.
>
> Thank you,
>
> The chairs =85.
>
>
>
>
> _______________________________________________
> 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

--001a11c227e8416da104e70feca1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Sep 20, 2013 8:43 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote:

>

> For NAT/Firewall traversal WebRTC uses ICE, where the browser today ge=
ts the

> TURN server address from the web application, or gets it configured by=
 a LAN

> admin via an =93admin policy template=94.

>

> However, there is a need (motivations below) for the TURN server addre=
ss to

> be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, =
and

> the OTT channel in mobiles have their own method I=92ve been told). Si=
mply

> put, just as you often get your IP-address, DNS address, etc. automati=
cally

> from the network access, you should also get the TURN server address.<=
br>
>

> I suggest the following is added to the end of use case (which today i=
s

> about multiple TURN servers)

> 3.2.4. =A0Simple Video Communication Service, global service provider<=
br>
> 3.2.4.1. =A0Description

> ...

> "A network service provider must be able to automatically supply =
a TURN

> server addresses to the browser when accessing a network. The address =
may

> come via DHCP or a similar mechanism (maybe RA - Router Advertisement =
- for

> IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or what=
ever

> method the mobile OTT channels use). The mechanism should be similar t=
o

> automatically getting the IP-address, DNS address, etc.. and need exte=
nsions

> to current recommendations/standards.

>

> There are several reasons for a network service provider to supply a T=
URN

> server as part of his offered access:

> - to keep media paths short, specifically not sending media outside it=
s own

> network to some distant application provided TURN server

> - to support mobility, i.e. you may want to move from a LAN with a

> configured TURN server to accessing via WiFi or 3G/4G OTT channels


I have not read the draft but would like to make it clear th=
at no 2g/3g/4g provider uses dhcp over the mobile network so this dhcp solu=
tion would not apply. 


CB


> - to offer a media path with better quality (than best =
effort data traffic).

> Getting =93WebRTC-ready=94 access and we look forward to telepresence =
for

> everyone.

>

> An enterprise network that want to keep a restrictive firewall not all=
owing

> UDP traffic, could provide a real-time path using a TURN server parall=
eling

> the firewall, instead of tunneling RTP through always open http or htt=
ps

> ports resulting in RTP media over TCP =96 with severe quality problems=
 from

> TCP retransmissions of dropped packets. The TURN server address is mos=
t

> easily provided in the same way as the IP address and DNS address. (Th=
at

> would also put the right party in control =96 The network provider dec=
ides

> what is allowed on his network.)

>

> This browser should select which available TURN server address to use =
in the

> following priority order, where ICE could be used to try several:

>

> 1) TURN server address configured in the browser by the user (special =
cases,

> normally not used)

> 2) TURN server address configured by the network administrator via an =
=93admin

> policy template=94

> 3) TURN server address supplied by DHCP or similar automatic network m=
ethod

> 4) TURN server address being supplied by the web application"

>

> Two new requirements can be extracted:

> " =A0 -----------------------------------------------------------=
-----

> =A0 =A0F40 =A0 =A0 The browser must support retrieving TURN server add=
resses via

> DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv=
6, an

> addition to the IPCP protocol like RFC1877 for PPPoE, or whatever meth=
od the

> mobile OTT channels use). The mechanism should be similar to automatic=
ally

> getting the IP-address, DNS address, etc..

> =A0 =A0---------------------------------------------------------------=
-

> =A0 =A0F42 =A0 =A0 This browser should select which available TURN ser=
ver address to

> use in the following priority order, where ICE could be used to try se=
veral:

>

> 1) TURN server address configured in the browser by the user (special =
cases,

> normally not used)

> 2) TURN server address configured by the network administrator via an =
=93admin

> policy template=94

> 3) TURN server address supplied by DHCP or similar automatic network m=
ethod

> 4) TURN server address being supplied by the web application

> ----------------------------------------------------------------"=


>

> I suppose this also will add to:

> 5. =A0IANA Considerations

> =A0 =A0TBD

>

> /Karl

>

>

> -----Ursprungligt meddelande-----

> Fr=E5n: rtcweb-bounces@ietf=
.org [mailto:rtcweb-bounces@=
ietf.org] F=F6r Cullen

> Jennings (fluffy)

> Skickat: den 4 september 2013 18:24

> Till: rtcweb@ietf.org

> =C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-=
11

>

>

> We would like to start a working group last call of

> draft-ietf-rtcweb-use-cases-and-requirements-11.

>

> Please send comments by the end of the day on September 21.

>

> Thank you,

>

> The chairs =85.

>

>

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb




--001a11c227e8416da104e70feca1--

From dwing@cisco.com  Mon Sep 23 10:56:41 2013
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 D3ADC21F9DB0 for ; Mon, 23 Sep 2013 10:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.434
X-Spam-Level: 
X-Spam-Status: No, score=-111.434 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FdGq0DoMSYA for ; Mon, 23 Sep 2013 10:56:23 -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 3FE4621F9CE8 for ; Mon, 23 Sep 2013 10:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7919; q=dns/txt; s=iport; t=1379958980; x=1381168580; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zIyAe6h2KQk1qb2Ui92sTI8e+RkEwOQ7KB8dgo4CbLA=; b=COAL1MZJEsbCZBFGDwKZ/NM9YiV+WrcA1NBxuPgk33XMtC5eIaUrYUAA BlqnLypZJRqnD1FdhqbYdumok9kUM+lkoldeiVNntNDcHc3AY1k6lUp3l t1idzMfzWyinHKWKhB/46aru8jbfac8SgdEg2rz6MWTf9amyfXhmQnrh8 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAMp/QFKrRDoJ/2dsb2JhbABZgwc4wTBKgSIWdIIlAQEBAwEBAQFkAQYEBwULCz8HJx8RBhMJEodkBQ27Vo4sgQYzB4MegQADiTiORJF3g0QcgSwJFwI
X-IronPort-AV: E=Sophos;i="4.90,964,1371081600"; d="scan'208";a="92811511"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Sep 2013 17:56:14 +0000
Received: from sjc-vpn3-476.cisco.com (sjc-vpn3-476.cisco.com [10.21.65.220]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8NHuDPt003504; Mon, 23 Sep 2013 17:56:13 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing 
In-Reply-To: <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>
Date: Mon, 23 Sep 2013 10:57:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com>
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>
To: Karl Stahl 
X-Mailer: Apple Mail (2.1508)
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 23 Sep 2013 17:56:42 -0000

On Sep 21, 2013, at 2:44 PM, Karl Stahl  wrote:

> Yet another thing related to
> draft-ietf-rtcweb-use-cases-and-requirements-11:
> It is about payload type, PT=3D, in SDP and RTP, so I am copying =
MMUSIC
>=20
> Network service providers have expressed an interest to know whether =
packets
> carry audio or video, to be able to handle them differently in the =
network
> (e.g. quality wise). PT is visible outside the encrypted payload in =
RTP,
> however if dynamic payload types PT:96-127 are used, you cannot know =
what
> the payload is without knowledge of the SDP (which we for WebRTC must =
assume
> the network provider has no knowledge of).
>=20
> In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I =
see
> no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC.
>=20
> So, can we have payload types assigned to codecs that will be =
recommended
> for WebRTC (PT:35-71 are unassigned)?
> Or can we at least split dynamic payload types PT:96-127 into groups =
for
> audio and video codecs?
>=20
>=20
> I relation to that simple request, one may wonder how the network =
anyway can
> know what is carried in an UPD packet (the RTP header is no reserved =
field -
> it could be the payload of something else).
>=20
> Quality related requirements F38, A23 and A26 in the use case draft,
> nowadays only seem to relate to the browsers, not assuming that =
diffserve
> bits or similar are conveyed to the network. That is realistic, since =
most
> operating systems don't allow quality markings (diffserve, TOS) of =
packets.
> However, 3.2.1.  Simple Video Communication Service, mentions "The web
> service monitors the quality of the service (focus on quality of audio =
and
> video) the end-users experience.". I don't understand how "The *web =
service*
> monitors" based on the listed requirements. Should it be "The =
*browsers*
> monitors"?
>=20
> What are then the possibilities for a network to classify traffic for
> quality or other purposes?

I agree there is a problem here, and have been trying to convince others =
there is a problem that needs to be solved.  So far, there appears to be =
scant agreement there is a problem.  See thread on TSVWG starting at =
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12182.html.  The =
solution I am pitching is an extension to PCP, draft-wing-pcp-flowdata.  =
Another solution is MALICE which adds information to the ICE =
connectivity checks (bandwidth, drop preference, etc.) which can be =
DPI'd by network devices.

But before getting deep on solutions, we first we need some consensus =
that some flows need different handling than other flows, and then =
acquiescence that existing techniques do not solve the problem (RSVP, =
NSIS, Diffserv).  Unfortunately the industry doesn't yet seem to agree =
there is even a problem.

-d


>=20
> 3G/4G networks have DPIs (Deep Packet Inspection) - such box may guess =
what
> encrypted RTP traffic is... or may not...
>=20
> Real time communication protocols using ICE as a pre-protocol to =
establish
> media paths give a possibility though. If the network provider offers =
a TURN
> server at his access, and enforces the TURN server to be used (by =
eating
> STUN packets), then the RTP flows set up through the TURN server could
> classify and mark packets. Then it is useful to know whether it is an =
audio
> or video packet by looking at the payload type.
>=20
> A LAN firewall, can also include a TURN-server, that in addition to
> classifying and marking packets for the transport network (if honored =
-
> which rarely is the case on the Internet today), it can also =
prioritize and
> traffic shape so the RTP traffic at least is undisturbed through a =
data
> crowded Internet access.
>=20
> A more difficult request comes from networks using bandwidth =
reservation
> (RSVP) for quality, like mobile and cable networks. Such networks =
would
> benefit from knowing the bandwidth used, but that is not fixes for =
advanced
> codecs like the ones considered for WebRTC. One way would be to =
reserve
> maximum bandwidth, and possibly repeat the reservation if less is =
actually
> used.
>=20
> /Karl
>=20
>=20
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Karl
> Stahl
> Skickat: den 21 september 2013 02:16
> Till: rtcweb@ietf.org;
> draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
> =C4mne: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
>=20
> While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, =
here are
> a few "telephony related" WebRTC things I think should be clarified in =
the
> use cases.=20
>=20
>=20
> 3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ... =20=

> The invited user might accept or reject the session.=20
> [Suggest adding] The invited user might accept only audio, rejecting =
video
> (even if a camera is enabled). A user may also select to initiate an =
audio
> session, without video.
>=20
> And in API requirements:
>   ----------------------------------------------------------------
>   A1      The Web API must provide means for the application to ask =
the
> browser for permission to use cameras and microphones, individually as =
input
> devices. (One must be able to answer with voice only - declining =
video.)
>   ----------------------------------------------------------------
> Same under
> 6.2.  Browser Considerations
> ...
> The browser is expected to provide mechanisms for users to revise and =
even
> completely revoke consent to use device resources such as camera and
> microphone. [Suggest adding] Specifically, a user must be given the
> opportunity to only accept audio in a video call invitation.
>=20
>=20
>=20
> 3.2.12.  Multiparty video communication
> 3.2.12.1.  Description
> ...
> [Suggest adding] It is essential that automatic adjustments of =
microphone
> volume is disabled, or microphones not spoken into are muted. (This is =
a
> serious problem with most soft clients (SIP clients) of today, =
plaguing
> conferences with ever increasing noise from silent participants.)
>=20
> And in API requirements:
>   ----------------------------------------------------------------
>   A15     The Web API must provide means for the web application to =
adjust
> the level in audio streams.
>  ----------------------------------------------------------------
>   Axx     The Web API must provide means to disable any automatic =
volume
> adjustment in the sent audio streams. (To avoid disturbing noise in
> conferences - making many softclients unusable).=20
>   ----------------------------------------------------------------
>=20
>=20
>=20
> 3.2.6.  Simple Video Communication Service, access change 3.2.6.1.
> Description ...
> the user has to start a trip during the session. The communication =
device
> automatically changes to use WiFi when the Ethernet cable is removed =
and
> then moves to cellular access to the Internet when moving out of WiFi
> coverage.  The session continues even though the access method =
changes.
>=20
> [Question] Is this some sort of roaming without network support =
(please
> clarify)? Getting a new access will also give the client a new IP =
address,
> won't it? How could then the session continue? The browsers will have =
no
> signaling connection and cannot renegotiate a media connection, can =
they?
>=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 karl.stahl@intertex.se  Mon Sep 23 12:57:58 2013
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 0C53C21F9DD5 for ; Mon, 23 Sep 2013 12:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.268,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP764rN512uV for ; Mon, 23 Sep 2013 12:57:53 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id D8AA621F9E62 for ; Mon, 23 Sep 2013 12:57:49 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309232157470227; Mon, 23 Sep 2013 21:57:47 +0200
From: "Karl Stahl" 
To: "'cb.list6'" 
References: 	<523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> 
In-Reply-To: 
Date: Mon, 23 Sep 2013 21:57:47 +0200
Message-ID: <098001ceb897$2d1c6090$875521b0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0981_01CEB8A7.F0A53090"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac64fg/AV7BTiDkNShCWDRBfQSHvygAFyukA
Content-Language: sv
Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 23 Sep 2013 19:57:58 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0981_01CEB8A7.F0A53090
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

CB > I have not read the draft but would like to make it clear that no
2g/3g/4g provider uses dhcp over the mobile network so this dhcp =
solution
would not apply.=20

[Karl] True, my proposed requirement was:=20

> The browser must support retrieving TURN server addresses via DHCP or =
a
similar mechanism (maybe RA - Router Advertisement - for IPv6, an
addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method =
the
mobile OTT channels use).

=20

=93or whatever method the  mobile OTT channels use=94

is of course not proper language =96 3G/4G do provide IP and DNS =
addresses by
some method and the same is proposed for a network provided TURN server
address.

=20

Actually, it is up to the OS to retrieve, and the browser should only =
use it
for its ICE implementation.

=20

If (hopefully) such network provided TURN server addresses becomes
available, the next suggested browser requirement becomes important:

=20

> The browser should select which available TURN server address to
> use in the following priority order, where ICE could be used to try
several:
>
> 1) TURN server address configured in the browser by the user (special
cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an
=93admin
> policy template=94
> 3) TURN server address supplied by DHCP or similar automatic network
method
> 4) TURN server address being supplied by the web application=20

=20

I believe step 2) and 4) is implemented in Chrome today

/Karl



=20

=20

=20

Fr=E5n: cb.list6 [mailto:cb.list6@gmail.com]=20
Skickat: den 23 september 2013 18:58
Till: Karl Stahl
Kopia: rtcweb@ietf.org; Cullen Jennings (fluffy)
=C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

=20


On Sep 20, 2013 8:43 AM, "Karl Stahl"  wrote:
>
> For NAT/Firewall traversal WebRTC uses ICE, where the browser today =
gets
the
> TURN server address from the web application, or gets it configured by =
a
LAN
> admin via an =93admin policy template=94.
>
> However, there is a need (motivations below) for the TURN server =
address
to
> be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, =
and
> the OTT channel in mobiles have their own method I=92ve been told). =
Simply
> put, just as you often get your IP-address, DNS address, etc.
automatically
> from the network access, you should also get the TURN server address.
>
> I suggest the following is added to the end of use case (which today =
is
> about multiple TURN servers)
> 3.2.4.  Simple Video Communication Service, global service provider
> 3.2.4.1.  Description
> ...
> "A network service provider must be able to automatically supply a =
TURN
> server addresses to the browser when accessing a network. The address =
may
> come via DHCP or a similar mechanism (maybe RA - Router Advertisement =
-
for
> IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or =
whatever
> method the mobile OTT channels use). The mechanism should be similar =
to
> automatically getting the IP-address, DNS address, etc.. and need
extensions
> to current recommendations/standards.
>
> There are several reasons for a network service provider to supply a =
TURN
> server as part of his offered access:
> - to keep media paths short, specifically not sending media outside =
its
own
> network to some distant application provided TURN server
> - to support mobility, i.e. you may want to move from a LAN with a
> configured TURN server to accessing via WiFi or 3G/4G OTT channels

I have not read the draft but would like to make it clear that no =
2g/3g/4g
provider uses dhcp over the mobile network so this dhcp solution would =
not
apply.=20

CB

> - to offer a media path with better quality (than best effort data
traffic).
> Getting =93WebRTC-ready=94 access and we look forward to telepresence =
for
> everyone.
>
> An enterprise network that want to keep a restrictive firewall not
allowing
> UDP traffic, could provide a real-time path using a TURN server
paralleling
> the firewall, instead of tunneling RTP through always open http or =
https
> ports resulting in RTP media over TCP =96 with severe quality problems =
from
> TCP retransmissions of dropped packets. The TURN server address is =
most
> easily provided in the same way as the IP address and DNS address. =
(That
> would also put the right party in control =96 The network provider =
decides
> what is allowed on his network.)
>
> This browser should select which available TURN server address to use =
in
the
> following priority order, where ICE could be used to try several:
>
> 1) TURN server address configured in the browser by the user (special
cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an
=93admin
> policy template=94
> 3) TURN server address supplied by DHCP or similar automatic network
method
> 4) TURN server address being supplied by the web application"
>
> Two new requirements can be extracted:
> "   ----------------------------------------------------------------
>    F40     The browser must support retrieving TURN server addresses =
via
> DHCP or a similar mechanism (maybe RA - Router Advertisement - for =
IPv6,
an
> addition to the IPCP protocol like RFC1877 for PPPoE, or whatever =
method
the
> mobile OTT channels use). The mechanism should be similar to =
automatically
> getting the IP-address, DNS address, etc..
>    ----------------------------------------------------------------
>    F42     This browser should select which available TURN server =
address
to
> use in the following priority order, where ICE could be used to try
several:
>
> 1) TURN server address configured in the browser by the user (special
cases,
> normally not used)
> 2) TURN server address configured by the network administrator via an
=93admin
> policy template=94
> 3) TURN server address supplied by DHCP or similar automatic network
method
> 4) TURN server address being supplied by the web application
> ----------------------------------------------------------------"
>
> I suppose this also will add to:
> 5.  IANA Considerations
>    TBD
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Cullen
> Jennings (fluffy)
> Skickat: den 4 september 2013 18:24
> Till: rtcweb@ietf.org
> =C4mne: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
> We would like to start a working group last call of
> draft-ietf-rtcweb-use-cases-and-requirements-11.
>
> Please send comments by the end of the day on September 21.
>
> Thank you,
>
> The chairs =85.
>
>
>
>
> _______________________________________________
> 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


------=_NextPart_000_0981_01CEB8A7.F0A53090
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


CB =
&g=
t; I have not read the draft but would like to =
make it clear that no 2g/3g/4g provider uses dhcp over the mobile =
network so this dhcp solution would not apply. =

[Karl] True, my proposed =
requirement was: 
> The browser must support retrieving TURN server =
addresses via DHCP or a similar mechanism (maybe RA - Router =
Advertisement - for IPv6, an
addition to the IPCP protocol like =
RFC1877 for PPPoE, or whatever method the =A0mobile OTT channels =
use).
 
“or whatever method the =A0mobile OTT channels =
use”
is of course not proper language – 3G/4G do provide =
IP and DNS addresses by some method and the same is proposed for a =
network provided TURN server address.
 
Actually, it is up to the OS to =
retrieve, and the browser should only use it for its ICE =
implementation.
 
If (hopefully) such network provided TURN server addresses =
becomes available, the next suggested browser requirement becomes =
important:
 
> The browser should select which available TURN server =
address to
> use in the following priority order, where ICE could =
be used to try several:
>
> 1) TURN server address =
configured in the browser by the user (special cases,
> normally =
not used)
> 2) TURN server address configured by the network =
administrator via an “admin
> policy template”
> =
3) TURN server address supplied by DHCP or similar automatic network =
method
> 4) TURN server address being supplied by the web =
application 
 
I believe step 2) and 4) is implemented in Chrome =
today
/Karl

 
 
 
Fr=E5n: cb.list6 =
[mailto:cb.list6@gmail.com] 
Skickat: den 23 september 2013 =
18:58
Till: Karl Stahl
Kopia: rtcweb@ietf.org; =
Cullen Jennings (fluffy)
=C4mne: Re: [rtcweb] TURN server =
address via DHCP, WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
 

On Sep 20, 2013 8:43 =
AM, "Karl Stahl" <karl.stahl@intertex.se> =
wrote:
>
> For NAT/Firewall traversal WebRTC uses ICE, where =
the browser today gets the
> TURN server address from the web =
application, or gets it configured by a LAN
> admin via an =
“admin policy template”.
>
> However, there is a =
need (motivations below) for the TURN server address to
> be =
provided via DHCP (and maybe RA - Router Advertisement - for IPv6, =
and
> the OTT channel in mobiles have their own method I’ve =
been told). Simply
> put, just as you often get your IP-address, =
DNS address, etc. automatically
> from the network access, you =
should also get the TURN server address.
>
> I suggest the =
following is added to the end of use case (which today is
> about =
multiple TURN servers)
> 3.2.4.  Simple Video Communication =
Service, global service provider
> 3.2.4.1. =
 Description
> ...
> "A network service provider =
must be able to automatically supply a TURN
> server addresses to =
the browser when accessing a network. The address may
> come via =
DHCP or a similar mechanism (maybe RA - Router Advertisement - =
for
> IPv6, an addition to the IPCP protocol like RFC1877 for =
PPPoE, or whatever
> method the mobile OTT channels use). The =
mechanism should be similar to
> automatically getting the =
IP-address, DNS address, etc.. and need extensions
> to current =
recommendations/standards.
>
> There are several reasons for =
a network service provider to supply a TURN
> server as part of =
his offered access:
> - to keep media paths short, specifically =
not sending media outside its own
> network to some distant =
application provided TURN server
> - to support mobility, i.e. you =
may want to move from a LAN with a
> configured TURN server to =
accessing via WiFi or 3G/4G OTT channels
I have not =
read the draft but would like to make it clear that no 2g/3g/4g provider =
uses dhcp over the mobile network so this dhcp solution would not apply. =

CB
> - to offer a media path with =
better quality (than best effort data traffic).
> Getting =
“WebRTC-ready” access and we look forward to telepresence =
for
> everyone.
>
> An enterprise network that want to =
keep a restrictive firewall not allowing
> UDP traffic, could =
provide a real-time path using a TURN server paralleling
> the =
firewall, instead of tunneling RTP through always open http or =
https
> ports resulting in RTP media over TCP – with severe =
quality problems from
> TCP retransmissions of dropped packets. =
The TURN server address is most
> easily provided in the same way =
as the IP address and DNS address. (That
> would also put the =
right party in control – The network provider decides
> what =
is allowed on his network.)
>
> This browser should select =
which available TURN server address to use in the
> following =
priority order, where ICE could be used to try several:
>
> =
1) TURN server address configured in the browser by the user (special =
cases,
> normally not used)
> 2) TURN server address =
configured by the network administrator via an “admin
> =
policy template”
> 3) TURN server address supplied by DHCP =
or similar automatic network method
> 4) TURN server address being =
supplied by the web application"
>
> Two new =
requirements can be extracted:
> "   =
----------------------------------------------------------------
> =
   F40     The browser must support retrieving TURN =
server addresses via
> DHCP or a similar mechanism (maybe RA - =
Router Advertisement - for IPv6, an
> addition to the IPCP =
protocol like RFC1877 for PPPoE, or whatever method the
> mobile =
OTT channels use). The mechanism should be similar to =
automatically
> getting the IP-address, DNS address, etc..
> =
  =
 ---------------------------------------------------------------->    F42     This browser should select which =
available TURN server address to
> use in the following priority =
order, where ICE could be used to try several:
>
> 1) TURN =
server address configured in the browser by the user (special =
cases,
> normally not used)
> 2) TURN server address =
configured by the network administrator via an “admin
> =
policy template”
> 3) TURN server address supplied by DHCP =
or similar automatic network method
> 4) TURN server address being =
supplied by the web application
> =
----------------------------------------------------------------">
> I suppose this also will add to:
> 5.  IANA =
Considerations
>    TBD
>
> =
/Karl
>
>
> -----Ursprungligt meddelande-----
> =
Fr=E5n: rtcweb-bounces@ietf.org =
[mailto:rtcweb-bounces@ietf.org] =
F=F6r Cullen
> Jennings (fluffy)
> Skickat: den 4 september =
2013 18:24
> Till: rtcweb@ietf.org
> =C4mne: =
[rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
> =
We would like to start a working group last call of
> =
draft-ietf-rtcweb-use-cases-and-requirements-11.
>
> Please =
send comments by the end of the day on September 21.
>
> =
Thank you,
>
> The chairs =
….
>
>
>
>
> =
_______________________________________________
> rtcweb mailing =
list
> rtcweb@ietf.org
> https://www.ietf.or=
g/mailman/listinfo/rtcweb
>
> =
_______________________________________________
> rtcweb mailing =
list
> rtcweb@ietf.org
> https://www.ietf.or=
g/mailman/listinfo/rtcweb

------=_NextPart_000_0981_01CEB8A7.F0A53090--


From hangzhou.chenxin@huawei.com  Mon Sep 23 19:15:15 2013
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 782FB11E80F8 for ; Mon, 23 Sep 2013 19:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.28
X-Spam-Level: 
X-Spam-Status: No, score=-7.28 tagged_above=-999 required=5 tests=[AWL=0.720,  BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4dRNdEN8RfH for ; Mon, 23 Sep 2013 19:15:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F84921F9FCE for ; Mon, 23 Sep 2013 19:15:08 -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 AVU16841; Tue, 24 Sep 2013 02:15:07 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 03:13:49 +0100
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 03:14:31 +0100
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 10:14:27 +0800
From: "Chenxin (Xin)" 
To: Karl Stahl , "rtcweb@ietf.org" ,  "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" 
Thread-Topic: [rtcweb]  WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEw
Date: Tue, 24 Sep 2013 02:14:26 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com>
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>
In-Reply-To: <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.41.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 24 Sep 2013 02:15:16 -0000

Hi Karl,=20
>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O=
f
>Karl Stahl
>Sent: Saturday, September 21, 2013 8:16 AM
>To: rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>Subject: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>
>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here ar=
e
>a few "telephony related" WebRTC things I think should be clarified in the
>use cases.
>
>
>3.2.1.  Simple Video Communication Service
>3.2.1.1.  Description
>...
>The invited user might accept or reject the session.
>[Suggest adding] The invited user might accept only audio, rejecting video
>(even if a camera is enabled). A user may also select to initiate an audio
>session, without video.
>
>And in API requirements:
>   ----------------------------------------------------------------
>   A1      The Web API must provide means for the application to ask the
>browser for permission to use cameras and microphones, individually as inp=
ut
>devices. (One must be able to answer with voice only - declining video.)
>   ----------------------------------------------------------------

>Same under
>6.2.  Browser Considerations
>...
>The browser is expected to provide mechanisms for users to revise and even
>completely revoke consent to use device resources such as camera and
>microphone. [Suggest adding] Specifically, a user must be given the
>opportunity to only accept audio in a video call invitation.
>
[Xin] it is a common use case to accept only audio call and reject the vide=
o and quite useful. But I am doubt that this function should be mixed with =
video or audio device access permission . Do I misunderstand your proposal?=
  I think we could just disable the video stream when signaling. So we coul=
d make video call with one and reject it with other in the same web-service=
. I think the audio and video device access permission is not for each call=
(peer connection).=20

Thanks,
   Xin

From bernard_aboba@hotmail.com  Mon Sep 23 22:00:32 2013
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 3AF5911E80F5 for ; Mon, 23 Sep 2013 22:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Level: 
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSFyJ9vwcp+r for ; Mon, 23 Sep 2013 22:00:26 -0700 (PDT)
Received: from blu0-omc1-s26.blu0.hotmail.com (blu0-omc1-s26.blu0.hotmail.com [65.55.116.37]) by ietfa.amsl.com (Postfix) with ESMTP id 354D011E8102 for ; Mon, 23 Sep 2013 22:00:26 -0700 (PDT)
Received: from BLU169-W76 ([65.55.116.8]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 23 Sep 2013 22:00:20 -0700
X-TMN: [U8RcWoi9a3jyPEFTtaFOuxe/oGJd6U6X]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_55af0b3f-ccb6-4b86-950e-4c3df1150277_"
From: Bernard Aboba 
To: Dan Wing 
Date: Mon, 23 Sep 2013 22:00:18 -0700
Importance: Normal
In-Reply-To: <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com>
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>, <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>, <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>, <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Sep 2013 05:00:20.0042 (UTC) FILETIME=[F7D5B2A0:01CEB8E2]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] additional ICE info
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, 24 Sep 2013 05:00:32 -0000

--_55af0b3f-ccb6-4b86-950e-4c3df1150277_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dan Wing said:=20
"Another solution is MALICE which adds information to the ICE connectivity =
checks (bandwidth=2C drop preference=2C etc.) which can be DPI'd by network=
 devices."
[BA]  I am fairly keen on adding some of this information to ICE=2C though =
not to assist DPI.   Rather=2C my concern is that with SDP being optional i=
n WebRTC=2C some of the info that would otherwise be exchanged in the signa=
ling channel may not be present=2C and if present=2C cannot necessarily be =
trusted=2C so that putting this into the ICE exchange has potential securit=
y value.  Also=2C in a situation where TURN servers are rented in the cloud=
=2C it can be useful to signal the maximum bandwidth that could be used for=
 a given allocation.  To my mind=2C the issue to be fixed in the TURN REST =
API wasn't necessarily the ability to steal credentials=2C but the ability =
to misuse those credentials in a way that could impose significant cost on =
the victim.  The act of mis-using a TURN credential does not by itself impo=
se that cost -- but pumping huge amounts of traffic through it would.  		 	=
   		  =

--_55af0b3f-ccb6-4b86-950e-4c3df1150277_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Dan Wing said: =3B
<=
br>
"Another solution i=
s MALICE which adds information to the ICE connectivity checks (bandwidth=
=2C drop preference=2C etc.) which can be DPI'd by network devices."=


[BA]  =3BI am fairly keen on adding some of=
 this information to ICE=2C though not to assist DPI.  =3B Rather=2C my=
 concern is that with SDP being optional in WebRTC=2C some of the info that=
 would otherwise be exchanged in the signaling channel may not be present=
=2C and if present=2C cannot necessarily be trusted=2C so that putting this=
 into the ICE exchange has potential security value.  =3BAlso=2C in a s=
ituation where TURN servers are rented in the cloud=2C it can be useful to =
signal the maximum bandwidth that could be used for a given allocation. &nb=
sp=3BTo my mind=2C the issue to be fixed in the TURN REST API wasn't necess=
arily the ability to steal credentials=2C but the ability to misuse those c=
redentials in a way that could impose significant cost on the victim.  =
=3BThe act of mis-using a TURN credential does not by itself impose that co=
st -- but pumping huge amounts of traffic through it would. =3B<=
/div> 		 	   		  

=

--_55af0b3f-ccb6-4b86-950e-4c3df1150277_--

From karl.stahl@intertex.se  Tue Sep 24 00:04:03 2013
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 D722511E8105 for ; Tue, 24 Sep 2013 00:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level: 
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.924,  BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdlfsXRHpLg5 for ; Tue, 24 Sep 2013 00:03:58 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83A1011E8107 for ; Tue, 24 Sep 2013 00:03:56 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309240903546378; Tue, 24 Sep 2013 09:03:54 +0200
From: "Karl Stahl" 
To: "'Chenxin \(Xin\)'" , , 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com>
Date: Tue, 24 Sep 2013 09:03:54 +0200
Message-ID: <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7A=
Content-Language: sv
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 24 Sep 2013 07:04:04 -0000

-----Ursprungligt meddelande-----
Fr=E5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20
Skickat: den 24 september 2013 04:14
Till: Karl Stahl; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: RE: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,=20
>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
>Behalf Of Karl Stahl
>Sent: Saturday, September 21, 2013 8:16 AM
>To: rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>Subject: [rtcweb] WGLC of=20
>draft-ietf-rtcweb-use-cases-and-requirements-11
>
>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here =

>are a few "telephony related" WebRTC things I think should be clarified =

>in the use cases.
>
>
>3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...
>The invited user might accept or reject the session.
>[Suggest adding] The invited user might accept only audio, rejecting=20
>video (even if a camera is enabled). A user may also select to initiate =

>an audio session, without video.
>
>And in API requirements:
>   ----------------------------------------------------------------
>   A1      The Web API must provide means for the application to ask =
the
>browser for permission to use cameras and microphones, individually as=20
>input devices. (One must be able to answer with voice only - declining
video.)
>   ----------------------------------------------------------------

>Same under
>6.2.  Browser Considerations
>...
>The browser is expected to provide mechanisms for users to revise and=20
>even completely revoke consent to use device resources such as camera=20
>and microphone. [Suggest adding] Specifically, a user must be given the =

>opportunity to only accept audio in a video call invitation.
>
[Xin] it is a common use case to accept only audio call and reject the =
video
and quite useful. But I am doubt that this function should be mixed with
video or audio device access permission . Do I misunderstand your =
proposal?
I think we could just disable the video stream when signaling. So we =
could
make video call with one and reject it with other in the same =
web-service. I
think the audio and video device access permission is not for each =
call(peer
connection).=20

Thanks,
   Xin
[Karl] Try using a WebRTC application with Chrome and you will see: The
Permission/Allowance to use Camera and Microphone comes up at a bar at =
the
top of the browser window and is the actual answering of a call.


From hangzhou.chenxin@huawei.com  Tue Sep 24 04:56:16 2013
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 1EE3F11E811A for ; Tue, 24 Sep 2013 04:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.823
X-Spam-Level: 
X-Spam-Status: No, score=-6.823 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmdqP8GM8j1O for ; Tue, 24 Sep 2013 04:56:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0B4D11E8110 for ; Tue, 24 Sep 2013 04:56:09 -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 AVU69040; Tue, 24 Sep 2013 11:56:08 +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.3.146.0; Tue, 24 Sep 2013 12:54:57 +0100
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 12:55:41 +0100
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 19:55:35 +0800
From: "Chenxin (Xin)" 
To: Karl Stahl , "rtcweb@ietf.org" ,  "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" 
Thread-Topic: [rtcweb]  WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7CAAEbaMA==
Date: Tue, 24 Sep 2013 11:55:34 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE0397680805AC@SZXEMA504-MBX.china.huawei.com>
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com> <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se>
In-Reply-To: <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.41.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 24 Sep 2013 11:56:16 -0000

Hi Karl,
>>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here
>>are a few "telephony related" WebRTC things I think should be clarified
>>in the use cases.
>>
>>
>>3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...
>>The invited user might accept or reject the session.
>>[Suggest adding] The invited user might accept only audio, rejecting
>>video (even if a camera is enabled). A user may also select to initiate
>>an audio session, without video.
>>
>>And in API requirements:
>>   ----------------------------------------------------------------
>>   A1      The Web API must provide means for the application to ask the
>>browser for permission to use cameras and microphones, individually as
>>input devices. (One must be able to answer with voice only - declining
>video.)
>>   ----------------------------------------------------------------
>
>>Same under
>>6.2.  Browser Considerations
>>...
>>The browser is expected to provide mechanisms for users to revise and
>>even completely revoke consent to use device resources such as camera
>>and microphone. [Suggest adding] Specifically, a user must be given the
>>opportunity to only accept audio in a video call invitation.
>>
>[Xin] it is a common use case to accept only audio call and reject the vid=
eo
>and quite useful. But I am doubt that this function should be mixed with
>video or audio device access permission . Do I misunderstand your proposal=
?
>I think we could just disable the video stream when signaling. So we could
>make video call with one and reject it with other in the same web-service.=
 I
>think the audio and video device access permission is not for each call(pe=
er
>connection).
>
>Thanks,
>   Xin
>[Karl] Try using a WebRTC application with Chrome and you will see: The
>Permission/Allowance to use Camera and Microphone comes up at a bar at the
>top of the browser window and is the actual answering of a call.

[Xin] yes, it come up because invoking the getUserMedia API. When we write =
the webrtc app, we could call getUserMedia API just once and use the same m=
ediaStream later. The webrtc app could decide to send the video stream to t=
he other side or not by configure the signaling(SDP or other).  It is trivi=
al to click the Permission bar at the top every time when I get a call, eve=
n terrible when join a p2p conference.=20
That is the reason I think the use case you mentioned should not mix with p=
ermission, which should be a signaling configuration problem. Now in Chrome=
,we could control it by using creatOffer or createAnswer and setting the Of=
ferToReceiveVideo constraint.=20

Thanks,
   Xin

From creslin@digium.com  Tue Sep 24 08:59:04 2013
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 7003811E8175 for ; Tue, 24 Sep 2013 08:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level: 
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbCxEzH0--ss for ; Tue, 24 Sep 2013 08:59:00 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1158311E816D for ; Tue, 24 Sep 2013 08:58:47 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ep20so3827171lab.16 for ; Tue, 24 Sep 2013 08:58:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WMi9aEPBV3bjTX8RbxjK/doRo7Bz6kvkmGVHIoJfask=; b=TWtwWTS0VOCouX30eX6so4KS1dgnBe1k4tldoDhaLLteCfa+qWsv/L9Z3watg3ZFHX ATWyadsx8ul99aHGgafs2g8DVz0erjGm1XXm593t7ERsOJoaIESqmiY4f+c15r6Wx4G9 s1OSvOSFnL/n44YVkcnEPxABSdtx3YgsvzMJMBMN76naZlXfSS+fyEk+AAncMloTKhbC uCClZ/ESI+oWMPhb3ywyPRlOuicVogSyulx4rxzQGQ4qGoX+ZVLQo6ZR41GY/5SlEAl3 VAug5nDPXehccjh6eAy8BRGe5p42qrWF1AZUNBzrq4xlO0EjrXVZkLVt/jj0gnD7cQum ArLg==
X-Gm-Message-State: ALoCoQkBP0BLEctf2f9ZjG/MF5bO1Kq6ixIah/4rvZ8iYzfqgDxTkFuCH6a2XDumyiEnAXQ9wptG
MIME-Version: 1.0
X-Received: by 10.152.30.74 with SMTP id q10mr7534987lah.27.1380038326001; Tue, 24 Sep 2013 08:58:46 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Tue, 24 Sep 2013 08:58:45 -0700 (PDT)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
References: <523BE4DB.5030800@ericsson.com> <523BF860.1090105@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
Date: Tue, 24 Sep 2013 10:58:45 -0500
Message-ID: 
From: Matt Fredrickson 
To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
Content-Type: multipart/alternative; boundary=089e0158c41032b41704e7233600
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
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, 24 Sep 2013 15:59:05 -0000
X-List-Received-Date: Tue, 24 Sep 2013 15:59:05 -0000

--089e0158c41032b41704e7233600
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I tend also to agree with this.  Maybe I'm completely off, but it would
seem that pause and resume might be done using some semi-inband media
related path, perhaps like RTCP or something like that.  I'm not sure where
to fit resolution in though...

Matthew Fredrickson
Digium, Inc.


On Fri, Sep 20, 2013 at 5:57 AM, Stefan H=E5kansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2013-09-20 09:25, Harald Alvestrand wrote:
> > On 09/20/2013 08:02 AM, Magnus Westerlund wrote:
> >> WG,
> >>
> >> In the JSEP call I commented regarding a=3Dimageattr open issue that w=
e
> >> had an original agreement from over a year ago (Vancouver) to go with
> >> Harald's proposal in then
> >> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt
> >>
> >> This is documented in the minutes:
> >> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb
> >>
> >>
> >> However, I did forget to note that there has been discussion on this
> >> issue after that between Harald Alvestrand and Stefan H=E5kansson
> >> primarily on the W3C list
> >>
> >> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html
> >>
> >> Where they are seriously discussing only using WebRTC API for this.
> >>
> >> It is in the context of
> >>
> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution/
> >>
> >> Thus I would like to point out that there appear to be some indication
> >> of desire move away from the consensus last year.
> >
> > My thinking is that there are 3 points on the spectrum of solutions:
> >
> > - Constraints at source only (the approach most thoroughly described in
> > draft-alvestrand-constraints-resolution).
> >
> > - Constraints at destination can be sigalled in SDP, and acted on at
> > source (described in draft-alvestrand-rtcweb-resolution). This spec
> > could not be pursued as long as the "Plan X" discussions were still
> > unsettled, but now it should really be "a piece of cake".
>
> My personal view is still that SDP is the wrong level for carrying this
> kind of signaling (resolution, and perhaps further down the road
> pause/resume related signaling). Each update requires an O/A, and locks
> out other changes to the session. And since the SDPs must be handled by
> the application (that is responsible for sending them over and applying
> them) I wonder if there is any advantage compared to just having an API
> on the sending side. If the receiving application wants another
> resolution sent, it could just tell the sending application so, rather
> than going through a createOffer/setLocal/ send-offer
> /receive-answer/setRemote cycle.
>
> >
> > - Defining a new way of signalling. This was the approach rejected in
> > Vancouver.
> >
> > Formalistically, if the IETF decides to offer a well defined mechanism
> > for negotiating resolution through SDP, the W3C will certainly take up
> > the discussion on whether or not we should connect the API to that
> > functionality.
> >
> > Happy to discuss more.
> >
> > _______________________________________________
> > 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
>

--089e0158c41032b41704e7233600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I tend also to agree with this. =A0Maybe I'm completel=
y off, but it would seem that pause and resume might be done using some sem=
i-inband media related path, perhaps like RTCP or something like that. =A0I=
'm not sure where to fit resolution in though...


Matthew Fredrickson
Digium, Inc.


On Fri, Sep 20, 201=
3 at 5:57 AM, Stefan H=E5kansson LK <stefan.lk.hakansson@er=
icsson.com> wrote:


On 2=
013-09-20 09:25, Harald Alvestrand wrote:

> On 09/20/2013 08:02 AM, Magnus Westerlund wrote:

>> WG,

>>

>> In the JSEP call I commented regarding a=3Dimageattr open issue th=
at we

>> had an original agreement from over a year ago (Vancouver) to go w=
ith

>> Harald's proposal in then

>> http://tools.ietf.org/id/draft-alvestrand-rt=
cweb-resolution-00.txt

>>

>> This is documented in the minutes:

>> http://www.ietf.org/proceedings/84/minutes/minutes=
-84-rtcweb

>>

>>

>> However, I did forget to note that there has been discussion on th=
is

>> issue after that between Harald Alvestrand and Stefan H=E5kansson<=
br>
>> primarily on the W3C list

>>

>> http://lists.w3.org/Archives/Public/public-=
webrtc/2013Aug/0051.html

>>

>> Where they are seriously discussing only using WebRTC API for this=
.

>>

>> It is in the context of

>> https://datatracker.ietf.org/doc/draf=
t-alvestrand-constraints-resolution/

>>

>> Thus I would like to point out that there appear to be some indica=
tion

>> of desire move away from the consensus last year.

>

> My thinking is that there are 3 points on the spectrum of solutions:
>

> - Constraints at source only (the approach most thoroughly described i=
n

> draft-alvestrand-constraints-resolution).

>

> - Constraints at destination can be sigalled in SDP, and acted on at
> source (described in draft-alvestrand-rtcweb-resolution). This spec
> could not be pursued as long as the "Plan X" discussions wer=
e still

> unsettled, but now it should really be "a piece of cake".



My personal view is still that SDP is the wrong level for carry=
ing this

kind of signaling (resolution, and perhaps further down the road

pause/resume related signaling). Each update requires an O/A, and locks

out other changes to the session. And since the SDPs must be handled by

the application (that is responsible for sending them over and applying

them) I wonder if there is any advantage compared to just having an API

on the sending side. If the receiving application wants another

resolution sent, it could just tell the sending application so, rather

than going through a createOffer/setLocal/ send-offer

/receive-answer/setRemote cycle.




>

> - Defining a new way of signalling. This was the approach rejected in<=
br>
> Vancouver.

>

> Formalistically, if the IETF decides to offer a well defined mechanism=


> for negotiating resolution through SDP, the W3C will certainly take up=


> the discussion on whether or not we should connect the API to that

> functionality.

>

> Happy to discuss more.

>

> _______________________________________________

> 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





--089e0158c41032b41704e7233600--

From karl.stahl@intertex.se  Tue Sep 24 13:08:57 2013
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 C4A5521F9C99 for ; Tue, 24 Sep 2013 13:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.158
X-Spam-Level: 
X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_93=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhJWIHc4asrx for ; Tue, 24 Sep 2013 13:08:48 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 633A721F9BFA for ; Tue, 24 Sep 2013 13:08:41 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309242208383356; Tue, 24 Sep 2013 22:08:38 +0200
From: "Karl Stahl" 
To: "'Chenxin \(Xin\)'" , , 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com> <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680805AC@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680805AC@SZXEMA504-MBX.china.huawei.com>
Date: Tue, 24 Sep 2013 22:08:38 +0200
Message-ID: <0b5b01ceb961$db8cff20$92a6fd60$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7CAAEbaMIAAkEbg
Content-Language: sv
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 24 Sep 2013 20:08:57 -0000

-----Ursprungligt meddelande-----
Fr=E5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20
Skickat: den 24 september 2013 13:56
Till: Karl Stahl; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: RE: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,
>>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11,=20
>>here are a few "telephony related" WebRTC things I think should be=20
>>clarified in the use cases.
>>
>>
>>3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...
>>The invited user might accept or reject the session.
>>[Suggest adding] The invited user might accept only audio, rejecting=20
>>video (even if a camera is enabled). A user may also select to=20
>>initiate an audio session, without video.
>>
>>And in API requirements:
>>   ----------------------------------------------------------------
>>   A1      The Web API must provide means for the application to ask =
the
>>browser for permission to use cameras and microphones, individually as =

>>input devices. (One must be able to answer with voice only - declining
>video.)
>>   ----------------------------------------------------------------
>
>>Same under
>>6.2.  Browser Considerations
>>...
>>The browser is expected to provide mechanisms for users to revise and=20
>>even completely revoke consent to use device resources such as camera=20
>>and microphone. [Suggest adding] Specifically, a user must be given=20
>>the opportunity to only accept audio in a video call invitation.
>>
>[Xin] it is a common use case to accept only audio call and reject the=20
>video and quite useful. But I am doubt that this function should be=20
>mixed with video or audio device access permission . Do I misunderstand
your proposal?
>I think we could just disable the video stream when signaling. So we=20
>could make video call with one and reject it with other in the same=20
>web-service. I think the audio and video device access permission is=20
>not for each call(peer connection).
>
>Thanks,
>   Xin
>[Karl] Try using a WebRTC application with Chrome and you will see: The =

>Permission/Allowance to use Camera and Microphone comes up at a bar at=20
>the top of the browser window and is the actual answering of a call.

[Xin] yes, it come up because invoking the getUserMedia API. When we =
write
the webrtc app, we could call getUserMedia API just once and use the =
same
mediaStream later. The webrtc app could decide to send the video stream =
to
the other side or not by configure the signaling(SDP or other).  It is
trivial to click the Permission bar at the top every time when I get a =
call,
even terrible when join a p2p conference.=20
That is the reason I think the use case you mentioned should not mix =
with
permission, which should be a signaling configuration problem. Now in
Chrome,we could control it by using creatOffer or createAnswer and =
setting
the OfferToReceiveVideo constraint.=20

Thanks,
   Xin
[Karl] If you permit the Browser to use the camera, then later "answer =
with
only audio in the application" (as I understand you suggest) - Can we =
trust
that the application isn't sending our video anyway - not even informing =
us?

I don't think we can trust any video WebRTC application, but will learn =
to
only trust well known browsers not to view us, when we don't want to be
seen.

Isn't this a necessary security thing?

/Karl=20




From dwing@cisco.com  Tue Sep 24 17:09:14 2013
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 C669A21F9AE7 for ; Tue, 24 Sep 2013 17:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.684
X-Spam-Level: 
X-Spam-Status: No, score=-110.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shghg6K2bTl4 for ; Tue, 24 Sep 2013 17:09:09 -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 BB0D421F8E3D for ; Tue, 24 Sep 2013 17:09:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1843; q=dns/txt; s=iport; t=1380067749; x=1381277349; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rril74V9K1Eb+49dRE3ic1Aqlq3Z3V0cf/5rgOvLETg=; b=LKfuiDpwA2CkD5nLVgAjtZF3/t+BAGgIkl4KEzTlEo4llSUa5pifdzMN 0/YE5X+ydLMuJmgAcwyKyTG1BE+GQf2/e8CHAW8+sN/oYkFBvkB2IFqYx L6UHfvEQ0UkYeUbPT9ZddpZVBOXme/R+YbkIemO8FoZ8IaDFaFDeFCkeQ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFALwoQlKrRDoJ/2dsb2JhbABbgwc4rlmSVIEeFnSCJQEBAQMBeQUJAgtGFkEGExuHWAMJBQ28RQSMYoI4MweDHYEAA4k4jFyBaIEviReBfoUzg0Qc
X-IronPort-AV: E=Sophos;i="4.90,974,1371081600"; d="scan'208";a="89795077"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 25 Sep 2013 00:09:09 +0000
Received: from sjc-vpn3-476.cisco.com (sjc-vpn3-476.cisco.com [10.21.65.220]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8P098Ad027672; Wed, 25 Sep 2013 00:09:08 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing 
In-Reply-To: 
Date: Tue, 24 Sep 2013 17:10:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>, <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>, <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>, <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com> 
To: Bernard Aboba 
X-Mailer: Apple Mail (2.1508)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] additional ICE info
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, 25 Sep 2013 00:09:14 -0000

On Sep 23, 2013, at 10:00 PM, Bernard Aboba  =
wrote:

> Dan Wing said:=20
>=20
> "Another solution is MALICE which adds information to the ICE =
connectivity checks (bandwidth, drop preference, etc.) which can be =
DPI'd by network devices."
>=20
> [BA]  I am fairly keen on adding some of this information to ICE, =
though not to assist DPI.   Rather, my concern is that with SDP being =
optional in WebRTC, some of the info that would otherwise be exchanged =
in the signaling channel may not be present, and if present, cannot =
necessarily be trusted, so that putting this into the ICE exchange has =
potential security value.  Also, in a situation where TURN servers are =
rented in the cloud, it can be useful to signal the maximum bandwidth =
that could be used for a given allocation. =20

Yes, bandwidth is part of Microsoft's extensions to TURN as I'm sure you =
are aware (but others are probably not aware), =
http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx

The advantage of allowing routers along the path to see the bandwidth is =
they can influence their routing decisions to put the traffic on a =
better path (e.g., 3G versus microwave link versus satellite), =
prioritize the traffic, and do other things.  If the network always has =
sufficient bandwidth and thus no need to differentiate traffic, I agree =
there is no value and no purpose to tell the network anything.

> To my mind, the issue to be fixed in the TURN REST API wasn't =
necessarily the ability to steal credentials, but the ability to misuse =
those credentials in a way that could impose significant cost on the =
victim.  The act of mis-using a TURN credential does not by itself =
impose that cost -- but pumping huge amounts of traffic through it =
would.=20

-d


From fluffy@cisco.com  Tue Sep 24 21:57:06 2013
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 872CD21F9CF1 for ; Tue, 24 Sep 2013 21:57:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZM0h5lO+A8w for ; Tue, 24 Sep 2013 21:57:01 -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 07C4121F9D95 for ; Tue, 24 Sep 2013 21:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6056; q=dns/txt; s=iport; t=1380085016; x=1381294616; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p303SyEH3Cvta8fsOMtqwXNQ3kQ/YdbDv8OIwQnrJHQ=; b=QBN7HBFIpJw9sgwBK8yROJSo9v5wkDCOnX9sFYJ6pfvWL/6YGDmKi5uY 2OWLquwA6E+Bb2nsZF2iqBc85NT9buusN80LoD2u0kLlJi5WfFytHmuNG wXqtECphRvtVBSNk0waIuRPr//J+DoUSpx6Jyqk66mWWFyUA7bKw9IAZE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAOlsQlKtJXHA/2dsb2JhbABbgwc4Ur9/SoEbFnSCJQEBAQMBAQEBawsQAgEIGAodByEGCxQRAgQOBQgTh1gDCQYMskANiWYEjGaBGIEgAjEHgx2BAAOUH4F0ji2FM4FmgT6BcTk
X-IronPort-AV: E=Sophos;i="4.90,976,1371081600"; d="scan'208";a="264114948"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 25 Sep 2013 04:56:31 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8P4uU0s012791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 04:56:30 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 23:56:30 -0500
From: "Cullen Jennings (fluffy)" 
To: "cb.list6" 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMA
Date: Wed, 25 Sep 2013 04:56:30 +0000
Message-ID: 
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.86.191]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 25 Sep 2013 04:57:06 -0000

On desktop OS, it is very hard for an application like a browser to learn a=
ny information that was passed via DHCP to the host. This has long been a p=
roblem for things like geopriv.=20

I will note that browsers have many ways to learn about HTTP proxies from t=
he network and it seems to me that using some of theses same technique migh=
t also be a good way to learn about TURN servers.=20


On Sep 23, 2013, at 9:58 AM, cb.list6  wrote:

>=20
> On Sep 20, 2013 8:43 AM, "Karl Stahl"  wrote:
> >
> > For NAT/Firewall traversal WebRTC uses ICE, where the browser today get=
s the
> > TURN server address from the web application, or gets it configured by =
a LAN
> > admin via an =93admin policy template=94.
> >
> > However, there is a need (motivations below) for the TURN server addres=
s to
> > be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, a=
nd
> > the OTT channel in mobiles have their own method I=92ve been told). Sim=
ply
> > put, just as you often get your IP-address, DNS address, etc. automatic=
ally
> > from the network access, you should also get the TURN server address.
> >
> > I suggest the following is added to the end of use case (which today is
> > about multiple TURN servers)
> > 3.2.4.  Simple Video Communication Service, global service provider
> > 3.2.4.1.  Description
> > ...
> > "A network service provider must be able to automatically supply a TURN
> > server addresses to the browser when accessing a network. The address m=
ay
> > come via DHCP or a similar mechanism (maybe RA - Router Advertisement -=
 for
> > IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whate=
ver
> > method the mobile OTT channels use). The mechanism should be similar to
> > automatically getting the IP-address, DNS address, etc.. and need exten=
sions
> > to current recommendations/standards.
> >
> > There are several reasons for a network service provider to supply a TU=
RN
> > server as part of his offered access:
> > - to keep media paths short, specifically not sending media outside its=
 own
> > network to some distant application provided TURN server
> > - to support mobility, i.e. you may want to move from a LAN with a
> > configured TURN server to accessing via WiFi or 3G/4G OTT channels
>=20
> I have not read the draft but would like to make it clear that no 2g/3g/4=
g provider uses dhcp over the mobile network so this dhcp solution would no=
t apply.
>=20
> CB
>=20
> > - to offer a media path with better quality (than best effort data traf=
fic).
> > Getting =93WebRTC-ready=94 access and we look forward to telepresence f=
or
> > everyone.
> >
> > An enterprise network that want to keep a restrictive firewall not allo=
wing
> > UDP traffic, could provide a real-time path using a TURN server paralle=
ling
> > the firewall, instead of tunneling RTP through always open http or http=
s
> > ports resulting in RTP media over TCP =96 with severe quality problems =
from
> > TCP retransmissions of dropped packets. The TURN server address is most
> > easily provided in the same way as the IP address and DNS address. (Tha=
t
> > would also put the right party in control =96 The network provider deci=
des
> > what is allowed on his network.)
> >
> > This browser should select which available TURN server address to use i=
n the
> > following priority order, where ICE could be used to try several:
> >
> > 1) TURN server address configured in the browser by the user (special c=
ases,
> > normally not used)
> > 2) TURN server address configured by the network administrator via an =
=93admin
> > policy template=94
> > 3) TURN server address supplied by DHCP or similar automatic network me=
thod
> > 4) TURN server address being supplied by the web application"
> >
> > Two new requirements can be extracted:
> > "   ----------------------------------------------------------------
> >    F40     The browser must support retrieving TURN server addresses vi=
a
> > DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6=
, an
> > addition to the IPCP protocol like RFC1877 for PPPoE, or whatever metho=
d the
> > mobile OTT channels use). The mechanism should be similar to automatica=
lly
> > getting the IP-address, DNS address, etc..
> >    ----------------------------------------------------------------
> >    F42     This browser should select which available TURN server addre=
ss to
> > use in the following priority order, where ICE could be used to try sev=
eral:
> >
> > 1) TURN server address configured in the browser by the user (special c=
ases,
> > normally not used)
> > 2) TURN server address configured by the network administrator via an =
=93admin
> > policy template=94
> > 3) TURN server address supplied by DHCP or similar automatic network me=
thod
> > 4) TURN server address being supplied by the web application
> > ----------------------------------------------------------------"
> >
> > I suppose this also will add to:
> > 5.  IANA Considerations
> >    TBD
> >
> > /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Cullen
> > Jennings (fluffy)
> > Skickat: den 4 september 2013 18:24
> > Till: rtcweb@ietf.org
> > =C4mne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-1=
1
> >
> >
> > We would like to start a working group last call of
> > draft-ietf-rtcweb-use-cases-and-requirements-11.
> >
> > Please send comments by the end of the day on September 21.
> >
> > Thank you,
> >
> > The chairs =85.
> >
> >
> >
> >
> > _______________________________________________
> > 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 harald@alvestrand.no  Tue Sep 24 23:15:39 2013
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 6D30B11E80AD for ; Tue, 24 Sep 2013 23:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level: 
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5n98E9ka1yb for ; Tue, 24 Sep 2013 23:15:34 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0446521F9FE7 for ; Tue, 24 Sep 2013 23:15:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DE6739E172; Wed, 25 Sep 2013 08:15:17 +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 9cJqntc+QAYB; Wed, 25 Sep 2013 08:15:16 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8935A39E0BF; Wed, 25 Sep 2013 08:15:16 +0200 (CEST)
Message-ID: <52427F74.9030805@alvestrand.no>
Date: Wed, 25 Sep 2013 08:15:16 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Dan Wing , Bernard Aboba 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>, <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>, <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>, <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com>	 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] additional ICE info
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, 25 Sep 2013 06:15:39 -0000

Thanks for the pointer!

The existence of that (public) document explains some strange features
of some earlier Microsoft proposals that I was never able to get an
explanation for.

This approach (which seems to have many of the properties of RSVP) seems
to offer a solution to some problems that people have been solving by
snooping SIP (which is impossible if SIP isn't used, and very hard when
all the SIP channels are encrypted). Is there a chance that we could get
public-stable specification of the required pieces, so that other
companies can dare to depend on it?

(public-stable, a term I just invented, includes independent RFC, info
RFC and standards-track)

On 09/25/2013 02:10 AM, Dan Wing wrote:
> On Sep 23, 2013, at 10:00 PM, Bernard Aboba  wrote:
>
>> Dan Wing said: 
>>
>> "Another solution is MALICE which adds information to the ICE connectivity checks (bandwidth, drop preference, etc.) which can be DPI'd by network devices."
>>
>> [BA]  I am fairly keen on adding some of this information to ICE, though not to assist DPI.   Rather, my concern is that with SDP being optional in WebRTC, some of the info that would otherwise be exchanged in the signaling channel may not be present, and if present, cannot necessarily be trusted, so that putting this into the ICE exchange has potential security value.  Also, in a situation where TURN servers are rented in the cloud, it can be useful to signal the maximum bandwidth that could be used for a given allocation.  
> Yes, bandwidth is part of Microsoft's extensions to TURN as I'm sure you are aware (but others are probably not aware), http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx
>
> The advantage of allowing routers along the path to see the bandwidth is they can influence their routing decisions to put the traffic on a better path (e.g., 3G versus microwave link versus satellite), prioritize the traffic, and do other things.  If the network always has sufficient bandwidth and thus no need to differentiate traffic, I agree there is no value and no purpose to tell the network anything.
>
>> To my mind, the issue to be fixed in the TURN REST API wasn't necessarily the ability to steal credentials, but the ability to misuse those credentials in a way that could impose significant cost on the victim.  The act of mis-using a TURN credential does not by itself impose that cost -- but pumping huge amounts of traffic through it would. 
> -d
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.


From dwing@cisco.com  Wed Sep 25 08:35:49 2013
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 3306611E8118 for ; Wed, 25 Sep 2013 08:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.67
X-Spam-Level: 
X-Spam-Status: No, score=-110.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCVNwajRnRTk for ; Wed, 25 Sep 2013 08:35:41 -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 6986111E8119 for ; Wed, 25 Sep 2013 08:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3688; q=dns/txt; s=iport; t=1380123334; x=1381332934; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=N8/bBJrb8MwAfNTnmhS2BzWNkQXxAouyndS6LrimSpE=; b=l3B5oVe8Lv5v1OlbJ+7k5QjxMYVKnc6P6/052I5lYbXCp9j9w0qFWzcf Ss7VFIPm7LRSInC0Cnw5ZOxi4iFR7V1jXoGaDnCocOZ+mVnSbSfab1hBe JN2id2hm8EKqp1LEYMZfWyuoGjKcbXmOj0RzH++4x7JCF4YHoe6C8icxG U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAJABQ1KrRDoH/2dsb2JhbABbgwc4rkWSCkqBHhZ0giUBAQEDAQEBAWsLBQkCCxguFhEwBhMbh1kDCQUNvAUEjGKCODMHgx2BAAOJOIxcgRNVgS+JF4F+hTODRBw
X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208";a="93157554"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Sep 2013 15:35:32 +0000
Received: from sjc-vpn3-476.cisco.com (sjc-vpn3-476.cisco.com [10.21.65.220]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PFZVKp023174; Wed, 25 Sep 2013 15:35:31 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing 
In-Reply-To: <52427F74.9030805@alvestrand.no>
Date: Wed, 25 Sep 2013 08:36:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A7BC464-B027-4A94-98D5-440BF45A8D82@cisco.com>
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>, <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>, <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>, <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com>	  <52427F74.9030805@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1508)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] additional ICE info
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, 25 Sep 2013 15:35:49 -0000

On Sep 24, 2013, at 11:15 PM, Harald Alvestrand  =
wrote:

> Thanks for the pointer!
>=20
> The existence of that (public) document explains some strange features
> of some earlier Microsoft proposals that I was never able to get an
> explanation for.
>=20
> This approach (which seems to have many of the properties of RSVP) =
seems
> to offer a solution to some problems that people have been solving by
> snooping SIP (which is impossible if SIP isn't used, and very hard =
when
> all the SIP channels are encrypted).

An additional difficulty, even if the SIP signaling is un-encrypted, is =
on complex (enterprise) networks the SIP signaling path and media path =
may go over different network equipment.  Our existing customers solve =
that problem by ensuring their network topology forces the paths to be =
congruent, but forcing such a network topology has other disadvantages =
(link costs go up, and becomes difficult to design around link failure).

> Is there a chance that we could get
> public-stable specification of the required pieces, so that other
> companies can dare to depend on it?

We recently published =
http://tools.ietf.org/html/draft-martinsen-mmusic-malice which does =
something similar.  We are not married to those exact bits-on-the-wire, =
but we see value in the signaling for both the network and the end hosts =
(such as the TURN server).

-d


> (public-stable, a term I just invented, includes independent RFC, info
> RFC and standards-track)
>=20
> On 09/25/2013 02:10 AM, Dan Wing wrote:
>> On Sep 23, 2013, at 10:00 PM, Bernard Aboba =
 wrote:
>>=20
>>> Dan Wing said:=20
>>>=20
>>> "Another solution is MALICE which adds information to the ICE =
connectivity checks (bandwidth, drop preference, etc.) which can be =
DPI'd by network devices."
>>>=20
>>> [BA]  I am fairly keen on adding some of this information to ICE, =
though not to assist DPI.   Rather, my concern is that with SDP being =
optional in WebRTC, some of the info that would otherwise be exchanged =
in the signaling channel may not be present, and if present, cannot =
necessarily be trusted, so that putting this into the ICE exchange has =
potential security value.  Also, in a situation where TURN servers are =
rented in the cloud, it can be useful to signal the maximum bandwidth =
that could be used for a given allocation. =20
>> Yes, bandwidth is part of Microsoft's extensions to TURN as I'm sure =
you are aware (but others are probably not aware), =
http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx
>>=20
>> The advantage of allowing routers along the path to see the bandwidth =
is they can influence their routing decisions to put the traffic on a =
better path (e.g., 3G versus microwave link versus satellite), =
prioritize the traffic, and do other things.  If the network always has =
sufficient bandwidth and thus no need to differentiate traffic, I agree =
there is no value and no purpose to tell the network anything.
>>=20
>>> To my mind, the issue to be fixed in the TURN REST API wasn't =
necessarily the ability to steal credentials, but the ability to misuse =
those credentials in a way that could impose significant cost on the =
victim.  The act of mis-using a TURN credential does not by itself =
impose that cost -- but pumping huge amounts of traffic through it =
would.=20
>> -d
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> --=20
> Surveillance is pervasive. Go Dark.
>=20


From karl.stahl@intertex.se  Wed Sep 25 16:38:32 2013
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 5CB1511E8123 for ; Wed, 25 Sep 2013 16:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level: 
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEKqX6M2rTQk for ; Wed, 25 Sep 2013 16:38:27 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7918811E8120 for ; Wed, 25 Sep 2013 16:38:23 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309260138217489; Thu, 26 Sep 2013 01:38:21 +0200
From: "Karl Stahl" 
To: "'Cullen Jennings \(fluffy\)'" , "'cb.list6'" 
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>  
In-Reply-To: 
Date: Thu, 26 Sep 2013 01:38:20 +0200
Message-ID: <0c9d01ceba48$517f4530$f47dcf90$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMAgAEA24A=
Content-Language: sv
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 25 Sep 2013 23:38:32 -0000

-----Ursprungligt meddelande-----
Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20
Skickat: den 25 september 2013 06:56
Till: cb.list6
Kopia: Karl Stahl; 
=C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11


> On desktop OS, it is very hard for an application like a browser to =
learn
any information that was passed via DHCP to the host. This has long been =
a
problem for things like geopriv.=20
[Karl] A WebRTC browser must be far beyond "a simple application". How =
can
it otherwise see and hear us, send RTP over UDP, do ICE and other =
advanced
stuff? It must already hook deep into the OS, so that in itself cannot =
be a
problem if the OS would know about such a handy thing as a network =
provided
TURN server...

[Karl] The problem is how will Network Provider can tell the OS about =
the
TURN server he provides together with his access: One of our developers
actually came up with a way of doing that WITHOUT my "provided via DHCP =
(and
maybe RA - Router Advertisement - for IPv6, and the OTT channel in =
mobiles
have their own method I=92ve been told)"! I'll come back tomorrow to =
explain
(asked him to write a few line so I can convey correctly).

>I will note that browsers have many ways to learn about HTTP proxies =
from
the network and it seems to me that using some of theses same technique
might also be a good way to learn about TURN servers.=20


On Sep 23, 2013, at 9:58 AM, cb.list6  wrote:

>=20
> On Sep 20, 2013 8:43 AM, "Karl Stahl"  wrote:
> >
> > For NAT/Firewall traversal WebRTC uses ICE, where the browser today=20
> > gets the TURN server address from the web application, or gets it=20
> > configured by a LAN admin via an =93admin policy template=94.
> >
> > However, there is a need (motivations below) for the TURN server=20
> > address to be provided via DHCP (and maybe RA - Router Advertisement =

> > - for IPv6, and the OTT channel in mobiles have their own method=20
> > I=92ve been told). Simply put, just as you often get your =
IP-address,=20
> > DNS address, etc. automatically from the network access, you should =
also
get the TURN server address.
> >
> > I suggest the following is added to the end of use case (which today =

> > is about multiple TURN servers) 3.2.4.  Simple Video Communication=20
> > Service, global service provider 3.2.4.1.  Description ...
> > "A network service provider must be able to automatically supply a=20
> > TURN server addresses to the browser when accessing a network. The=20
> > address may come via DHCP or a similar mechanism (maybe RA - Router=20
> > Advertisement - for IPv6, an addition to the IPCP protocol like=20
> > RFC1877 for PPPoE, or whatever method the mobile OTT channels use).=20
> > The mechanism should be similar to automatically getting the=20
> > IP-address, DNS address, etc.. and need extensions to current
recommendations/standards.
> >
> > There are several reasons for a network service provider to supply a =

> > TURN server as part of his offered access:
> > - to keep media paths short, specifically not sending media outside=20
> > its own network to some distant application provided TURN server
> > - to support mobility, i.e. you may want to move from a LAN with a=20
> > configured TURN server to accessing via WiFi or 3G/4G OTT channels
>=20
> I have not read the draft but would like to make it clear that no =
2g/3g/4g
provider uses dhcp over the mobile network so this dhcp solution would =
not
apply.
>=20
> CB
>=20
> > - to offer a media path with better quality (than best effort data
traffic).
> > Getting =93WebRTC-ready=94 access and we look forward to =
telepresence=20
> > for everyone.
> >
> > An enterprise network that want to keep a restrictive firewall not=20
> > allowing UDP traffic, could provide a real-time path using a TURN=20
> > server paralleling the firewall, instead of tunneling RTP through=20
> > always open http or https ports resulting in RTP media over TCP =96=20
> > with severe quality problems from TCP retransmissions of dropped=20
> > packets. The TURN server address is most easily provided in the same =

> > way as the IP address and DNS address. (That would also put the=20
> > right party in control =96 The network provider decides what is=20
> > allowed on his network.)
> >
> > This browser should select which available TURN server address to=20
> > use in the following priority order, where ICE could be used to try
several:
> >
> > 1) TURN server address configured in the browser by the user=20
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via=20
> > an =93admin policy template=94
> > 3) TURN server address supplied by DHCP or similar automatic network =

> > method
> > 4) TURN server address being supplied by the web application"
> >
> > Two new requirements can be extracted:
> > "   ----------------------------------------------------------------
> >    F40     The browser must support retrieving TURN server addresses =
via
> > DHCP or a similar mechanism (maybe RA - Router Advertisement - for=20
> > IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or=20
> > whatever method the mobile OTT channels use). The mechanism should=20
> > be similar to automatically getting the IP-address, DNS address, =
etc..
> >    ----------------------------------------------------------------
> >    F42     This browser should select which available TURN server
address to
> > use in the following priority order, where ICE could be used to try
several:
> >
> > 1) TURN server address configured in the browser by the user=20
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via=20
> > an =93admin policy template=94
> > 3) TURN server address supplied by DHCP or similar automatic network =

> > method
> > 4) TURN server address being supplied by the web application=20
> > ----------------------------------------------------------------"
> >
> > I suppose this also will add to:
> > 5.  IANA Considerations
> >    TBD
> >
> > /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] =
F=F6r=20
> > Cullen Jennings (fluffy)
> > Skickat: den 4 september 2013 18:24
> > Till: rtcweb@ietf.org
> > =C4mne: [rtcweb] WGLC of=20
> > draft-ietf-rtcweb-use-cases-and-requirements-11
> >
> >
> > We would like to start a working group last call of=20
> > draft-ietf-rtcweb-use-cases-and-requirements-11.
> >
> > Please send comments by the end of the day on September 21.
> >
> > Thank you,
> >
> > The chairs =85.
> >
> >
> >
> >
> > _______________________________________________
> > 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 junluan.xia@intel.com  Thu Sep 26 00:55:21 2013
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 864A221F9FBC for ; Thu, 26 Sep 2013 00:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.378
X-Spam-Level: 
X-Spam-Status: No, score=-8.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfBOmTuDxGKu for ; Thu, 26 Sep 2013 00:55:15 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C421F9FE5 for ; Thu, 26 Sep 2013 00:55:15 -0700 (PDT)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 26 Sep 2013 00:55:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.90,983,1371106800";  d="scan'208,217";a="401267633"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by fmsmga001.fm.intel.com with ESMTP; 26 Sep 2013 00:55:14 -0700
Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Sep 2013 00:55:14 -0700
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Sep 2013 00:55:13 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.4]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.12]) with mapi id 14.03.0123.003; Thu, 26 Sep 2013 15:55:02 +0800
From: "Xia, Junluan" 
To: "rtcweb@ietf.org" 
Thread-Topic: unsubscribe
Thread-Index: Ac66jbRGpIbc3Gx3SaK+GmZQElyRtA==
Date: Thu, 26 Sep 2013 07:55:02 +0000
Message-ID: <7841A4E0A9C8784C9D8B07DF5E48F0A811601081@SHSMSX104.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/alternative; boundary="_000_7841A4E0A9C8784C9D8B07DF5E48F0A811601081SHSMSX104ccrcor_"
MIME-Version: 1.0
Subject: [rtcweb] unsubscribe
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, 26 Sep 2013 07:55:21 -0000

--_000_7841A4E0A9C8784C9D8B07DF5E48F0A811601081SHSMSX104ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



regards,
Andrew


--_000_7841A4E0A9C8784C9D8B07DF5E48F0A811601081SHSMSX104ccrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


 


regards,


Andrew


 






--_000_7841A4E0A9C8784C9D8B07DF5E48F0A811601081SHSMSX104ccrcor_--

From paalh@ifi.uio.no  Thu Sep 26 02:11:41 2013
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 6D26511E817F; Thu, 26 Sep 2013 02:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgYpeHtMjMWr; Thu, 26 Sep 2013 02:11:35 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 929FD11E8177; Thu, 26 Sep 2013 02:11:33 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VP7bg-0002Y2-CK; Thu, 26 Sep 2013 11:11:32 +0200
Received: from 1x-193-157-253-105.uio.no ([193.157.253.105]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1VP7bg-0000lY-0h; Thu, 26 Sep 2013 11:11:32 +0200
From: =?iso-8859-1?Q?P=E5l_Halvorsen?= 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Sep 2013 11:11:31 +0200
Message-Id: 
To: rmcat@ietf.org, rtcweb@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 45 msgs/h 16 sum rcpts/h 48 sum msgs/h 17 total rcpts 5254 max rcpts/h 73 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.1, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C20EDEBDA27324E730C07B5BDBC2CFC9E92B2B35
X-UiO-SPAM-Test: remote_host: 193.157.253.105 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 16 total 46 max/h 16 blacklist 0 greylist 0 ratelimit 0
Subject: [rtcweb] [Packet Video 2013] Call for posters and demos, deadline 11 October
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, 26 Sep 2013 09:11:41 -0000

-=
--------------------------------------------------------------------------=
---------------------
Packet Video 2013
December 12 and 13th =96 San Jose, CA USA
http://pv2013.itec.aau.at/
http://pv2013.itec.aau.at/2013/09/call-for-posters-and-demos/

CALL FOR POSTERS AND DEMOS
Deadline: Friday, October 11th
=
--------------------------------------------------------------------------=
----------------------

We invite Packet Video attendees to participate to a special poster and =
demo session=20
in the Packet Video technical program that will foster lively, informal, =
and in-depth=20
discussions. Topics of interest include, but are not limited to:

- Cloud and peer-to-peer system architectures
- Media streaming, distribution and storage support
- Multimedia communications and system security
- Multi-core and many-core architecture support
-  Networked GPUs, graphics and virtual environments
-  Networked games, real-time immersive systems
- Operating system, middleware and network support
- Web 2.0 systems and social networks
- Next-generation video like multi-view, panorama and 3D
- Wireless networks and embedded systems for multimedia applications
- Content-centric networking

What and How to Submit

Packet Video posters and demos will be selected on the basis of two-page =
PDF abstracts,=20
with fonts no smaller than 10 point, using the same format as for =
regular papers. You=20
can download templates for your abstract on the IEEE website. Abstracts =
must be submitted=20
through the submission system at

http://pv2013.itec.aau.at/submission-poster/

Posters will be reviewed and selected on the following basis:

- Submissions must describe new, interesting work, not previously =
presented. Posters may=20
  be accompanied by demos (subject to limited space). Preference will be =
given toward=20
  posters accompanied by demos.
- Student submissions meeting the above criteria will be given =
preference; however,=20
  non-students may also submit abstracts.=20

Please provide the following information in your PDF file in addition to =
presenting=20
your research:

- Poster title
- Author names, affiliations and email addresses
- Mark which authors, if any, are students
- Indicate if you plan to set up a demo with your poster. If so, the =
submission must include=20
  the requirements for the demo setup and presentation. Note that the =
authors will be responsible=20
  to bring and set up any equipment they will need.

No reviews will be provided.

Posters will be published online on the workshop Web site. Authors of =
the best posters will be=20
given three minutes each to present their work before the poster =
session. At least one author=20
should register and present the poster throughout the entire session.

Important Dates

- Submission: Friday, October 11th
- Notifications: Friday, October 18th
- Workshop

Best regards,
John Apostolopoulos and P=E5l Halvorsen.
(TPC co-chairs)=

From harald@alvestrand.no  Thu Sep 26 03:45:59 2013
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 77E7311E80AD for ; Thu, 26 Sep 2013 03:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.473
X-Spam-Level: 
X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9oJw38OHW+J for ; Thu, 26 Sep 2013 03:45:53 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B303321F9E02 for ; Thu, 26 Sep 2013 03:45:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F09D39E2A9 for ; Thu, 26 Sep 2013 12:45:33 +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 D5tq+D5VMnum for ; Thu, 26 Sep 2013 12:45:31 +0200 (CEST)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A4D5B39E1AD for ; Thu, 26 Sep 2013 12:45:31 +0200 (CEST)
Message-ID: <5244104D.4010401@alvestrand.no>
Date: Thu, 26 Sep 2013 12:45:33 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>   <0c9d01ceba48$517f4530$f47dcf90$@stahl@intertex.se>
In-Reply-To: <0c9d01ceba48$517f4530$f47dcf90$@stahl@intertex.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 10:45:59 -0000

On 09/26/2013 01:38 AM, Karl Stahl wrote:
>
> -----Ursprungligt meddelande-----
> Från: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
> Skickat: den 25 september 2013 06:56
> Till: cb.list6
> Kopia: Karl Stahl; 
> Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
>> On desktop OS, it is very hard for an application like a browser to learn
> any information that was passed via DHCP to the host. This has long been a
> problem for things like geopriv.
> [Karl] A WebRTC browser must be far beyond "a simple application". How can
> it otherwise see and hear us, send RTP over UDP, do ICE and other advanced
> stuff? It must already hook deep into the OS, so that in itself cannot be a
> problem if the OS would know about such a handy thing as a network provided
> TURN server...

All OSes have APIs. These APIs are controlled by the OS vendor.
Most of the information that's common across the relevant platforms is 
the information encapsulated in the POSIX standard (which is the base 
for both *BSD and Linux, which again form the basis for Android, MacOS 
and Linux).

So far, neither the POSIX standard nor any OS vendor has offered a 
generic facility to access information made available in DHCP packets.

Please don't talk about what "must be". Talk about what is. And if you 
don't know what is, ask.


From Markus.Isomaki@nokia.com  Thu Sep 26 05:13:53 2013
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 14FCD21F9FC6 for ; Thu, 26 Sep 2013 05:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.505
X-Spam-Level: 
X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyFeakOcqvgp for ; Thu, 26 Sep 2013 05:13:47 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 03BEF21F9FB9 for ; Thu, 26 Sep 2013 05:13:44 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8QC6U6h029549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 26 Sep 2013 15:06:31 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Thu, 26 Sep 2013 12:06:30 +0000
From: 
To: , 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMAgAHIA1A=
Date: Thu, 26 Sep 2013 12:06:29 +0000
Message-ID: 
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoWdnCqQrUspJ5y5HR/Ccg81qyIEN84D/hR6GTUXC26eX7lfXotW/5WQV5Q3W3gT4Oss8ZbiZfl04tcVZz8Rv6/dJS+ytjXbZ7wD8sa9q6Ip22rHZuUoFZY/cGwnexoSojecOUW1jjAN3mknRuD5xEDPXK/TKtnyQt7cX9B4ZzozRoRIoJ4O0rfla9cdCN5ssZ/L8baiWf4CFxVbiiZtd74jGkdrh2fKR8ZkMc4jpcOMVqfzkdqU8guGcxcEXkd+EYJBPubCjw+avxppEicSns8SxCIs7N2AobcsrrPFbiqP4aRvI8E+YrWc8fv0y1Q3kg==
x-originating-ip: [10.236.13.87]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 12:13:53 -0000

Hi,

Cullen Jennings wrote:
>=20
> I will note that browsers have many ways to learn about HTTP proxies from
> the network and it seems to me that using some of theses same technique
> might also be a good way to learn about TURN servers.
>=20

I agree. I assume that in enterprises it would be the same people managing =
both of these.

Is there something the IETF can or should do about this, or do we just assu=
me it will happen? A new DHCP option is something the IETF could easily do,=
 but I also doubt how usable that would be.=20

Markus=20

From hangzhou.chenxin@huawei.com  Thu Sep 26 06:00:27 2013
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 E0B6921F9BD0 for ; Thu, 26 Sep 2013 06:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.119
X-Spam-Level: 
X-Spam-Status: No, score=-7.119 tagged_above=-999 required=5 tests=[AWL=0.280,  BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBAro-Ca0cMK for ; Thu, 26 Sep 2013 06:00:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 586F911E8168 for ; Thu, 26 Sep 2013 05:59:49 -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 AVW74649; Thu, 26 Sep 2013 12:59:45 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 13:58:21 +0100
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 13:59:10 +0100
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 20:59:06 +0800
From: "Chenxin (Xin)" 
To: Karl Stahl , "rtcweb@ietf.org" ,  "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" 
Thread-Topic: [rtcweb]  WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7CAAEbaMIAAkEbggABmefA=
Date: Thu, 26 Sep 2013 12:59:06 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE03976808095D@SZXEMA504-MBX.china.huawei.com>
References:  <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com> <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680805AC@SZXEMA504-MBX.china.huawei.com> <0b5b01ceb961$db8cff20$92a6fd60$@stahl@intertex.se>
In-Reply-To: <0b5b01ceb961$db8cff20$92a6fd60$@stahl@intertex.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.41.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 13:00:27 -0000

Hi karl,

>-----Original Message-----
>From: Karl Stahl [mailto:karl.stahl@intertex.se]
>Sent: Wednesday, September 25, 2013 4:09 AM
>To: Chenxin (Xin); rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>Subject: SV: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements=
-11
>
>
>
>-----Ursprungligt meddelande-----
>Fr=E5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]
>Skickat: den 24 september 2013 13:56
>Till: Karl Stahl; rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>=C4mne: RE: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-=
11
>
>Hi Karl,
>>>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11,
>>>here are a few "telephony related" WebRTC things I think should be
>>>clarified in the use cases.
>>>
>>>
>>>3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...
>>>The invited user might accept or reject the session.
>>>[Suggest adding] The invited user might accept only audio, rejecting
>>>video (even if a camera is enabled). A user may also select to
>>>initiate an audio session, without video.
>>>
>>>And in API requirements:
>>>   ----------------------------------------------------------------
>>>   A1      The Web API must provide means for the application to ask the
>>>browser for permission to use cameras and microphones, individually as
>>>input devices. (One must be able to answer with voice only - declining
>>video.)
>>>   ----------------------------------------------------------------
>>
>>>Same under
>>>6.2.  Browser Considerations
>>>...
>>>The browser is expected to provide mechanisms for users to revise and
>>>even completely revoke consent to use device resources such as camera
>>>and microphone. [Suggest adding] Specifically, a user must be given
>>>the opportunity to only accept audio in a video call invitation.
>>>
>>[Xin] it is a common use case to accept only audio call and reject the
>>video and quite useful. But I am doubt that this function should be
>>mixed with video or audio device access permission . Do I misunderstand
>your proposal?
>>I think we could just disable the video stream when signaling. So we
>>could make video call with one and reject it with other in the same
>>web-service. I think the audio and video device access permission is
>>not for each call(peer connection).
>>
>>Thanks,
>>   Xin
>>[Karl] Try using a WebRTC application with Chrome and you will see: The
>>Permission/Allowance to use Camera and Microphone comes up at a bar at
>>the top of the browser window and is the actual answering of a call.
>
>[Xin] yes, it come up because invoking the getUserMedia API. When we write
>the webrtc app, we could call getUserMedia API just once and use the same
>mediaStream later. The webrtc app could decide to send the video stream to
>the other side or not by configure the signaling(SDP or other).  It is
>trivial to click the Permission bar at the top every time when I get a cal=
l,
>even terrible when join a p2p conference.
>That is the reason I think the use case you mentioned should not mix with
>permission, which should be a signaling configuration problem. Now in
>Chrome,we could control it by using creatOffer or createAnswer and setting
>the OfferToReceiveVideo constraint.
>
>Thanks,
>   Xin
>[Karl] If you permit the Browser to use the camera, then later "answer wit=
h
>only audio in the application" (as I understand you suggest)=20
[Xin] this is the function of PeerConnection API in W3C.=20

- Can we trust
>that the application isn't sending our video anyway - not even informing u=
s?
>
>I don't think we can trust any video WebRTC application, but will learn to
>only trust well known browsers not to view us, when we don't want to be
>seen.
>
>Isn't this a necessary security thing?
>
>/Karl
>
[Xin] I agree with you that the app is possible to steal user's video or au=
dio stream.=20
But it is still hard to controI if the stream from getUserMedia could be us=
ed by other call(peerconnection) as designed in API now.

What I want to say is that the permission to access the device is orthogona=
l to consent to transmit the media to whom. The first one is for a site. Th=
e second one is for a user, it could be guaranteed by other ways, such as i=
dentity, media-encryption and so on, which need other consent method.=20

 There are some details in http://tools.ietf.org/html/draft-ietf-rtcweb-sec=
urity-05#section-4.1.2.1


From karl.stahl@intertex.se  Thu Sep 26 08:27:26 2013
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 C888D11E80D2 for ; Thu, 26 Sep 2013 08:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh5VAETItB0U for ; Thu, 26 Sep 2013 08:27:22 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id C259E11E8109 for ; Thu, 26 Sep 2013 08:27:20 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309261727165400; Thu, 26 Sep 2013 17:27:16 +0200
From: "Karl Stahl" 
To: , , 
References: 	<523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>		 
In-Reply-To: 
Date: Thu, 26 Sep 2013 17:27:16 +0200
Message-ID: <0d7a01cebacc$e20a65b0$a61f3110$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMAgAHIA1CAABYNkA==
Content-Language: sv
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 15:27:26 -0000

Here comes the suggestion I got from my developer that would allow a =
network
provider to offer his TURN server for the WebRTC browser to use. This =
would
require NO new DHCP-options or similar, and NO OS changes (I do realize
those should be avoided if possible...).

The idea is still, that whoever is responsible for giving a device an IP
address (the network provider or a LAN administrator) can also announce =
a
TURN server for the WebRTC browser to use.

The suggestion is to use RFC6763 (DNS-Based Service Discovery, see =
chapter
11) where the network provider (the owner of the IP address) has set up =
a
DNS PTR record for the TURN server in the in-addr.arpa domain.=20

If the device got IP 173.164.252.149, then make a query for the PTR =
record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV record would return the actual address to the TURN server =
(and
you may find several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the =
WAN
IP you get via STUN in the ICE process. But if the LAN administrator
provides a local TURN server, then he also should have blocked STUN in =
the
firewall, and the browser should query the device's local host address =
(as
in the ICE procedure) and the local LAN DNS server should answer the =
query
to give the local TURN server address on the LAN.

Shouldn't this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work nicely for mobile devices, whenever the device is =
on
a "WebRTC-ready access" (actually good for everything using ICE), =
whether
fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
mechanism).

Not to slow down every call setup by doing this in the ICE process, I =
guess
this could be done when starting the browser and when the device gets a =
new
IP address, to have the TURN server address ready for later use.

/Karl


-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r
Markus.Isomaki@nokia.com
Skickat: den 26 september 2013 14:06
Till: fluffy@cisco.com; cb.list6@gmail.com
Kopia: rtcweb@ietf.org
=C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi,

Cullen Jennings wrote:
>=20
> I will note that browsers have many ways to learn about HTTP proxies=20
> from the network and it seems to me that using some of theses same=20
> technique might also be a good way to learn about TURN servers.
>=20

I agree. I assume that in enterprises it would be the same people =
managing
both of these.

Is there something the IETF can or should do about this, or do we just
assume it will happen? A new DHCP option is something the IETF could =
easily
do, but I also doubt how usable that would be.=20

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


From karl.stahl@intertex.se  Thu Sep 26 08:49:27 2013
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 3B40021F9C46 for ; Thu, 26 Sep 2013 08:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_93=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l+YnQqnl-IB for ; Thu, 26 Sep 2013 08:49:19 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 55B5721F9B08 for ; Thu, 26 Sep 2013 08:47:54 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309261747488060; Thu, 26 Sep 2013 17:47:48 +0200
From: "Karl Stahl" 
To: "'Chenxin \(Xin\)'" , , 
References: 	<5238446D.8050700@ericsson.com>	<9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>	<07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680804B3@SZXEMA504-MBX.china.huawei.com> <09d801ceb8f4$3b50dfd0$b1f29f70$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE0397680805AC@SZXEMA504-MBX.china.huawei.com> <0b5b01ceb961$db8cff20$92a6fd60$@stahl@intertex.se> <9E34D50A21D1D1489134B4D770CE03976808095D@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976808095D@SZXEMA504-MBX.china.huawei.com>
Date: Thu, 26 Sep 2013 17:47:48 +0200
Message-ID: <0d8101cebacf$c08f5aa0$41ae0fe0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7CAAEbaMIAAkEbggABmefCAAnUBoA==
Content-Language: sv
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 15:49:27 -0000

Hi Xin,
> permission to access the device is orthogonal to consent to transmit =
the
media to whom....

Thanks for the draft pointer, but what about the common usage that I =
pass
you a link: "Click here so we can discuss further", You click and run =
_my_
application och you are prompted by your browser to permit Mic&Camera, =
and
get no further option at all to restrict to only voice?

Doesn't _the browser_ really have to show an "Only Mic"-permission also,
i.e. three buttons "Deny", "Video Call", "Voice Call"?

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20
Skickat: den 26 september 2013 14:59
Till: Karl Stahl; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: RE: [rtcweb] WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi karl,

>-----Original Message-----
>From: Karl Stahl [mailto:karl.stahl@intertex.se]
>Sent: Wednesday, September 25, 2013 4:09 AM
>To: Chenxin (Xin); rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>Subject: SV: [rtcweb] WGLC of=20
>draft-ietf-rtcweb-use-cases-and-requirements-11
>
>
>
>-----Ursprungligt meddelande-----
>Fr=E5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]
>Skickat: den 24 september 2013 13:56
>Till: Karl Stahl; rtcweb@ietf.org;
>draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
>=C4mne: RE: [rtcweb] WGLC of=20
>draft-ietf-rtcweb-use-cases-and-requirements-11
>
>Hi Karl,
>>>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11,
>>>here are a few "telephony related" WebRTC things I think should be=20
>>>clarified in the use cases.
>>>
>>>
>>>3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...
>>>The invited user might accept or reject the session.
>>>[Suggest adding] The invited user might accept only audio, rejecting=20
>>>video (even if a camera is enabled). A user may also select to=20
>>>initiate an audio session, without video.
>>>
>>>And in API requirements:
>>>   ----------------------------------------------------------------
>>>   A1      The Web API must provide means for the application to ask =
the
>>>browser for permission to use cameras and microphones, individually=20
>>>as input devices. (One must be able to answer with voice only -=20
>>>declining
>>video.)
>>>   ----------------------------------------------------------------
>>
>>>Same under
>>>6.2.  Browser Considerations
>>>...
>>>The browser is expected to provide mechanisms for users to revise and =

>>>even completely revoke consent to use device resources such as camera =

>>>and microphone. [Suggest adding] Specifically, a user must be given=20
>>>the opportunity to only accept audio in a video call invitation.
>>>
>>[Xin] it is a common use case to accept only audio call and reject the =

>>video and quite useful. But I am doubt that this function should be=20
>>mixed with video or audio device access permission . Do I=20
>>misunderstand
>your proposal?
>>I think we could just disable the video stream when signaling. So we=20
>>could make video call with one and reject it with other in the same=20
>>web-service. I think the audio and video device access permission is=20
>>not for each call(peer connection).
>>
>>Thanks,
>>   Xin
>>[Karl] Try using a WebRTC application with Chrome and you will see:=20
>>The Permission/Allowance to use Camera and Microphone comes up at a=20
>>bar at the top of the browser window and is the actual answering of a
call.
>
>[Xin] yes, it come up because invoking the getUserMedia API. When we=20
>write the webrtc app, we could call getUserMedia API just once and use=20
>the same mediaStream later. The webrtc app could decide to send the=20
>video stream to the other side or not by configure the signaling(SDP or =

>other).  It is trivial to click the Permission bar at the top every=20
>time when I get a call, even terrible when join a p2p conference.
>That is the reason I think the use case you mentioned should not mix=20
>with permission, which should be a signaling configuration problem. Now =

>in Chrome,we could control it by using creatOffer or createAnswer and=20
>setting the OfferToReceiveVideo constraint.
>
>Thanks,
>   Xin
>[Karl] If you permit the Browser to use the camera, then later "answer=20
>with only audio in the application" (as I understand you suggest)
[Xin] this is the function of PeerConnection API in W3C.=20

- Can we trust
>that the application isn't sending our video anyway - not even =
informing
us?
>
>I don't think we can trust any video WebRTC application, but will learn =

>to only trust well known browsers not to view us, when we don't want to =

>be seen.
>
>Isn't this a necessary security thing?
>
>/Karl
>
[Xin] I agree with you that the app is possible to steal user's video or
audio stream.=20
But it is still hard to controI if the stream from getUserMedia could be
used by other call(peerconnection) as designed in API now.

What I want to say is that the permission to access the device is =
orthogonal
to consent to transmit the media to whom. The first one is for a site. =
The
second one is for a user, it could be guaranteed by other ways, such as
identity, media-encryption and so on, which need other consent method.=20

 There are some details in
http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.2.1


From cb.list6@gmail.com  Thu Sep 26 16:05:59 2013
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 B6D8721F944C for ; Thu, 26 Sep 2013 16:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r6HVwWQ70e0 for ; Thu, 26 Sep 2013 16:05:57 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7DE11E80EE for ; Thu, 26 Sep 2013 16:05:57 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id hm2so31829wib.0 for ; Thu, 26 Sep 2013 16:05:56 -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=W/OGNajPlC7SAmLEc1cy5gOCbbpq2US8A9LNU3T/tLY=; b=iGA3qczWDcCUfDL0qIHUOrm69hjC1OZigCMM7kcFPlCD9u0tYD9uqLMsHfKBRmshCU /3Y8xlumobkmzQwZQTeSGhK4mJzzU9o3xqMlmBMJQI6SxIyiojaWSxrvhf7wyE33aAC2 U6jcuZfgyF6+UvQ899w0iFo4Xl/UMIsSLDzxzOyvCXSEcEyiSh/Rin8AVcCIyLbsz/6d oj89i+IOEjl/FxZVuma2fUA+fLI3tG5tPTxWADJDbNcFfSN3CEaQASjOraAf1YoJrCu3 JwXlGHczQmFoKP4T3dTgDcKC4Q+MKj3cxjwcxZKunS32nDidJM+MQNEY6rJJ2FtSS5SA Dh+Q==
MIME-Version: 1.0
X-Received: by 10.181.12.75 with SMTP id eo11mr77075wid.24.1380236756331; Thu, 26 Sep 2013 16:05:56 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Thu, 26 Sep 2013 16:05:56 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Thu, 26 Sep 2013 16:05:56 -0700 (PDT)
In-Reply-To: <52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com>
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>    <52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Thu, 26 Sep 2013 16:05:56 -0700
Message-ID: 
From: "cb.list6" 
To: Karl Stahl 
Content-Type: multipart/alternative; boundary=f46d043c7c5691387604e751693e
Cc: fluffy@cisco.com, rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 23:05:59 -0000

--f46d043c7c5691387604e751693e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sep 26, 2013 8:27 AM, "Karl Stahl"  wrote:
>
> Here comes the suggestion I got from my developer that would allow a
network
> provider to offer his TURN server for the WebRTC browser to use. This
would
> require NO new DHCP-options or similar, and NO OS changes (I do realize
> those should be avoided if possible...).
>
> The idea is still, that whoever is responsible for giving a device an IP
> address (the network provider or a LAN administrator) can also announce a
> TURN server for the WebRTC browser to use.
>
> The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapte=
r
> 11) where the network provider (the owner of the IP address) has set up a
> DNS PTR record for the TURN server in the in-addr.arpa domain.
>
> If the device got IP 173.164.252.149, then make a query for the PTR recor=
d
> for:
> _turn._udp.149.252.164.173.in-addr.arpa.
> Then the SRV record would return the actual address to the TURN server
(and
> you may find several for load balancing and failover I guess)
>
> If the device is on a LAN, the IP 173.164.252.149 to query would be the
WAN
> IP you get via STUN in the ICE process. But if the LAN administrator
> provides a local TURN server, then he also should have blocked STUN in th=
e
> firewall, and the browser should query the device's local host address (a=
s
> in the ICE procedure) and the local LAN DNS server should answer the quer=
y
> to give the local TURN server address on the LAN.
>
> Shouldn't this work to allow network provider to offer his TURN server
> "automatically and generally"?
>
> And wouldn't this work nicely for mobile devices, whenever the device is
on
> a "WebRTC-ready access" (actually good for everything using ICE), whether
> fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
> provider hopefully offers a prioritized pipe there as one usage of this
> mechanism).
>

Does your mobile provider currently do reverse dns for your mobile's real
ip address?

CB

> Not to slow down every call setup by doing this in the ICE process, I
guess
> this could be done when starting the browser and when the device gets a
new
> IP address, to have the TURN server address ready for later use.
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r
> Markus.Isomaki@nokia.com
> Skickat: den 26 september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia: rtcweb@ietf.org
> =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> draft-ietf-rtcweb-use-cases-and-requirements-11
>
> Hi,
>
> Cullen Jennings wrote:
> >
> > I will note that browsers have many ways to learn about HTTP proxies
> > from the network and it seems to me that using some of theses same
> > technique might also be a good way to learn about TURN servers.
> >
>
> I agree. I assume that in enterprises it would be the same people managin=
g
> both of these.
>
> Is there something the IETF can or should do about this, or do we just
> assume it will happen? A new DHCP option is something the IETF could
easily
> do, but I also doubt how usable that would be.
>
> Markus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d043c7c5691387604e751693e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Sep 26, 2013 8:27 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote:

>

> Here comes the suggestion I got from my developer that would allow a n=
etwork

> provider to offer his TURN server for the WebRTC browser to use. This =
would

> require NO new DHCP-options or similar, and NO OS changes (I do realiz=
e

> those should be avoided if possible...).

>

> The idea is still, that whoever is responsible for giving a device an =
IP

> address (the network provider or a LAN administrator) can also announc=
e a

> TURN server for the WebRTC browser to use.

>

> The suggestion is to use RFC6763 (DNS-Based Service Discovery, see cha=
pter

> 11) where the network provider (the owner of the IP address) has set u=
p a

> DNS PTR record for the TURN server in the in-addr.arpa domain.

>

> If the device got IP 173.164.252.149, then make a query for the PTR re=
cord

> for:

> _turn._udp.149.252.164.173.in-addr.arpa.

> Then the SRV record would return the actual address to the TURN server=
 (and

> you may find several for load balancing and failover I guess)

>

> If the device is on a LAN, the IP 173.164.252.149 to query would be th=
e WAN

> IP you get via STUN in the ICE process. But if the LAN administrator
> provides a local TURN server, then he also should have blocked STUN in=
 the

> firewall, and the browser should query the device's local host add=
ress (as

> in the ICE procedure) and the local LAN DNS server should answer the q=
uery

> to give the local TURN server address on the LAN.

>

> Shouldn't this work to allow network provider to offer his TURN se=
rver

> "automatically and generally"?

>

> And wouldn't this work nicely for mobile devices, whenever the dev=
ice is on

> a "WebRTC-ready access" (actually good for everything using =
ICE), whether

> fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network<=
br>
> provider hopefully offers a prioritized pipe there as one usage of thi=
s

> mechanism).

>


Does your mobile provider currently do reverse dns for your =
mobile's real ip address?


CB


> Not to slow down every call setup by doing this in the =
ICE process, I guess

> this could be done when starting the browser and when the device gets =
a new

> IP address, to have the TURN server address ready for later use.

>

> /Karl

>

>

> -----Ursprungligt meddelande-----

> Fr=E5n: rtcweb-bounces@ietf=
.org [mailto:rtcweb-bounces@=
ietf.org] F=F6r

> Markus.Isomaki@nokia.com

> Skickat: den 26 september 2013 14:06

> Till: fluffy@cisco.com; cb.list6@gmail.com

> Kopia: rtcweb@ietf.org

> =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of

> draft-ietf-rtcweb-use-cases-and-requirements-11

>

> Hi,

>

> Cullen Jennings wrote:

> >

> > I will note that browsers have many ways to learn about HTTP prox=
ies

> > from the network and it seems to me that using some of theses sam=
e

> > technique might also be a good way to learn about TURN servers.
> >

>

> I agree. I assume that in enterprises it would be the same people mana=
ging

> both of these.

>

> Is there something the IETF can or should do about this, or do we just=


> assume it will happen? A new DHCP option is something the IETF could e=
asily

> do, but I also doubt how usable that would be.

>

> Markus

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

>




--f46d043c7c5691387604e751693e--

From fluffy@cisco.com  Thu Sep 26 16:56:03 2013
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 B326B21E80CB for ; Thu, 26 Sep 2013 16:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.562
X-Spam-Level: 
X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MafnrYmuvaeC for ; Thu, 26 Sep 2013 16:55:58 -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 C24DF21E80CC for ; Thu, 26 Sep 2013 16:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=812; q=dns/txt; s=iport; t=1380239750; x=1381449350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uGEgpAG8UyG2nngXGgxFrlrm9zMUDgfBiab8/e4OSXk=; b=Xs6Luk7qBbVfOM5+1e4c0ktBtr3LSFgR79ixbY78xLBDl2XGmQxE04oE oHFHhJVo3GNL1CJOi6emm5c44znzS4O4wSyEIv0eDftFLRjrbtASzpXwi mOKzlwRUmRdQJiKCJhHqG6gMY4fsoNiM4v0UWJGOPaZ9f0WZlX50VSr6e A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjoFACjJRFKtJXG9/2dsb2JhbABbgwc4wRuBGhZtB4IlAQEBAwE6PwULAgEIGB4QMiUCBA4FiAAGvQSPHjMHgx2BAQOXfZF4gWaBPg
X-IronPort-AV: E=Sophos;i="4.90,989,1371081600"; d="scan'208";a="262051468"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 26 Sep 2013 23:55:47 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8QNtkbs000512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 23:55:46 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 18:55:45 -0500
From: "Cullen Jennings (fluffy)" 
To: "Markus.Isomaki@nokia.com" 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMAgAHIA1CAANji7Q==
Date: Thu, 26 Sep 2013 23:55:45 +0000
Message-ID: <9304FCD1-7727-4F98-A810-F75D48769128@cisco.com>
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 26 Sep 2013 23:56:03 -0000

I think we need to give some advise to the browsers vendors on what they sh=
ould implement to find turn servers=20

On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com"  wrote:

> Hi,
>=20
> Cullen Jennings wrote:
>>=20
>> I will note that browsers have many ways to learn about HTTP proxies fro=
m
>> the network and it seems to me that using some of theses same technique
>> might also be a good way to learn about TURN servers.
>=20
> I agree. I assume that in enterprises it would be the same people managin=
g both of these.
>=20
> Is there something the IETF can or should do about this, or do we just as=
sume it will happen? A new DHCP option is something the IETF could easily d=
o, but I also doubt how usable that would be.=20
>=20
> Markus=20

From christer.holmberg@ericsson.com  Fri Sep 27 06:59:23 2013
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 AEA5E11E814F for ; Fri, 27 Sep 2013 06:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.874
X-Spam-Level: 
X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGPMOKfFBf5H for ; Fri, 27 Sep 2013 06:59:17 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4C32321F9CA1 for ; Fri, 27 Sep 2013 06:59:14 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-d4-52458f312f91
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 16.83.25272.13F85425; Fri, 27 Sep 2013 15:59:13 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 15:59:13 +0200
From: Christer Holmberg 
To: "rtcweb@ietf.org" 
Thread-Topic: Unified Plan: 'bundle-only' documentation
Thread-Index: Ac67icB0IqAhwR+TTWqeeD7ies23YA==
Content-Class: urn:content-classes:message
Date: Fri, 27 Sep 2013 13:59:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ADF2D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4ADF2DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvra5hv2uQwdwOeYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMffPJ6aCNSIVqzbOZWlgfCfQxcjJISFgInF8z15mCFtM4sK9 9WwgtpDAUUaJo//Kuxi5gOwljBLvLy5m6mLk4GATsJDo/qcNUiMioC5x+eEFdhBbWMBIYtrW LawQcXOJhtdrWCBsPYld3yeA1TALaEnsmLCPEcRmEVCVWL92DxOIzSvgK/H98wqwOCPQDd9P rWGCqBeXuPVkPhPEbQISS/ach7pTVOLl43+sELaixMdXEDOZBfIlFm2ZygIxU1Di5MwnLBMY hWchWT0LydhZSFpmIWmBiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yGoGmuJ32+PMSKrWcDIuYqR ozi1OCk33chgEyMwfg5u+W2xg/HyX5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYBTh6Tpd+4TjnM8M/Y+znJf92fh7jYFRfDfbsq6XTRrHcq+c/aXrsKvsuluE87el 9z4/6t0X+WeeRbcur3RR5D3Fu/7y/3kMbUt/fwkyOs/zVffGhs/8++Xv6e7PTPslGBU35/Wn 6Z3283Y9nGFR/Xj+U5WjTZw8r/k3qNsmigS2aDhNVmhf916JpTgj0VCLuag4EQBY+ScObQIA AA==
Subject: [rtcweb] Unified Plan: 'bundle-only' documentation
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, 27 Sep 2013 13:59:23 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4ADF2DESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



On the MMUSIC list I have suggested updated SDP Offer/Answer text for BUNDL=
E.



Part of that text is the definition, and usage, of the SDP 'bundle-only' at=
tribute.



However, eventhough I personally think it fits well there (and I believe Ad=
am had the same opinion, when I talked with him off-line in Berlin), afaik =
there has never been any formal WG agreement that the 'bundle-only' attribu=
te will be defined in the BUNDLE draft.



So, without going into the details (there are some issues, and if you are i=
nterested there are mail threads on the MMUSIC list dealing with those) do =
people have any issues with defining the SDP 'bundle-only' attribute, and t=
he usage of it, in BUNDLE?



If not, can we make a WG decision on the matter?



Regards,



Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4ADF2DESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <5B36C4DDF38F0247BA3DDAA9B219DECA@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


On the MMUSIC list I have suggested updated SDP Offer/Answer text for BU=
NDLE.


 


Part of that text is the definition, and usage, of the SDP 'bundle-only'=
 attribute.


 


However, eventhough I personally think it fits well there (and I believe=
 Adam had the same opinion, when I talked with him off-line in Berlin), afa=
ik there has never been any formal WG agreement that the 'bundle-only' attr=
ibute will be defined in the BUNDLE
 draft.


 


So, without going into the details (there are some issues, and =
;if you are interested there are mail threads on the MMUSIC list dealing wi=
th those) do people have any issues with defining the SDP 'bundle-only=
' attribute, and the usage of it, in BUNDLE?


 


If not, can we make a WG decision on the matter?


 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B1C4ADF2DESESSMB209erics_--

From juberti@google.com  Fri Sep 27 08:58:47 2013
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 C6AF221F8E40 for ; Fri, 27 Sep 2013 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM-9cTzjJKJZ for ; Fri, 27 Sep 2013 08:58:47 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4FE21F9123 for ; Fri, 27 Sep 2013 08:58:47 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id tp5so4275249ieb.26 for ; Fri, 27 Sep 2013 08:58:46 -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; bh=iXEuoljB7kpdGsGp2MlRXkWJo/mvEUIlLYeSusUQG7s=; b=G0r8HgZGjhBK/9EYLXSDXcp9wuuEkcJbnYKxIj3r8wVkAVUht+99LFchTH9SCkNLdf 7OfiLBYuDVKg0NThssec2C3J1OcJVRMlup7ZNdk+r9YGTEo6jJIZNZF8xPEi/gKBLOFn sUsyw/coviX6FxmG5IDs3FiDnbcBYICLdU4xX3MT8m6bL4SHVS1n0bONhqUhih8j7diP 1q27A6A3Iu+mdz4Lok/67pwrB748qmwupysTZEeqcEcFLWy10Y3HUJbFaB6BL4tYOQO+ Q20m6ok0B8Hbv0S+CcUPn5zCjen2nAfvz9koNPHZ1+GVzmm0BqEPfreW6g215lFzhlBr KQKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iXEuoljB7kpdGsGp2MlRXkWJo/mvEUIlLYeSusUQG7s=; b=F9u2EQvTWOvWe5eQjq6DkSKpYJ5utOuyU3FE7UB+MvgNM7CrIqGkunSz8TdtWxEoNt sV2//WEvwh4JlsTKeWWF9O0Ji99NB0KFK/qlgtCi8T/yZAQhisLlhUZA+tdYjLSL3ffp e9I1M+zzHzwaarBREQQEZxcykIIFyo7hT8LmiiKY02DaIfrT+lIYA5JmzAelUKei05Wa 0/irgeMpmRwCqzUVXZStqObMwvTW2YMp7SBhTM+xGBi/yeuI5rTkyteqIbjwPtRCqW52 hWxOYmDYNagBxcwAErwux5YxHJweU/XCr+GZLLDKVhek30nenz+LZrwMCH1NPgvRJCg3 mo+Q==
X-Gm-Message-State: ALoCoQkIQCA7mcJStsv+2MIqLIfbwNzVslvSYgmjLqw1KqCszlL7EtKDmwsiqCyppIiLEsdn4yfwxw3HhfbWl9p0LmhhT3ckN1PvQeG8tQZS/azDlJpCCG4iNTGD36lSrkdMlogaISemRmpuxl6c06EohJxH7SChMRLxTwuy8kfotcowA8/KBsN5f0qY7KnEtxML/1EkKtex
X-Received: by 10.42.97.71 with SMTP id m7mr6993056icn.33.1380297525639; Fri, 27 Sep 2013 08:58:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 08:58:25 -0700 (PDT)
In-Reply-To: <9304FCD1-7727-4F98-A810-F75D48769128@cisco.com>
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>    <9304FCD1-7727-4F98-A810-F75D48769128@cisco.com>
From: Justin Uberti 
Date: Fri, 27 Sep 2013 08:58:25 -0700
Message-ID: 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=20cf303bf958b364f404e75f8f88
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 27 Sep 2013 15:58:47 -0000

--20cf303bf958b364f404e75f8f88
Content-Type: text/plain; charset=UTF-8

Agree. I still think that extending PAC files to include TURN information
is the right way to go.

PAC files can already be discovered via DHCP or DNS, there is no need to
reinvent this wheel.


On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy)
wrote:

>
> I think we need to give some advise to the browsers vendors on what they
> should implement to find turn servers
>
> On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com" <
> Markus.Isomaki@nokia.com> wrote:
>
> > Hi,
> >
> > Cullen Jennings wrote:
> >>
> >> I will note that browsers have many ways to learn about HTTP proxies
> from
> >> the network and it seems to me that using some of theses same technique
> >> might also be a good way to learn about TURN servers.
> >
> > I agree. I assume that in enterprises it would be the same people
> managing both of these.
> >
> > Is there something the IETF can or should do about this, or do we just
> assume it will happen? A new DHCP option is something the IETF could easily
> do, but I also doubt how usable that would be.
> >
> > Markus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--20cf303bf958b364f404e75f8f88
Content-Type: text/html; charset=UTF-8


Agree. I still think that extending PAC files to include TURN information is the right way to go.

PAC files can already be discovered via DHCP or DNS, there is no need to reinvent this wheel.





On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:





I think we need to give some advise to the browsers vendors on what they should implement to find turn servers




On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:



> Hi,

>

> Cullen Jennings wrote:

>>

>> I will note that browsers have many ways to learn about HTTP proxies from

>> the network and it seems to me that using some of theses same technique

>> might also be a good way to learn about TURN servers.

>

> I agree. I assume that in enterprises it would be the same people managing both of these.

>

> Is there something the IETF can or should do about this, or do we just assume it will happen? A new DHCP option is something the IETF could easily do, but I also doubt how usable that would be.

>

> Markus

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb





--20cf303bf958b364f404e75f8f88--

From juberti@google.com  Fri Sep 27 10:34:27 2013
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 0E09221E809F for ; Fri, 27 Sep 2013 10:34:27 -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=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHfWBHR50H40 for ; Fri, 27 Sep 2013 10:34:26 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77F21F9C90 for ; Fri, 27 Sep 2013 10:34:25 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so4634591iec.16 for ; Fri, 27 Sep 2013 10:34:25 -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; bh=OnT6h0KscoalD0wxkFFZ60XjA9KEeUBc4yEEHTjAT+I=; b=RSiItqPujg8wp5T8PolOw3EJxWd92lCGQsojaoK1tBn3yTXD31MK5lhrmt9WRo901m ufHkj3xDFsqZD2abcZWzH/Budc/BBkK1QE3KW0bRQ9v5h2phjRosI7JR8RP54GKpLpzh 8ANBQNtOR39+hHZ2PR5nvkTX40z388CK8CTGsOzKU1OrUXqe6y6xl6phUYOnsdPuw2sA 4ZYEVe20vbkUD7OIH6NyP5U5YqxlFSmOuzvdmhLcRyLwc8nx7FeM/kX8KKcIIcZ/swyV peEOZne41frHRAbm5z94niNiKmy6CAU2VxyhJPKds1Gwu+k70q9NLkqU1jlyE311bpls ZxMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OnT6h0KscoalD0wxkFFZ60XjA9KEeUBc4yEEHTjAT+I=; b=KBoQa1IGexPew50ZyyAC+QiPI2Mkmz9dKCD9/JUV5qO2nDjdGlqluMKUhJNJIT0hDC lzDl1VuwW/YX2xGUYcDRpi8YRDeqNr3o3+nVrNoUUnzO79Ia1rH26ZgwVrcgoqoMzb63 YPajZmmCy9nxPWQB4QEbZaPwUMe+0cKubENZVmc53oRAmfHmBt+F8OaGafIQKGcUbrJr 427EHZg7y1DlkJzbgHUWBaJkCrWlRMLd/n8oPpDKFfp4HGi+3dhSzRlIYpVsmp4BdUw8 lSr+KiVJC5efpPQZ9qgu5iXqNVL958694GVVrXEJnyegwznneAAEws0vgJn40Oelz9et kP7w==
X-Gm-Message-State: ALoCoQnJEAnb3s8UNNp9ZKGzLavvZ/Mck88w+tYe4pxKon+HI0CtgF7b0gFaAaFULTAfx9W0GFJiVM9uUJU0z5qYjxXTvoi6qe3CSYOuOagnAKGg4vYUlHxSDY13rmx3KzqFfYMgiaKvhWJlsGLA1of/Si1CjaVJ2DfaEVpDIH/qrnrp4EYFWM9T9VPFfFLQEYcVzGEpxDq6
X-Received: by 10.42.121.4 with SMTP id h4mr1593781icr.61.1380303265353; Fri, 27 Sep 2013 10:34:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 10:34:05 -0700 (PDT)
In-Reply-To: <523B7886.2080201@alvestrand.no>
References: <523AF421.7000807@alvestrand.no>  <523B7886.2080201@alvestrand.no>
From: Justin Uberti 
Date: Fri, 27 Sep 2013 10:34:05 -0700
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=20cf3010eb8fd077fb04e760e50c
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Nits and niggles
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, 27 Sep 2013 17:34:27 -0000

--20cf3010eb8fd077fb04e760e50c
Content-Type: text/plain; charset=UTF-8

Thanks for these comments. Agree with your suggestions, will fix in the
next version.


On Thu, Sep 19, 2013 at 3:19 PM, Harald Alvestrand wrote:

>  On 09/19/2013 10:55 PM, Suhas Nandakumar wrote:
>
>  Regarding a=ssrc comment above,
> The text from RFC5576 says this
>
>  Each "ssrc" media attribute specifies a single source-level attribute
>    for the given .  For each source mentioned in SDP, the
>    source-level attribute "cname", defined in Section 6.1 , MUST be
>    provided.  Any number of other source-level attributes for the source
>    MAY also be provided.
>
>  given the above, would it be cname attribute for a given ssrc that should be mandated at the minimum ?
>
>
> Thanks, that makes sense to me. Updating JSEP to say "add a line with
> a=ssrc cname=" sounds like something that does what we want and is
> consistent with 5576.
>
>
>  Cheers
>
> Suhas
>
>
>
> On Thu, Sep 19, 2013 at 5:54 AM, Harald Alvestrand wrote:
>
>> I'm sure we'll have lots of things to discuss about JSEP. I just thought
>> I'd get these out of the way.
>>
>> - Usage of MSID. In addition to the a=msid: lines, the session-level
>> generation procedure needs to say that a line "a=msid-semantic:WMS " is
>> added to the session-level description, containing the IDs of the
>> MediaStreams that are signalled.
>>
>> - a=ssrc lines. The spec (5.2.1 second list last bullet) simply says "an
>> a=ssrc line". But RFC 5576 specifies that all ssrc lines contain an
>> attribute. Suggestion: define one that does no harm (role=primary?)
>>
>> - recycling of m= lines. The section in 5.2.2 (subsequent offers) that
>> talks about this doesn't mention that the media in the m-line has to match,
>> although section 5.3.1 (initial answer) actually talks about it. I'm
>> assuming that's an oversight.
>>
>> I'd suggest pulling the language about "selecting an appropriate m-line
>> for a track" out in a separate subsection, so that we have one place to
>> point to for this.
>>
>> Out of time, let's get these ones out of the way for -05....
>>
>>
>>
>> _______________________________________________
>> 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
>
>

--20cf3010eb8fd077fb04e760e50c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for these comments. Agree with your suggestions, wi=
ll fix in the next version.


On Thu, Sep 19, 2013 at 3:19 PM, Harald Alvestrand <harald@alvestrand.no> wrote:




 =20
   =20
 =20
  

    
On 09/19/2013 10:55 PM, Suhas
      Nandakumar wrote:

    

    

      

        
Regarding a=3Dssrc comment above,

        The text from RFC5576 says this=C2=A0
        


        

        

          
Eac=
h "ssrc" media attribute specifies a single source-level attribut=
e
   for the given <ssrc-id>.  For each source mentioned in SDP, the
   source-level attribute "cname", defined in Section 6.1, =
MUST be
   provided.  Any number of other source-level attributes for the source
   MAY also be provided.

          

          

          
given the above, would it be cname a=
ttribute for a given ssrc that should be mandated at the minimum ?



        

      

    

    

    
Thanks, that makes sense to me. Updating JSE=
P to
      say "add a line with a=3Dssrc cname=3D<cname>" sounds=
 like
      something that does what we want and is consistent with 5576.<=
div class=3D"im">

    

      

        

          



          




          
Cheers

          
Suhas

          

          

        

      

      

        

        

        
On Thu, Sep 19, 2013 at 5:54 AM, Harald
          Alvestrand <harald@alvestrand.no>
          wrote:

          

            I'm sure we'll have lots of things to discuss about JSE=
P. I
            just thought I'd get these out of the way.

            

            - Usage of MSID. In addition to the a=3Dmsid: lines, the
            session-level generation procedure needs to say that a line
            "a=3Dmsid-semantic:WMS <id>" is added to the
            session-level description, containing the IDs of the
            MediaStreams that are signalled.

            

            - a=3Dssrc lines. The spec (5.2.1 second list last bullet)
            simply says "an a=3Dssrc line". But RFC 5576 specifie=
s that
            all ssrc lines contain an attribute. Suggestion: define one
            that does no harm (role=3Dprimary?)

            

            - recycling of m=3D lines. The section in 5.2.2 (subsequent
            offers) that talks about this doesn't mention that the medi=
a
            in the m-line has to match, although section 5.3.1 (initial
            answer) actually talks about it. I'm assuming that's an
            oversight.

            

            I'd suggest pulling the language about "selecting an
            appropriate m-line for a track" out in a separate
            subsection, so that we have one place to point to for this.

            

            Out of time, let's get these ones out of the way for -05...=
.

            

            

            

            _______________________________________________

            rtcweb mailing list

            rtcweb@iet=
f.org

            https://www.ietf.org/mailman/listinfo/rtcweb

          

        

        

      

    

    

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--20cf3010eb8fd077fb04e760e50c--

From juberti@google.com  Fri Sep 27 10:43:25 2013
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 724AD21E8097 for ; Fri, 27 Sep 2013 10:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level: 
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fOjV+kWcTao for ; Fri, 27 Sep 2013 10:43:24 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C5CFC11E8109 for ; Fri, 27 Sep 2013 10:43:24 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id x13so4752354ief.3 for ; Fri, 27 Sep 2013 10:43:23 -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; bh=Eu47r+dpNrBaGBDMO6HNc9adz8KUwfnA183g0Ws7N1c=; b=hineUJRUP6xQH9wSToVXP+cHkpSk4t3hfTBRmszdtterwYctXjouOEo1MS2ctf6ZPT Lwg4iuxQx3amW8vu3UXWlPEgRDyyQ/OEhyIcLXeA+DKvaWxFYARocWbUWHSVJDRjLWB6 TbQxHFFGPqO/fSc8Vrs+zwRnqeMSrRPV6wtJnZPqDIfVdaNszGRTmzJUPYPrw8nNLFGw EMAh0ZFMg4Du11Oi1HYj2il/fr1CzHwEsAqCORyRX5g9c3X8t8u1p7eGIQYoz5iS91Df HO7g396RBPwS592o6vNxuLeDOSFRM3KApGt4XovtaexzHllkt73TV5I0JL1UjjJJfh42 h39w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Eu47r+dpNrBaGBDMO6HNc9adz8KUwfnA183g0Ws7N1c=; b=nLmPPHzFQJPMhOCilaBgvOWmOcCOwgoigABjK+C2RjwntHbKbcpckvgM0a/ovpimJB l34X4gL6HJ2BgTFpx29GVXKFHoIM285Z+rs0APJ8HMe4x60Il6GEcaBbCn0AbAa/MVWz jWMfIIbm4Fi7eXWSjOddF1SleXgmXdvNhqddddyGnukN0XsYshECy5xJFjvvHxBI8TSO 8i/2hkPiorvngHiXLNRt5hQJ3fo0nGYaSdQgfos9N0IjJlxTz4XDF+BUgGfErh1y5ZyN 0pPM8DzeuL5wUdlTv8luE70VLWLBq1pBovhPaufwWVsCtyzpkjiOEMvM54nzDYydhgEJ mQpw==
X-Gm-Message-State: ALoCoQnw9IU3VWoJmsvWEt4Dd8b+mGKxUHt2NaDBOQPChmmYK5h+iyvuO+Lm/EcXXQsgNLWrk7Z+56lHCLXpTSc2LG5Ni8SjvkSjnD+bQ9hJ1xTwm5pyixAIuDDqFGii6ICxaZz+xgGgY5THIQYTgNuY+eCLjKYcoeBzZCltGTDigXPbpGzM/PDlCZDArl5EwAH+GisP3b56
X-Received: by 10.50.103.6 with SMTP id fs6mr3328837igb.16.1380303802103; Fri, 27 Sep 2013 10:43:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 10:43:02 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Fri, 27 Sep 2013 10:43:02 -0700
Message-ID: 
To: Michael Procter 
Content-Type: multipart/alternative; boundary=047d7b2e0abbce98b204e7610585
Cc: "" 
Subject: Re: [rtcweb] jsep-04 questions about phrasing
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, 27 Sep 2013 17:43:25 -0000

--047d7b2e0abbce98b204e7610585
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 19, 2013 at 8:40 AM, Michael Procter  wrote:

> Hi,
>
> Section 5.2.2 Subsequent Offers
>
> This section starts with the sentence "When createOffer is called a
> second (or later) time,".  As far as I can tell, the rest of this
> section applies both to subsequent offers created by the original
> offerer and also offers created by the original answerer.  In this
> second case, createOffer has never been called.  I would suggest
> something like "When createOffer is called after the initial
> offer/answer exchange,".
>

Good catch. There are states between the initial state and the completion
of the o/a exchange, so the text probably needs to be more along the lines
of
"When createOffer is called a second (or later) time, or called after a
local or remote description has been installed..."

Will try to wordsmith this a bit.


> Section 5.2.2 11th bullet:
>
>    o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
>       only include codecs present in the remote description.
>
> Is this necessary?  Can't we offer new codecs in a subsequent offer?
> RFC3264 Sec 8.3.2 permits new codecs to be offered, old ones to be
> removed etc, with the only constraint being to not reuse dynamic
> payload types.
>

Certainly, this is possible, but we probably want this to only happen when
explicitly requested by JS. For example, if a track is put on hold, I don't
think we want to renegotiate all codecs at that time. Hence the current
text.

If we do provide APIs for this, this behavior change would be covered in
the Constraints Handling section.


> Finally, the two example SDPs both contain "s=-" whereas section 5.2.1
> encourages "s= " instead. Personally, I prefer the hyphen, but
> consistency is probably more important.
>
> I prefer the hyphen too, since it better matches the o= line. Does anyone
feel strongly about this?

--047d7b2e0abbce98b204e7610585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Thu, Sep 19, 2013 at 8:40 AM, Michael Procter =
<michael@voip.co=
.uk> wrote:



Hi,



Section 5.2.2 Subsequent Offers



This section starts with the sentence "When createOffer is called a
second (or later) time,". =C2=A0As far as I can tell, the rest of this=


section applies both to subsequent offers created by the original

offerer and also offers created by the original answerer. =C2=A0In this

second case, createOffer has never been called. =C2=A0I would suggest

something like "When createOffer is called after the initial

offer/answer exchange,".

Good catc=
h. There are states between the initial state and the completion of the o/a=
 exchange, so the text probably needs to be more along the lines of



"When createOffer is called a second (or later) time, or called a=
fter a local or remote description has been installed..."=C2=A0
<=
div>
Will try to wordsmith this a bit.






Section 5.2.2 11th bullet:



=C2=A0 =C2=A0o =C2=A0The m=3D line and corresponding "a=3Drtpmap"=
 and "a=3Dfmtp" lines MUST

=C2=A0 =C2=A0 =C2=A0 only include codecs present in the remote description.=




Is this necessary? =C2=A0Can't we offer new codecs in a subsequent offe=
r?

RFC3264 Sec 8.3.2 permits new codecs to be offered, old ones to be

removed etc, with the only constraint being to not reuse dynamic

payload types.

Certainly, this is possi=
ble, but we probably want this to only happen when explicitly requested by =
JS. For example, if a track is put on hold, I don't think we want to re=
negotiate all codecs at that time. Hence the current text.




If we do provide APIs for this, this behavior change wo=
uld be covered in the Constraints Handling section.






Finally, the two example SDPs both contain "s=3D-" whereas sectio=
n 5.2.1

encourages "s=3D " instead. Personally, I prefer the hyphen, but<=
br>
consistency is probably more important.


I prefer the hyphen too, since it better matches the =
o=3D line. Does anyone feel strongly about this?
=C2=A0


--047d7b2e0abbce98b204e7610585--

From karl.stahl@intertex.se  Fri Sep 27 10:47:20 2013
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 00B1711E80E9 for ; Fri, 27 Sep 2013 10:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level: 
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd4aJJUuPx27 for ; Fri, 27 Sep 2013 10:47:16 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 769E911E8110 for ; Fri, 27 Sep 2013 10:47:12 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309271947099401; Fri, 27 Sep 2013 19:47:09 +0200
From: "Karl Stahl" 
To: "'cb.list6'" 
References: 	<523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>				<52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com> 
In-Reply-To: 
Date: Fri, 27 Sep 2013 19:47:08 +0200
Message-ID: <0ec201cebba9$96a69610$c3f3c230$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EC3_01CEBBBA.5A2F6610"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac67DPVQj2/HwXRYTsWQ0CdStwhdkAAmqkIA
Content-Language: sv
Cc: fluffy@cisco.com, rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 27 Sep 2013 17:47:20 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0EC3_01CEBBBA.5A2F6610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Does your mobile provider currently do reverse dns for your mobile's =
real
ip address?

>CB

Good question and the answer is good: Yes

We just checked both major 3G mobile operators TeleaSonera and Tele2 in
Sweden.

E.g. just surfing  to http://whatismyipaddress.com=20

(which tells me it is TeliaSonera, Wireless Broadband)

Then clicking the =93Additional IP Details=94 button, I get the PTR =
record:

host-95-199-196-65.mobileonline.telia.com

Tele2 gave: m83-186-15-99.cust.tele2.se

=20

So, obviously mobile providers have ways of provisioning these kind of
things in DNS.

=20

How does it look in other places of the world?

=20

/Karl

=20

=20

Fr=E5n: cb.list6 [mailto:cb.list6@gmail.com]=20
Skickat: den 27 september 2013 01:06
Till: Karl Stahl
Kopia: fluffy@cisco.com; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org;
Markus.Isomaki@nokia.com
=C4mne: Re: SV: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

=20


On Sep 26, 2013 8:27 AM, "Karl Stahl"  wrote:
>
> Here comes the suggestion I got from my developer that would allow a
network
> provider to offer his TURN server for the WebRTC browser to use. This
would
> require NO new DHCP-options or similar, and NO OS changes (I do =
realize
> those should be avoided if possible...).
>
> The idea is still, that whoever is responsible for giving a device an =
IP
> address (the network provider or a LAN administrator) can also =
announce a
> TURN server for the WebRTC browser to use.
>
> The suggestion is to use RFC6763 (DNS-Based Service Discovery, see =
chapter
> 11) where the network provider (the owner of the IP address) has set =
up a
> DNS PTR record for the TURN server in the in-addr.arpa domain.
>
> If the device got IP 173.164.252.149, then make a query for the PTR =
record
> for:
> _turn._udp.149.252.164.173.in-addr.arpa.
> Then the SRV record would return the actual address to the TURN server
(and
> you may find several for load balancing and failover I guess)
>
> If the device is on a LAN, the IP 173.164.252.149 to query would be =
the
WAN
> IP you get via STUN in the ICE process. But if the LAN administrator
> provides a local TURN server, then he also should have blocked STUN in =
the
> firewall, and the browser should query the device's local host address =
(as
> in the ICE procedure) and the local LAN DNS server should answer the =
query
> to give the local TURN server address on the LAN.
>
> Shouldn't this work to allow network provider to offer his TURN server
> "automatically and generally"?
>
> And wouldn't this work nicely for mobile devices, whenever the device =
is
on
> a "WebRTC-ready access" (actually good for everything using ICE), =
whether
> fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
> provider hopefully offers a prioritized pipe there as one usage of =
this
> mechanism).
>

Does your mobile provider currently do reverse dns for your mobile's =
real ip
address?

CB

> Not to slow down every call setup by doing this in the ICE process, I
guess
> this could be done when starting the browser and when the device gets =
a
new
> IP address, to have the TURN server address ready for later use.
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r
> Markus.Isomaki@nokia.com
> Skickat: den 26 september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia: rtcweb@ietf.org
> =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> draft-ietf-rtcweb-use-cases-and-requirements-11
>
> Hi,
>
> Cullen Jennings wrote:
> >
> > I will note that browsers have many ways to learn about HTTP proxies
> > from the network and it seems to me that using some of theses same
> > technique might also be a good way to learn about TURN servers.
> >
>
> I agree. I assume that in enterprises it would be the same people =
managing
> both of these.
>
> Is there something the IETF can or should do about this, or do we just
> assume it will happen? A new DHCP option is something the IETF could
easily
> do, but I also doubt how usable that would be.
>
> Markus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


------=_NextPart_000_0EC3_01CEBBBA.5A2F6610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


&g=
t; Does your mobile provider currently do =
reverse dns for your mobile's real ip =
address?
>CB
Go=
od question and the answer is good: Yes
We=
 just checked both major 3G mobile operators TeleaSonera and Tele2 in =
Sweden.
E.=
g. just surfing =A0to http://whatismyipaddress.com =

(w=
hich tells me it is TeliaSonera, Wireless =
Broadband)
Th=
en clicking the “Additional IP Details” button, I get the =
PTR record:
ho=
st-95-199-196-65.mobileonline.telia.com
Te=
le2 gave: m83-186-15-99.cust.tele2.se
 
So=
, obviously mobile providers have ways of provisioning these kind of =
things in DNS.
 
Ho=
w does it look in other places of the world?
 
/K=
arl
 
 
Fr=E5n: cb.list6 =
[mailto:cb.list6@gmail.com] 
Skickat: den 27 september 2013 =
01:06
Till: Karl Stahl
Kopia: fluffy@cisco.com; =
rtcweb@ietf.org; =
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; =
Markus.Isomaki@nokia.com
=C4mne: Re: SV: [rtcweb] TURN server =
address via DHCP, WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
 

On Sep 26, 2013 8:27 =
AM, "Karl Stahl" <karl.stahl@intertex.se> =
wrote:
>
> Here comes the suggestion I got from my developer =
that would allow a network
> provider to offer his TURN server for =
the WebRTC browser to use. This would
> require NO new =
DHCP-options or similar, and NO OS changes (I do realize
> those =
should be avoided if possible...).
>
> The idea is still, =
that whoever is responsible for giving a device an IP
> address =
(the network provider or a LAN administrator) can also announce =
a
> TURN server for the WebRTC browser to use.
>
> The =
suggestion is to use RFC6763 (DNS-Based Service Discovery, see =
chapter
> 11) where the network provider (the owner of the IP =
address) has set up a
> DNS PTR record for the TURN server in the =
in-addr.arpa domain.
>
> If the device got IP =
173.164.252.149, then make a query for the PTR record
> =
for:
> _turn._udp.149.252.164.173.in-addr.arpa.
> Then the =
SRV record would return the actual address to the TURN server =
(and
> you may find several for load balancing and failover I =
guess)
>
> If the device is on a LAN, the IP 173.164.252.149 =
to query would be the WAN
> IP you get via STUN in the ICE =
process. But if the LAN administrator
> provides a local TURN =
server, then he also should have blocked STUN in the
> firewall, =
and the browser should query the device's local host address (as
> =
in the ICE procedure) and the local LAN DNS server should answer the =
query
> to give the local TURN server address on the =
LAN.
>
> Shouldn't this work to allow network provider to =
offer his TURN server
> "automatically and =
generally"?
>
> And wouldn't this work nicely for =
mobile devices, whenever the device is on
> a "WebRTC-ready =
access" (actually good for everything using ICE), whether
> =
fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the =
network
> provider hopefully offers a prioritized pipe there as =
one usage of this
> mechanism).
>
Does your =
mobile provider currently do reverse dns for your mobile's real ip =
address?
CB
> Not to slow down =
every call setup by doing this in the ICE process, I guess
> this =
could be done when starting the browser and when the device gets a =
new
> IP address, to have the TURN server address ready for later =
use.
>
> /Karl
>
>
> -----Ursprungligt =
meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org =
[mailto:rtcweb-bounces@ietf.org] =
F=F6r
> Markus.Isomaki@nokia.com
=
> Skickat: den 26 september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia: =
rtcweb@ietf.org
> =C4mne: =
Re: [rtcweb] TURN server address via DHCP, WGLC of
> =
draft-ietf-rtcweb-use-cases-and-requirements-11
>
> =
Hi,
>
> Cullen Jennings wrote:
> >
> > I =
will note that browsers have many ways to learn about HTTP =
proxies
> > from the network and it seems to me that using some =
of theses same
> > technique might also be a good way to learn =
about TURN servers.
> >
>
> I agree. I assume that =
in enterprises it would be the same people managing
> both of =
these.
>
> Is there something the IETF can or should do =
about this, or do we just
> assume it will happen? A new DHCP =
option is something the IETF could easily
> do, but I also doubt =
how usable that would be.
>
> Markus
> =
_______________________________________________
> rtcweb mailing =
list
> rtcweb@ietf.org
> https://www.ietf.or=
g/mailman/listinfo/rtcweb
>

------=_NextPart_000_0EC3_01CEBBBA.5A2F6610--


From juberti@google.com  Fri Sep 27 10:50:33 2013
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 0295421F9C8B for ; Fri, 27 Sep 2013 10:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.565
X-Spam-Level: 
X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vVSjrs+LL-j for ; Fri, 27 Sep 2013 10:50:32 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42C21F9C28 for ; Fri, 27 Sep 2013 10:50:32 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id u16so4595699iet.5 for ; Fri, 27 Sep 2013 10:50:31 -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; bh=pVk9ch4TT4OBZWP/sqCOsjdb+M4VmnmDwVxLstClHvw=; b=j/BADRKmu7QU3eEh9rT6KmMbVE7+JxGNsjA/e+rVj+otaXAd38EzNFPSQcjNZrk2+1 5+87LzAGZ3TUnvyEnMD8oN/wE74RVvYTvD/aX9uKkuJ6mf2seT2MI+fskRbKUkCjOQ61 axqzdcCGbgR1m0WTzM5WP/G+JrGFjHR0NYFwG3vy034i/JVs+FjUp4EZIVfqGwVu5lSr zB09ieuin00o+pMhEt1hISDbpLVhsMlVgNxHMr7/kyToJrA+fNImcDWgADaByYiHJKIQ ERgA9u3dO+3dTfyPcZqxPYc+GfknAT9/dYJhkLzZw3NJui89x3sJmo+sVItpeP+yW0qC uyhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pVk9ch4TT4OBZWP/sqCOsjdb+M4VmnmDwVxLstClHvw=; b=NVKy+cD9IbBQAi4DOAWJciUV/RqLrPja7G8+v8GqdpeRqGli6ZNdtChYHI4PTQWFe5 GypR3/6wwgRAvVff4AmS9K7zqs/3BpTOWBq2v7+3YW0H5V2ZsibleDYz/m87NMQZChBc x2GUVzfvhA3gh11yCWcl6y38W+lbGwmvIYklYEgUK+a2a8fXTjyzfDIK6D5IAyot9WCl JvRvUk9dvOUuyr4/84Q297n2AUZFUN3u8mlDp9Md8wx/4MwkIEMof5KKB73iHlD0Ewk1 NIA9yTVFfqj2554qC+i0g6Y2ME5gEWBsO0zn5XmxHz+8bECPztxfZHnBMYlRVQgwgn3Y vPxQ==
X-Gm-Message-State: ALoCoQlFd1DvMfZ9+7NCLaQ4mhR9OqcYkSCFV76Nu6/weFlodK84EzFdjJqwqbfUCitH/Uk5um613V13Enb4wBfvGUBvdnSGN8bdWM5dXNuIBDzcihsBMS/pR7DItPl13Q8uZ/5BQ5/GLrU0AjxkxCCkB2jxKx4K0mqkLri4XQ5s2d9c2W+5kWceDN6VeJYfhF6LAQBpUFzQ
X-Received: by 10.50.73.41 with SMTP id i9mr3342157igv.30.1380304231432; Fri, 27 Sep 2013 10:50:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 10:50:11 -0700 (PDT)
In-Reply-To: 
References: <523BE4DB.5030800@ericsson.com> <523BF860.1090105@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se> 
From: Justin Uberti 
Date: Fri, 27 Sep 2013 10:50:11 -0700
Message-ID: 
To: Matt Fredrickson 
Content-Type: multipart/alternative; boundary=089e013a027065a82404e7611f9e
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
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, 27 Sep 2013 17:50:33 -0000

--089e013a027065a82404e7611f9e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Since we have a clear path forward for a signaling-plane mechanism for
these features, I think we should proceed on this path.

If it eventually turns out that this path does not provide good enough
performance in certain situations, we can look into a media-plane mechanism
as an alternative.


On Tue, Sep 24, 2013 at 8:58 AM, Matt Fredrickson wrote=
:

> I tend also to agree with this.  Maybe I'm completely off, but it would
> seem that pause and resume might be done using some semi-inband media
> related path, perhaps like RTCP or something like that.  I'm not sure whe=
re
> to fit resolution in though...
>
> Matthew Fredrickson
> Digium, Inc.
>
>
> On Fri, Sep 20, 2013 at 5:57 AM, Stefan H=C3=A5kansson LK <
> stefan.lk.hakansson@ericsson.com> wrote:
>
>> On 2013-09-20 09:25, Harald Alvestrand wrote:
>> > On 09/20/2013 08:02 AM, Magnus Westerlund wrote:
>> >> WG,
>> >>
>> >> In the JSEP call I commented regarding a=3Dimageattr open issue that =
we
>> >> had an original agreement from over a year ago (Vancouver) to go with
>> >> Harald's proposal in then
>> >> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt
>> >>
>> >> This is documented in the minutes:
>> >> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb
>> >>
>> >>
>> >> However, I did forget to note that there has been discussion on this
>> >> issue after that between Harald Alvestrand and Stefan H=C3=A5kansson
>> >> primarily on the W3C list
>> >>
>> >> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html
>> >>
>> >> Where they are seriously discussing only using WebRTC API for this.
>> >>
>> >> It is in the context of
>> >>
>> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution=
/
>> >>
>> >> Thus I would like to point out that there appear to be some indicatio=
n
>> >> of desire move away from the consensus last year.
>> >
>> > My thinking is that there are 3 points on the spectrum of solutions:
>> >
>> > - Constraints at source only (the approach most thoroughly described i=
n
>> > draft-alvestrand-constraints-resolution).
>> >
>> > - Constraints at destination can be sigalled in SDP, and acted on at
>> > source (described in draft-alvestrand-rtcweb-resolution). This spec
>> > could not be pursued as long as the "Plan X" discussions were still
>> > unsettled, but now it should really be "a piece of cake".
>>
>> My personal view is still that SDP is the wrong level for carrying this
>> kind of signaling (resolution, and perhaps further down the road
>> pause/resume related signaling). Each update requires an O/A, and locks
>> out other changes to the session. And since the SDPs must be handled by
>> the application (that is responsible for sending them over and applying
>> them) I wonder if there is any advantage compared to just having an API
>> on the sending side. If the receiving application wants another
>> resolution sent, it could just tell the sending application so, rather
>> than going through a createOffer/setLocal/ send-offer
>> /receive-answer/setRemote cycle.
>>
>> >
>> > - Defining a new way of signalling. This was the approach rejected in
>> > Vancouver.
>> >
>> > Formalistically, if the IETF decides to offer a well defined mechanism
>> > for negotiating resolution through SDP, the W3C will certainly take up
>> > the discussion on whether or not we should connect the API to that
>> > functionality.
>> >
>> > Happy to discuss more.
>> >
>> > _______________________________________________
>> > 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
>
>

--089e013a027065a82404e7611f9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Since we have a clear path forward for a signaling-plane m=
echanism for these features, I think we should proceed on this path.=C2=A0<=
div>
If it eventually turns out that this path does not provi=
de good enough performance in certain situations, we can look into a media-=
plane mechanism as an alternative.





On Tue,=
 Sep 24, 2013 at 8:58 AM, Matt Fredrickson <creslin@digium.com> wrote:



I tend also to agree with t=
his. =C2=A0Maybe I'm completely off, but it would seem that pause and r=
esume might be done using some semi-inband media related path, perhaps like=
 RTCP or something like that. =C2=A0I'm not sure where to fit resolutio=
n in though...




Matthew Fredrickson
Digium, Inc.


On Fri, Sep 20, 2013 at 5:57 AM, Stefan H=C3=A5kansson=
 LK <stefan.lk.hakansson@ericsson.com> wrote:=





On 2013-09-20 09:25, Harald Alvest=
rand wrote:

> On 09/20/2013 08:02 AM, Magnus Westerlund wrote:

>> WG,

>>

>> In the JSEP call I commented regarding a=3Dimageattr open issue th=
at we

>> had an original agreement from over a year ago (Vancouver) to go w=
ith

>> Harald's proposal in then

>> http://tools.ietf.org/id/draft-alvestrand-rt=
cweb-resolution-00.txt

>>

>> This is documented in the minutes:

>> http://www.ietf.org/proceedings/84/minutes/minutes=
-84-rtcweb

>>

>>

>> However, I did forget to note that there has been discussion on th=
is

>> issue after that between Harald Alvestrand and Stefan H=C3=A5kanss=
on

>> primarily on the W3C list

>>

>> http://lists.w3.org/Archives/Public/public-=
webrtc/2013Aug/0051.html

>>

>> Where they are seriously discussing only using WebRTC API for this=
.

>>

>> It is in the context of

>> https://datatracker.ietf.org/doc/draf=
t-alvestrand-constraints-resolution/

>>

>> Thus I would like to point out that there appear to be some indica=
tion

>> of desire move away from the consensus last year.

>

> My thinking is that there are 3 points on the spectrum of solutions:
>

> - Constraints at source only (the approach most thoroughly described i=
n

> draft-alvestrand-constraints-resolution).

>

> - Constraints at destination can be sigalled in SDP, and acted on at
> source (described in draft-alvestrand-rtcweb-resolution). This spec
> could not be pursued as long as the "Plan X" discussions wer=
e still

> unsettled, but now it should really be "a piece of cake".



My personal view is still that SDP is the wrong level for carry=
ing this

kind of signaling (resolution, and perhaps further down the road

pause/resume related signaling). Each update requires an O/A, and locks

out other changes to the session. And since the SDPs must be handled by

the application (that is responsible for sending them over and applying

them) I wonder if there is any advantage compared to just having an API

on the sending side. If the receiving application wants another

resolution sent, it could just tell the sending application so, rather

than going through a createOffer/setLocal/ send-offer

/receive-answer/setRemote cycle.




>

> - Defining a new way of signalling. This was the approach rejected in<=
br>
> Vancouver.

>

> Formalistically, if the IETF decides to offer a well defined mechanism=


> for negotiating resolution through SDP, the W3C will certainly take up=


> the discussion on whether or not we should connect the API to that

> functionality.

>

> Happy to discuss more.

>

> _______________________________________________

> 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





--089e013a027065a82404e7611f9e--

From juberti@google.com  Fri Sep 27 11:02:10 2013
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 C036621F9DCE for ; Fri, 27 Sep 2013 11:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level: 
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYzpcj-j0ME1 for ; Fri, 27 Sep 2013 11:02:09 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6F98221F9E88 for ; Fri, 27 Sep 2013 11:02:09 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id tp5so4684901ieb.40 for ; Fri, 27 Sep 2013 11:02:08 -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; bh=8YJSS5rWHQoNjlfDYbixwElHTYijM8wfWikJQ5NAZJM=; b=dAXOkhSHqrbCYrMVbZS83lgh6/VTGaJmutoeH9jxUl2t3p1meGAuWTkGKdj+Ve+gae jR13MihnHyhM8v1dbdN8CVNz7EWsu/62V9Wi0/wo/pTLpro76OCVHsxnLwRwcBLs5fVM y2RmxEkesSsJr2ZIl6+OeFWEzq5by8dq5mu9XfK1oto8tG3cudKrmbRwWbWzHAvVjce4 wmDSlpBJJkZdeXtJp7WVIn7viZqP4ei8IVabeQlLrnIm++QWN2+rc0naoyYQSQ/lxOMM +BgeneGHdSdaXpiJIkwpbWhog988RKXWiplE6xgYw6bN3M2/hAGEPofjVQmjItjQeslh YZjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8YJSS5rWHQoNjlfDYbixwElHTYijM8wfWikJQ5NAZJM=; b=YEfStCneWIHILgjupwiBN68165PzgyKTvmbvktVT4elLx7ujeHm28Agh6ZTuXcpDtq 9Iel3zjGQRY/b432AIFTnJI70u1TVGmUy34TbH6OAYeHrLjwwoNWIfjBljPjIC0AGeFH 8Ww6LSmghn1VRMbPtfN2KrcQqXGd49pA0zH0BZgeQuxKV14ltGE8EC6Cm6hfKVTW5E4K eVrKiSF2h+RmM1d+k5/imvI5JsP+x3QEEPuAuG7nwderSUYx5jjCcB94GkEZSz+KWFwA bG0QuSJqis5P+39Sbwm03pGDfhFNl8xLa1SlxWQj8AafTsPhOaX7SkYOJubI348/qn9K wSMA==
X-Gm-Message-State: ALoCoQmfThDAYXTVdZAHMJIAEoQNO/YTOH2iwlKcF8Vp5vBazdLNXWd6XTXxBaa/PYEolfR3D5D1RFDtdOiMxcQSnTjyydKQkj5zJp7Fq1MH4U+W+9lThVugyFJeumSA9K8TwnWEf3hO2huDqLevjRMOLr5LLz4clC5iJdeCsE76yvm1OtjiYjGjfJY8AvfRiMaTKP0GaR0s
X-Received: by 10.50.73.41 with SMTP id i9mr3386740igv.30.1380304928443; Fri, 27 Sep 2013 11:02:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 11:01:48 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> 
From: Justin Uberti 
Date: Fri, 27 Sep 2013 11:01:48 -0700
Message-ID: 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=089e013a0270f1255b04e761481b
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 27 Sep 2013 18:02:10 -0000

--089e013a0270f1255b04e761481b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 20, 2013 at 11:22 AM, Cullen Jennings (fluffy)  wrote:

>
> Good points - proposed resolutions inline =E2=80=A6
>
> On Sep 19, 2013, at 3:08 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> > Hi,
> >
> > Section 5.2.1:
> > -----------------
> >
> > Q_1:      o- line  initial value - deviation
> >
> > What is the reason for recommending a  zero value in the
> initial Offer, when the RFC says SHOULD use an NTP format timestamp?
> >
> > I don=E2=80=99t have any strong feelings, but in general: whenever we d=
eviate
> from the =E2=80=9Cbase=E2=80=9D SDP procedures I think we should justify =
why.
>
> Lets use NTP
>

It's not necessary to use NTP, since the session-id is already random.
Starting the session id at zero makes it easier for developers see the
changes to the session id. I can spell this out in the next version of the
document.


> >
> >
> > Q_2:      o- line  initial value - forking
> >
> > When a new PeerConnection is created due to forking, the 
> value must be based (incremented) on the value associated with the =E2=80=
=9Cmother=E2=80=9D
> PeerConnection, for which the initial Offer of the whole communication
> session was created.
>
>
> uh, that is old text sorry. I'm proposing the principal that any time the
> SDP changes (including new candidate lines) the version gets larger.
>

agree

>
> >
> >
> > Q_3:      RTP
> >
> > The text says:
> >
> > =E2=80=9CThe  field MUST be set to "RTP/SAVPF". =E2=80=9C
> >
> > But, that of course only applies to RTP based streams (not the data
> channel). Also, in general, it needs to be clear what information needs t=
o
> be in every m- line, and what information is protocol specific. I would
> suggest to have a =E2=80=9CGeneral=E2=80=9D sub-section, a =E2=80=9CRTP=
=E2=80=9D sub-section, etc.
>
> Yep - I think this should be offers are created with RTP/SAVPF for audio
> and video and system can reeve offers with SAVPF or SAVP
>

Currently the document specifies what to do with media lines, with later
discussion of handling the SCTP line. Do you think the current information
is not sufficiently descriptive?

> >
> >
> > Q_4:      BUNDLE
> >
> > The text says:
> >
> > =E2=80=9CIf a m=3D section is not being bundled into another m=3D secti=
on, it MUST
> >                generate a unique set of ICE credentials and gather its
> own set of
> >                candidates.  Otherwise, it MUST use the same ICE
> credentials and
> >                candidates that were used in the m=3D section that it is
> being bundled
> >                into.=E2=80=9D
> >
> > As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?
>
> no the initial offer will not have identical stuff other than on lines
> that "bundle-only" and we still need to add more text on this but idea is
> to make just like what is in united-plan


> >
> > I don=E2=80=99t object to that =E2=80=93 I just want to clarify, as it =
has impacts on
> the text in the BUNDLE spec :)
>

I'm not sure what the exact concern is here - I just put this here to be
clear about the exact processing needed, since the BUNDLE draft is also a
moving target.

> >
> >
> > Section 5.2.2:
> > -----------------
> >
> >
> > Q_5:      Offer when in =E2=80=9Clocal-offer=E2=80=9D
> >
> > The text says:
> >
> > =E2=80=9CIf the initial offer was applied using setLocalDescription, bu=
t an
> >                answer from the remote side has not yet been applied,
> meaning the
> >                PeerConnection is still in the "local-offer" state, the
> steps for
> >                generating an initial offer should be followed,=E2=80=9D
> >
> > I don=E2=80=99t understand this. Why would you create a new Offer while=
 you are
> waiting for an Answer to the previously sent Offer?
>
> Justin has asked for this in the case when the offer has not been sent to
> anyone else. This is not going to be useful for typical systems trying to
> have SIP or Jingle compatible flow but who knows =E2=80=A6
>

It's possible that the initial offer is never sent, because you just want
to set it to warm up the stack. So you can update the offer without any
consequences.

>
> >
> > Also, when setRemote() is called, to which Offer does it apply?
>
> The most recent one. And the JS app would have to make sure it passed the
> write one or you run high odds of getting completely broken behavior.
>

exactly. This will be spelled out in setRemote processing.

>
> >
> >
> > Q_6:      BUNDLE
> >
> > We=E2=80=99ll probably also need some text about BUNDLE.
> >
>
> yep - but plan is to match up with unified plan
>

Can you be specific about what more you think needs to be said? The
createAnswer treatment of BUNDLE is one clear thing that is currently
missing.

>
> >
> > Regards,
> >
> > Christer
> >
> > _______________________________________________
> > 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
>

--089e013a0270f1255b04e761481b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Sep 20, 2013 at 11:22 AM, Cullen Jennings (fluffy) <fluffy@=
cisco.com> wrote:





Good points - proposed resolutions inline =E2=80=A6




On Sep 19, 2013, at 3:08 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:



> Hi,

>

> Section 5.2.1:

> -----------------

>

> Q_1: =C2=A0 =C2=A0 =C2=A0o- line <sess-version> initial value - =
deviation

>

> What is the reason for recommending a <sess-version> zero value =
in the initial Offer, when the RFC says SHOULD use an NTP format timestamp?=


>

> I don=E2=80=99t have any strong feelings, but in general: whenever we =
deviate from the =E2=80=9Cbase=E2=80=9D SDP procedures I think we should ju=
stify why.




Lets use NTP

It's not necessa=
ry to use NTP, since the session-id is already random. Starting the session=
 id at zero makes it easier for developers see the changes to the session i=
d. I can spell this out in the next version of the document.








>

>

> Q_2: =C2=A0 =C2=A0 =C2=A0o- line <sess-version> initial value - =
forking

>

> When a new PeerConnection is created due to forking, the <sess-vers=
ion> value must be based (incremented) on the value associated with the =
=E2=80=9Cmother=E2=80=9D PeerConnection, for which the initial Offer of the=
 whole communication session was created.








uh, that is old text sorry. I'm proposing the principal that any =
time the SDP changes (including new candidate lines) the version gets large=
r.

agree=C2=A0






>

>

> Q_3: =C2=A0 =C2=A0 =C2=A0RTP

>

> The text says:

>

> =E2=80=9CThe <proto> field MUST be set to "RTP/SAVPF".=
 =E2=80=9C

>

> But, that of course only applies to RTP based streams (not the data ch=
annel). Also, in general, it needs to be clear what information needs to be=
 in every m- line, and what information is protocol specific. I would sugge=
st to have a =E2=80=9CGeneral=E2=80=9D sub-section, a =E2=80=9CRTP=E2=80=9D=
 sub-section, etc.






Yep - I think this should be offers are created with RTP/SAVPF for au=
dio and video and system can reeve offers with SAVPF or SAVP

Currently the document specifies what to do with medi=
a lines, with later discussion of handling the SCTP line. Do you think the =
current information is not sufficiently descriptive?=C2=A0





>

>

> Q_4: =C2=A0 =C2=A0 =C2=A0BUNDLE

>

> The text says:

>

> =E2=80=9CIf a m=3D section is not being bundled into another m=3D sect=
ion, it MUST

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate a uniq=
ue set of ICE credentials and gather its own set of

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates. =C2=
=A0Otherwise, it MUST use the same ICE credentials and

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates that=
 were used in the m=3D section that it is being bundled

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into.=E2=80=9D<=
br>
>

> As, when BUNDLE is used, the initial Offer will contain identical ICE =
candidates, does that mean that we will also include identical address info=
rmation in the initial Offer?




no the initial offer will not have identical stuff other than on line=
s that "bundle-only" and we still need to add more text on this b=
ut idea is to make just like what is in united-plan=C2=A0






>

> I don=E2=80=99t object to that =E2=80=93 I just want to clarify, as it=
 has impacts on the text in the BUNDLE spec :)
<=
br>
I'm not sure what the exact concern is here - I just put =
this here to be clear about the exact processing needed, since the BUNDLE d=
raft is also a moving target.=C2=A0




>

>

> Section 5.2.2:

> -----------------

>

>

> Q_5: =C2=A0 =C2=A0 =C2=A0Offer when in =E2=80=9Clocal-offer=E2=80=9D
>

> The text says:

>

> =E2=80=9CIf the initial offer was applied using setLocalDescription, b=
ut an

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0answer from the=
 remote side has not yet been applied, meaning the

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PeerConnection =
is still in the "local-offer" state, the steps for

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generating an i=
nitial offer should be followed,=E2=80=9D

>

> I don=E2=80=99t understand this. Why would you create a new Offer whil=
e you are waiting for an Answer to the previously sent Offer?




Justin has asked for this in the case when the offer has not been sen=
t to anyone else. This is not going to be useful for typical systems trying=
 to have SIP or Jingle compatible flow but who knows =E2=80=A6




It's possible that the initial offer is never sent,=
 because you just want to set it to warm up the stack. So you can update th=
e offer without any consequences.=C2=A0






>

> Also, when setRemote() is called, to which Offer does it apply?




The most recent one. And the JS app would have to make sure it passed=
 the write one or you run high odds of getting completely broken behavior.<=
br>

exactly. This will be spelled out in se=
tRemote processing.=C2=A0







>

>

> Q_6: =C2=A0 =C2=A0 =C2=A0BUNDLE

>

> We=E2=80=99ll probably also need some text about BUNDLE.

>




yep - but plan is to match up with unified plan
=

Can you be specific about what more you think needs to be sa=
id? The createAnswer treatment of BUNDLE is one clear thing that is current=
ly missing.







>

> Regards,

>

> Christer

>

> _______________________________________________

> 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





--089e013a0270f1255b04e761481b--

From juberti@google.com  Fri Sep 27 11:03:29 2013
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 A5A0721F9EC8 for ; Fri, 27 Sep 2013 11:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Level: 
X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxmiXcL2Icdv for ; Fri, 27 Sep 2013 11:03:28 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D87C821F9F86 for ; Fri, 27 Sep 2013 11:03:24 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id e14so4816519iej.10 for ; Fri, 27 Sep 2013 11:03:24 -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; bh=+EO87Dx5WVGz20LGtjDFMssS1mJ8b89+3gbcbkQVYqo=; b=Hba9XZbLmJFDRYyArNrLd/1DcH5Af7kIJwckHRmVstn+mJfpoMzmuzopz6NXgecy3x qIZI3kPlcm8WyyVpJKoOGDUDiIqfA4Pxa+pNUSWuQ4vpPMwEkaqeMpP9gN3lnCr+T7X3 0LaoQNj3WJ8YBcm270i2CMyJt7Pw2WNE2+kDGDbM2UcXQ9sNnc8ZH1MirwmHaos4/lNp Mc/Kxq6GrldDTiAY72iNxUbwZL+TeVZzXFtVpKZ4e0YfyWUs+omiROrHy+Wg2uaJY6rh lOKNNqZKGWFvbz0h7nNOPi/IMafWbZsl8Ui7ywyN0A7ahUG1DPvofcXuWvAcxhOv4AZc bYjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+EO87Dx5WVGz20LGtjDFMssS1mJ8b89+3gbcbkQVYqo=; b=Be9BnDgF/nLSkK/3EvX0EfMPLl5Wg7iALUscEVYUZ/42dc46y2Tr7sEPRcO+uhxrdL 0uz10HbhRQ9A56sJ117tu603KaHSq0NzC8Yfi5OF++qOzZ3R5ZnYMC+rOq0AH1Q9qGnG lShQdNtnGunweYgX8FBTWbj75OjRwjHyregnbh5rFBpW38AJifS2PmA1OaBY5HbzhzsH q8gOmwUIas8loubOCpEcPA2tTNnERCh/0LrRraonjUu+zTrhmFRpuxxucVf5Y9zobAeD sHFPrx6Zzb7nAbYBpWAFRh5Vih1tQVq6FLuYH4cMtYFD0hrUg35uLglJ2MK0zZnrRb5X YdGw==
X-Gm-Message-State: ALoCoQm5C6p41g+kliuZxtVyRy11c6aIqKvIBykwMpi514tYsAbhQvznyACFUvjssxk3B/JoDrvQS21i8XU9KRfOF/Vaprjf6T+kiTAuLgtXpSSDuktPuTDdUjZKv4SMEhqoTBsefieM/1fDqmJJECkVItR9EAj4kgpsS/xXdQNRsQswTGARhQQH/x8G9FTbLUxHn6yChc5b
X-Received: by 10.42.60.18 with SMTP id o18mr1177538ich.83.1380305004342; Fri, 27 Sep 2013 11:03:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 11:03:04 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A8EA4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4A8EA4@ESESSMB209.ericsson.se>
From: Justin Uberti 
Date: Fri, 27 Sep 2013 11:03:04 -0700
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=90e6ba25dbdd77528804e7614da0
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 27 Sep 2013 18:03:29 -0000

--90e6ba25dbdd77528804e7614da0
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 20, 2013 at 3:17 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Cullen,
>
> >> Q_2:      o- line  initial value - forking
> >>
> >> When a new PeerConnection is created due to forking, the 
> value must be based (incremented) on the value associated with the "mother"
> PeerConnection, for which the initial Offer of the whole communication
> session was created.
> >
> > uh, that is old text sorry. I'm proposing the principal that any time
> the SDP changes (including new candidate lines) the version gets larger.
>
> Yes. But keep in mind that this is an Offer created for a new
> PeerConnection.
>
>
> ----------------
>
>
> >> Q_4:      BUNDLE
> >>
> >> The text says:
> >>
> >> "If a m= section is not being bundled into another m= section, it MUST
> >>                generate a unique set of ICE credentials and gather its
> own set of
> >>                candidates.  Otherwise, it MUST use the same ICE
> credentials and
> >>                candidates that were used in the m= section that it is
> being bundled
> >>                into."
> >>
> >> As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?
> >
> > no the initial offer will not have identical stuff other than on lines
> that "bundle-only" and we still need to add more text on this but idea is
> to make just like what is in united-plan
>
> Regarding the details (usage of port zero etc) of "bundle-only", that is
> still something we have to agree upon. But, that discussion belongs to
> MMUSIC (and, I believe there is a thread about that already :)
>
> But again, in the case of forking, when a new PeerConnection is created, I
> think we should allow identical stuff in the initial Offer of that
> PeerConnection. Because, the remote party has already indicated support of
> BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the
> initial Offer for the new PeerConnection will be the second Offer for the
> remote party.
>
> At some point, we are going to have to add much more details about
> forking, in the case multiple PeerConnections are used. It is not enough to
> only say "create a new PeerConnection" :)
>
>
> ----------------
>
>
> >> Section 5.2.2:
> >> -----------------
> >>
> >>
> >> Q_5:      Offer when in "local-offer"
> >>
> >> The text says:
> >>
> >> "If the initial offer was applied using setLocalDescription, but an
> >>                answer from the remote side has not yet been applied,
> meaning the
> >>                PeerConnection is still in the "local-offer" state, the
> steps for
> >>                generating an initial offer should be followed,"
> >>
> >> I don't understand this. Why would you create a new Offer while you are
> waiting for an Answer to the previously sent Offer?
> >
> > Justin has asked for this in the case when the offer has not been sent
> to anyone else. This is not going to be useful for typical systems trying
> to have SIP or Jingle compatible flow but who knows ...
>
> Again, we have consensus to base JSEP on 3264. And, if we are going to
> deviate from 3264, I'd like to have some discussion and justification for
> that.
>

We have been through this many times before. The state machine that has
been in the JSEP document for a while clearly shows that
local-offer->local-offer state transitions are permitted.

--90e6ba25dbdd77528804e7614da0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Sep 20, 2013 at 3:17 PM, Christer Holmberg <c=
hrister.holmberg@ericsson.com> wrote:



Hi Cullen,




>> Q_2: =C2=A0 =C2=A0 =C2=A0o- line <sess-version> initial valu=
e - forking

>>

>> When a new PeerConnection is created due to forking, the <sess-=
version> value must be based (incremented) on the value associated with =
the "mother" PeerConnection, for which the initial Offer of the w=
hole communication session was created.



>

> uh, that is old text sorry. I'm proposing the principal that any t=
ime the SDP changes (including new candidate lines) the version gets larger=
.




Yes. But keep in mind that this is an Offer created for a new PeerCon=
nection.





----------------






>> Q_4: =C2=A0 =C2=A0 =C2=A0BUNDLE

>>

>> The text says:

>>

>> "If a m=3D section is not being bundled into another m=3D sec=
tion, it MUST

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate a =
unique set of ICE credentials and gather its own set of

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates.=
 =C2=A0Otherwise, it MUST use the same ICE credentials and

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates =
that were used in the m=3D section that it is being bundled

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into."=


>>

>> As, when BUNDLE is used, the initial Offer will contain identical =
ICE candidates, does that mean that we will also include identical address =
information in the initial Offer?

>

> no the initial offer will not have identical stuff other than on lines=
 that "bundle-only" and we still need to add more text on this bu=
t idea is to make just like what is in united-plan




Regarding the details (usage of port zero etc) of "bundle-only&q=
uot;, that is still something we have to agree upon. But, that discussion b=
elongs to MMUSIC (and, I believe there is a thread about that already :)




But again, in the case of forking, when a new PeerConnection is created, I =
think we should allow identical stuff in the initial Offer of that PeerConn=
ection. Because, the remote party has already indicated support of BUNDLE, =
in the Answer that was sent for the "mother" PeerConnection, so t=
he initial Offer for the new PeerConnection will be the second Offer for th=
e remote party.





At some point, we are going to have to add much more details about forking,=
 in the case multiple PeerConnections are used. It is not enough to only sa=
y "create a new PeerConnection" :)





----------------






>> Section 5.2.2:

>> -----------------

>>

>>

>> Q_5: =C2=A0 =C2=A0 =C2=A0Offer when in "local-offer"

>>

>> The text says:

>>

>> "If the initial offer was applied using setLocalDescription, =
but an

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0answer from=
 the remote side has not yet been applied, meaning the

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PeerConnect=
ion is still in the "local-offer" state, the steps for

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generating =
an initial offer should be followed,"

>>

>> I don't understand this. Why would you create a new Offer whil=
e you are waiting for an Answer to the previously sent Offer?

>


> Justin has asked for this in the case when the offer has not bee=
n sent to anyone else. This is not going to be useful for typical systems t=
rying to have SIP or Jingle compatible flow but who knows ...



Again, we have consensus to base JSEP on 3264. And, if we are going to devi=
ate from 3264, I'd like to have some discussion and justification for t=
hat.

We have been through this many tim=
es before. The state machine that has been in the JSEP document for a while=
 clearly shows that local-offer->local-offer state transitions are permi=
tted.=C2=A0





--90e6ba25dbdd77528804e7614da0--

From juberti@google.com  Fri Sep 27 11:04:59 2013
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 0A1EB21F9E70 for ; Fri, 27 Sep 2013 11:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.87
X-Spam-Level: 
X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov-pdj5g5eVL for ; Fri, 27 Sep 2013 11:04:54 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40D21F9EC8 for ; Fri, 27 Sep 2013 11:04:47 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id as1so4666193iec.35 for ; Fri, 27 Sep 2013 11:04:46 -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; bh=Lsy1CS5B3ch3/oNRr8mlVf1WbxnTDggHp8/1DAkACLg=; b=CVzxiqVfhVXioISZU6ZyXXY4ZYQWp+DxnlG0ILCRvxNsDbjCCsM7IWZCv9LONDP6B/ fkkf20GbDdPYLcvJ7HUvdk4TCOViP/0a1w7/jluCVDhZeWaKkgz7or58YCqWn4I9uiDL FH9gxG+GA0KxnBVQkhvElqBPTo0mlDYFRiVvGIgdKwIGZhVf9tb70GEmxkBmh4mColDD FW3+hP4C7iwKi4RvD2rL+xQR1JzvUgM7US/443ztGu9hbvwuVnNvC651UHBwUYhpdtUq /7SZ0zgEqtc813qDIhUVCwc19eVUelQlQCyAYwmwljDF0fYU2xqk/UCvEdxov6lxOIPf pmJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Lsy1CS5B3ch3/oNRr8mlVf1WbxnTDggHp8/1DAkACLg=; b=UxGDNJYDfEgwyL0TvzKmvx5JZpGpU1QxZozPeljJWJFphhBa8fIAyp63ziXz9GS6EB 2J8sGRPZaTVttWaY6QaEDzpd0v0eBsoWizvUdiYb/4PsjYD/JwAcVATITeiF9MSjqN3k suJ4wkp3a4rwWtFOl7j1j/N2Zq6orlHeZUwFOqsW1stQiVW4Py4Nlh/SQ+NucGfx43Pn uy9z26XgGS/Nu49D3HST9FJgTPpJ09YQ5WcoOuvu0cI+HEnwUPI6tYRX/H6nT36jI0zx 6Ex4muYqFgaZOnv4RpHfK9svjZdjKFBPZUSKzsT9qJidmVyD5NXDvX9K1Ghpqf47weC+ KfnQ==
X-Gm-Message-State: ALoCoQl933u8qpVYms9F9DLQUZXDkis4QN5YOv7NFN19+hIklFfC+9rM9K5QfwNyM7+T8eDDSf+Tja2nOgusCk7D/PeoWFGtlnFMB20dTXmLoIrCJzCOPU41kcJKCuksB808vpZk3wVBTfvOu6R231w/D8fpaZiuPo5h9346zhyZax2yNRTF6lBEsXyyFubhyx0Xo1A/UjLl
X-Received: by 10.50.103.6 with SMTP id fs6mr3408340igb.16.1380305086124; Fri, 27 Sep 2013 11:04:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 11:04:24 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4ADF2D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4ADF2D@ESESSMB209.ericsson.se>
From: Justin Uberti 
Date: Fri, 27 Sep 2013 11:04:24 -0700
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b2e0abb57735f04e7615282
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Unified Plan: 'bundle-only' documentation
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, 27 Sep 2013 18:05:09 -0000

--047d7b2e0abb57735f04e7615282
Content-Type: text/plain; charset=UTF-8

I think that the BUNDLE draft is the right place for this.


On Fri, Sep 27, 2013 at 6:59 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> On the MMUSIC list I have suggested updated SDP Offer/Answer text for
> BUNDLE.
>
>
>
> Part of that text is the definition, and usage, of the SDP 'bundle-only'
> attribute.
>
>
>
> However, eventhough I personally think it fits well there (and I believe
> Adam had the same opinion, when I talked with him off-line in Berlin),
> afaik there has never been any formal WG agreement that the 'bundle-only'
> attribute will be defined in the BUNDLE draft.
>
>
>
> So, without going into the details (there are some issues, and if you are
> interested there are mail threads on the MMUSIC list dealing with those) do
> people have any issues with defining the SDP 'bundle-only' attribute, and
> the usage of it, in BUNDLE?
>
>
>
> If not, can we make a WG decision on the matter?
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7b2e0abb57735f04e7615282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think that the BUNDLE draft is the right place for this.=



On Fri,=
 Sep 27, 2013 at 6:59 AM, Christer Holmberg <christer.holmb=
erg@ericsson.com> wrote:













Hi,


=C2=A0


On the MMUSIC list I have suggested updated SDP Offer/Answer text for BU=
NDLE.


=C2=A0


Part of that text is the definition, and usage, of the SDP 'bundle-o=
nly' attribute.


=C2=A0


However, eventhough I personally think it fits well there (and I believe=
 Adam had the same opinion, when I talked with him off-line in Berlin), afa=
ik there has never been any formal WG agreement that the 'bundle-only&#=
39; attribute will be defined in the BUNDLE
 draft.


=C2=A0


So, without going into the details (there are some=C2=A0issues, and=C2=
=A0if you are interested there are mail threads on the MMUSIC list dealing =
with those)=C2=A0do people have any issues with defining the SDP 'bundl=
e-only' attribute, and the usage of it, in BUNDLE?




=C2=A0


If not, can we make a WG decision on the matter?


=C2=A0


Regards,


=C2=A0


Christer







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b2e0abb57735f04e7615282--

From suhasietf@gmail.com  Fri Sep 27 11:09:50 2013
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 9656B11E815F for ; Fri, 27 Sep 2013 11:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level: 
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.848,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq9SdVSqkjMW for ; Fri, 27 Sep 2013 11:09:40 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7141821F94FA for ; Fri, 27 Sep 2013 11:09:36 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z12so3115288wgg.22 for ; Fri, 27 Sep 2013 11:09:32 -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=x5IaXzHay3qEMtYKhM3gHuiSOJCx41bZiq2IXbs/Wi4=; b=BNwgKfBHsWMdWZgXG1wZu4eozhPCOQTnFVZ1GoXjtSvqGSw6+tTLUIGhoEUPcvIS89 2l5utEpFoiGTsXogrdIP4WwHcqtcviRIjEOp3kbUo3Nlad5FRjzXdyba/6hpLK1ZFdrp 4GC2RjO1CKP/6ePn0ROkJONERHIUCAzG/iMlVAFRQ1WZwfCONs4tGkB+bErgNv0BKHpo b18gdHAu10KZrOnXwpH3ODoV8E09r64zVUgvVT9BwPyeUGVq/Vdq+qqKsgoVa2Nff/Ah 9Mtmi2ClFJVZwXsYX2MfNzigj4/dA/kYrrYjY5A66X3iQS+2iSaGC8TdO5YRQ7OzRZNe dFZw==
MIME-Version: 1.0
X-Received: by 10.195.13.164 with SMTP id ez4mr6946315wjd.11.1380305372715; Fri, 27 Sep 2013 11:09:32 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Fri, 27 Sep 2013 11:09:32 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4ADF2D@ESESSMB209.ericsson.se> 
Date: Fri, 27 Sep 2013 11:09:32 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=047d7bb04f686c1ef504e76163eb
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Unified Plan: 'bundle-only' documentation
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, 27 Sep 2013 18:09:50 -0000

--047d7bb04f686c1ef504e76163eb
Content-Type: text/plain; charset=ISO-8859-1

+1


On Fri, Sep 27, 2013 at 11:04 AM, Justin Uberti  wrote:

> I think that the BUNDLE draft is the right place for this.
>
>
> On Fri, Sep 27, 2013 at 6:59 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>>  Hi,
>>
>>
>>
>> On the MMUSIC list I have suggested updated SDP Offer/Answer text for
>> BUNDLE.
>>
>>
>>
>> Part of that text is the definition, and usage, of the SDP 'bundle-only'
>> attribute.
>>
>>
>>
>> However, eventhough I personally think it fits well there (and I believe
>> Adam had the same opinion, when I talked with him off-line in Berlin),
>> afaik there has never been any formal WG agreement that the 'bundle-only'
>> attribute will be defined in the BUNDLE draft.
>>
>>
>>
>> So, without going into the details (there are some issues, and if you are
>> interested there are mail threads on the MMUSIC list dealing with those) do
>> people have any issues with defining the SDP 'bundle-only' attribute, and
>> the usage of it, in BUNDLE?
>>
>>
>>
>> If not, can we make a WG decision on the matter?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>> _______________________________________________
>> 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
>
>

--047d7bb04f686c1ef504e76163eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1


On Fri, Sep 27, 2013 at 11:04 AM, Justin Uberti <juberti@goog=
le.com> wrote:


I think that the BUNDLE dra=
ft is the right place for this.




On Fri, Sep 27, 2013 at 6:59 AM, Christer Holmberg <=
span dir=3D"ltr"><christer.holmberg@ericsson.com> wrote:













Hi,


=A0


On the MMUSIC list I have suggested updated SDP Offer/Answer text for BU=
NDLE.


=A0


Part of that text is the definition, and usage, of the SDP 'bundle-o=
nly' attribute.


=A0


However, eventhough I personally think it fits well there (and I believe=
 Adam had the same opinion, when I talked with him off-line in Berlin), afa=
ik there has never been any formal WG agreement that the 'bundle-only&#=
39; attribute will be defined in the BUNDLE
 draft.


=A0


So, without going into the details (there are some=A0issues, and=A0if yo=
u are interested there are mail threads on the MMUSIC list dealing with tho=
se)=A0do people have any issues with defining the SDP 'bundle-only'=
 attribute, and the usage of it, in BUNDLE?





=A0


If not, can we make a WG decision on the matter?


=A0


Regards,


=A0


Christer







_______________________________________________

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





--047d7bb04f686c1ef504e76163eb--

From christer.holmberg@ericsson.com  Fri Sep 27 11:53:03 2013
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 E2F8921F9994 for ; Fri, 27 Sep 2013 11:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.678
X-Spam-Level: 
X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.570,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlWOkFb5Un60 for ; Fri, 27 Sep 2013 11:52:57 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA521F9C46 for ; Fri, 27 Sep 2013 11:52:56 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-f5-5245d4064bd8
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 56.27.03802.604D5425; Fri, 27 Sep 2013 20:52:55 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 20:52:54 +0200
From: Christer Holmberg 
To: Justin Uberti 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnPLVCAgAqcawCAAC2aZIAAAd2E
Date: Fri, 27 Sep 2013 18:52:54 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AE0B5@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4A8EA4@ESESSMB209.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE0B5ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvrS77Fdcgg0mvWSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxopZO5kKGjQqJi25ytbA2KHY xcjJISFgItF76jIrhC0mceHeejYQW0jgMKPE1DdlXYxcQPYSILvjB3sXIwcHm4CFRPc/bZAa EQE1iYezdoH1MgtESBw51QvWKywQLfFoxUQ2iJoYiV3nv7BA2G4S9188BLNZBFQlPj1YBWbz CvhK7L/9hhli10wmiY//94I1cwoEShw6twWsiBHouO+n1jBBLBOXuPVkPhPE0QISS/acZ4aw RSVePv4H9YyixNXpy6Hq8yUmX7rBDLFMUOLkzCcsExhFZyEZNQtJ2SwkZRBxPYkbU6ewQdja EssWvmaGsHUlZvw7BFVjLTFx+09WZDULGDlWMbLnJmbmpJcbbWIERt7BLb9VdzDeOSdyiFGa g0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxra88XJm0qf3Dm4Z3Ze16HzJaa /8aJI/rloVl+Dm/Zbv7he7E35/XR6u5dygbJW5lbmSrXmpkdWjwxy4i75va7pRxSUpq9b4Qn fAh0niL50XX117Pf59345G0ieCqkbbvvr05Pr83ykqfuCkXU8bxsXnpfRYPx39s91Rdii8xu t3u5BH27ZWelxFKckWioxVxUnAgATix2n4oCAAA=
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 27 Sep 2013 18:53:04 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0B5ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

>>>> Section 5.2.2:
>>>> -----------------
>>>>
>>>>
>>>> Q_5:      Offer when in "local-offer"
>>>>
>>>> The text says:
>>>>
>>>> "If the initial offer was applied using setLocalDescription, but an
>>>>                answer from the remote side has not yet been applied, m=
eaning the
>>>>                PeerConnection is still in the "local-offer" state, the=
 steps for
>>>>                generating an initial offer should be followed,"
>>>>
>>>> I don't understand this. Why would you create a new Offer while you ar=
e waiting for an Answer to the previously sent Offer?
>>
>>

>>> Justin has asked for this in the case when the offer has not been sent =
to anyone else. This is not going to be useful for typical systems trying t=
o have SIP or Jingle compatible flow but who knows ...
>>
>> Again, we have consensus to base JSEP on 3264. And, if we are going to d=
eviate from 3264, I'd like to have some discussion and justification for th=
at.
>
>

> We have been through this many times before.
>
> The state machine that has been in the JSEP document for a while clearly =
shows that local-offer->local-offer state transitions are permitted.

If we've been through this many times, I must have missed, or forgotten, ea=
ch time :) Well, that can happen, so feel free to send me a link to a discu=
ssion/decission on this.

But, still, whatever deviations we agree to make to 3264, I would like to h=
ave it clearly documented - with justification.

In this case, I would also want to have it documented that the previous Off=
er is "cancelled", and that any associated pranswer/answer etc only applies=
 to the latest offer.

Regards,

Christer



--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0B5ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi,




>>>> Section 5.2.2:

>>>> -----------------

>>>>

>>>>

>>>> Q_5:      Offer when in "local-offer&q=
uot;

>>>>

>>>> The text says:

>>>>

>>>> "If the initial offer was applied using setLocalDescr=
iption, but an

>>>>                ans=
wer from the remote side has not yet been applied, meaning the

>>>>                Pee=
rConnection is still in the "local-offer" state, the steps for
>>>>                gen=
erating an initial offer should be followed,"

>>>>

>>>> I don't understand this. Why would you create a new Offer =
while you are waiting for an Answer to the previously sent Offer?

>>

>>


>>> Justin has asked for this in the case when the offer has no=
t been sent to anyone else. This is not going to be useful for typical syst=
ems trying to have SIP or Jingle compatible flow but who knows ...

>>

>> Again, we have consensus to base JSEP on 3264. And, if we are goin=
g to deviate from 3264, I'd like to have some discussion and justification =
for that.

>

>










> We have been through this many times before.


>


> The state machine that has been in the JSEP document for a w=
hile clearly shows that local-offer->local-offer state transitions are p=
ermitted. 


 


If we've been through this many times, I must have missed, or forgotte=
n, each time :) Well, that can happen, so feel free to send me a link to a =
discussion/decission on this.


 


But, still, whatever deviations we agree to make to 3264, I =
would like to have it clearly documented - with justification.


 


In this case, I would also want to have it documented that the pr=
evious Offer is "cancelled", and that any associated pranswe=
r/answer etc only applies to the latest offer.


 


Regards,


 


Christer


 


 














--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0B5ESESSMB209erics_--

From christer.holmberg@ericsson.com  Fri Sep 27 12:15:32 2013
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 7CD4921F9E68 for ; Fri, 27 Sep 2013 12:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level: 
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.563,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lan5Y2qaZxt4 for ; Fri, 27 Sep 2013 12:15:26 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DD21F9E26 for ; Fri, 27 Sep 2013 12:15:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-04-5245d9450897
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.28.03802.549D5425; Fri, 27 Sep 2013 21:15:17 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 21:15:17 +0200
From: Christer Holmberg 
To: Justin Uberti , "Cullen Jennings (fluffy)" 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnZyWEAgAAwyzyAAAVFBw==
Date: Fri, 27 Sep 2013 19:15:16 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE0DBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvra7rTdcgg087TSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxozpN1kKTntUTPr5kK2B8a5V FyMnh4SAicSjC9MYIWwxiQv31rN1MXJxCAkcZpRoWX6fCcJZwijxsHs5cxcjBwebgIVE9z9t EFNEIFxi2kYVkF5mAXWJO4vPsYPYwgLREo9WTGQDsUUEYiR2nf/CAmE7SfTNu8wEYrMIqEr0 /r0NVs8r4Cux5v0cqFVXGSWWHL0PluAUCJRofjwbbBAj0HHfT61hglgmLnHryXwmiKMFJJbs Oc8MYYtKvHz8jxXCVpS4On05VH2+xP9DvWwQywQlTs58wjKBUXQWklGzkJTNQlIGETeQeH9u PjOErS2xbOFrKFtfYuOXs4wQtrXEoZ4vrMhqFjByrGJkz03MzEkvN9rECIy8g1t+q+5gvHNO 5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNfLul+hHS4c35cQu2Kks I7KC6+YB5k9PPswqX781XuWtjOn2VQbnxD6F+8w0Dvz+7JFc6GHO6ClW8gnqpoZrUhVWMpiV PWlT0fv041tI1fpODxOpukqznLv6G0+Ha+a2Lf9T5jX7EOeEBtXLCzaskPZqjrXkavzb3hPa bDbHfZH5JJWzktxKLMUZiYZazEXFiQCArwlyigIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 27 Sep 2013 19:15:32 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0DBESESSMB209erics_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,



>>> Section 5.2.1:
>>> -----------------
>>>
>>> Q_1:      o- line  initial value - deviation
>>>
>>> What is the reason for recommending a  zero value in the =
initial Offer, when the RFC says SHOULD use an NTP format timestamp?
>>>
>>> I don=92t have any strong feelings, but in general: whenever we deviate=
 from the =93base=94 SDP procedures I think we should justify why.
>>

>> Lets use NTP
>

> It's not necessary to use NTP, since the session-id is already random. St=
arting the session id at zero makes it easier for developers see the change=
s to the session id. I can spell this out in the next version of the docume=
nt.

I assume you mean the session version, because that is what is currently ze=
ro.

But, I am sure there is a reason why SDP recommends NTP. So, again, if we w=
ant to change that, we shall discuss it in MMUSIC.

And, if we agree to change it, clearly document and justify it.



>>> Q_3:      RTP
>>>
>>> The text says:
>>>
>>> =93The  field MUST be set to "RTP/SAVPF". =93
>>>
>>> But, that of course only applies to RTP based streams (not the data cha=
nnel). Also, in general, it needs to be clear what information needs to be =
in every m- line, and what information is protocol specific. I would sugges=
t to have a =93General=94 sub-section, a =93RTP=94 sub-section, etc.
>>>
>>>
>> Yep - I think this should be offers are created with RTP/SAVPF for audio=
 and video and system can reeve offers with SAVPF or SAVP
>
> Currently the document specifies what to do with media lines, with later =
discussion of handling the SCTP line. Do you think the current information =
is not sufficiently descriptive?

My point was that we need to be more clear on what is generic, what is RTP,=
 and what is SCTP. But, as you say SCTP text is still to be added, that cla=
rification can be done when the SCTP text is added.



>> Q_4:      BUNDLE
>>
>> The text says:
>>
>> =93If a m=3D section is not being bundled into another m=3D section, it =
MUST
>>                generate a unique set of ICE credentials and gather its o=
wn set of
>>                candidates.  Otherwise, it MUST use the same ICE credenti=
als and
>>                candidates that were used in the m=3D section that it is =
being bundled
>>                into.=94
>>
>> As, when BUNDLE is used, the initial Offer will contain identical ICE ca=
ndidates, does that mean that we will also include identical address inform=
ation in the initial Offer?
>
>
> no the initial offer will not have identical stuff other than on lines th=
at "bundle-only"

Assuming you by identical mean port zero, we'll still have to agree on that=
. But, that discussion belongs to MMUSIC.







>>> Q_6:      BUNDLE
>>>
>>> We=92ll probably also need some text about BUNDLE.
>>>
>>

>> yep - but plan is to match up with unified plan
>>
>Can you be specific about what more you think needs to be said? The create=
Answer treatment of BUNDLE is one clear thing that is currently missing.



I want to have text covering both the 1st (unique address) and 2nd (shared =
address) Offer.



And, when a PeerConnection is created due to forking (ie you use a separate=
 PeerConnection for each forked leg of a session), I assume already the 1st=
 Offer for that PeerConnection can have a shared address (as the remote ent=
ity has indicated support for BUNDLE). That also needs to be covered.





Regards,



Christer




--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0DBESESSMB209erics_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <14D1EF0A902CAE42924537ED4209CF8B@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


>>> Section 5.2.1:

>>> -----------------

>>>

>>> Q_1:      o- line <sess-version> initial =
value - deviation

>>>

>>> What is the reason for recommending a <sess-version> zer=
o value in the initial Offer, when the RFC says SHOULD use an NTP format ti=
mestamp?

>>>

>>> I don=92t have any strong feelings, but in general: whenever w=
e deviate from the =93base=94 SDP procedures I think we should justify why.=


>>


>> Lets use NTP

>










> It's not necessary to use NTP, since the session-id is already ra=
ndom. Starting the session id at zero makes it easier for developers see th=
e changes to the session id. I can spell this out in the next version of th=
e document.


 


I assume you mean the session version, because that is what is current=
ly zero.


 


But, I am sure there is a reason why SDP recommends NTP. So, again, if=
 we want to change that, we shall discuss it in MMUSIC.


 


And, if we agree to change it, clearly document and justify it.


 


 


 


>>> Q_3:      RTP

>>>

>>> The text says:

>>>

>>> =93The <proto> field MUST be set to "RTP/SAVPF"=
;. =93

>>>

>>> But, that of course only applies to RTP based streams (not the=
 data channel). Also, in general, it needs to be clear what information nee=
ds to be in every m- line, and what information is protocol specific. I wou=
ld suggest to have a =93General=94 sub-section,
 a =93RTP=94 sub-section, etc.

>>>

>>>


>> Yep - I think this should be offers are created with RTP/SAVP=
F for audio and video and system can reeve offers with SAVPF or SAVP

>


> Currently the document specifies what to do with media lines, wit=
h later discussion of handling the SCTP line. Do you think the current info=
rmation is not sufficiently descriptive? 


 


My point was that we need to be more clear on what is generic, what is=
 RTP, and what is SCTP. But, as you say SCTP text is still to be added, tha=
t clarification can be done when the SCTP text is added.


 


 




>> Q_4:      BUNDLE

>>

>> The text says:

>>

>> =93If a m=3D section is not being bundled into another m=3D sectio=
n, it MUST

>>                generate a =
unique set of ICE credentials and gather its own set of

>>                candidates.=
  Otherwise, it MUST use the same ICE credentials and

>>                candidates =
that were used in the m=3D section that it is being bundled

>>                into.=94
>>

>> As, when BUNDLE is used, the initial Offer will contain identical =
ICE candidates, does that mean that we will also include identical address =
information in the initial Offer?

>

>


> no the initial offer will not have identical stuff other than on =
lines that "bundle-only"


 


Assuming you by identical mean port zero, we'll still have to agree on=
 that. But, that discussion belongs to MMUSIC.


 


 


 


>>> Q_6:      BUNDLE

>>>

>>> We=92ll probably also need some text about BUNDLE.

>>>

>>


>> yep - but plan is to match up with unified plan

>>

>Can you be specific about what more you think needs to be said? The cre=
ateAnswer treatment of BUNDLE is one clear thing that is currently missing.=



 


I want to have text covering both the 1st (unique address) and 2nd =
(shared address) Offer.


 


And, when a PeerConnection is created due to forking (ie you use a separ=
ate PeerConnection for each forked leg of a session), I assume already the =
1st Offer for that PeerConnection can have a shared address (as the remote =
entity has indicated support for
 BUNDLE). That also needs to be covered.


 


 


Regards,


 


Christer


 
















--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0DBESESSMB209erics_--

From jlaurens@cisco.com  Fri Sep 27 12:44:12 2013
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 9E01921F9048 for ; Fri, 27 Sep 2013 12:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azNDoeL-d0up for ; Fri, 27 Sep 2013 12:44:07 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 729D421F8F2E for ; Fri, 27 Sep 2013 12:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15221; q=dns/txt; s=iport; t=1380311043; x=1381520643; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=thUEN4US7XN5ozc35nb6FHS5kK65TdZHe4fm5528soM=; b=AzLHST2dyqPgfTNgQRnwginkQAkSpGew1GqCJhplQdVf94Fdo1SwCKlP LQ/6gAUus0MFidH2cy/UUsKVzGqh40hjKL37x0oU8v9BwxNr0dEWAgtfi N80UEgkXpfDCbo3P7xwMeC30Z7NyWkKsr/XWhrZtwhYsNLRmPOgNqhmqM A=;
X-Files: smime.p7s : 4391
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlwFAOHeRVKtJXG+/2dsb2JhbABbgwc4UsACSoEhFm0HgiUBAQEDAQEBAWsQCwIBCBgKJAIlCyUCBBMIBodyBgy5YwSPIC0LAgKDG4EBA5AngTCYIIFmgT6CKg
X-IronPort-AV: E=Sophos;i="4.90,995,1371081600";  d="p7s'?scan'208,217";a="265463786"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 27 Sep 2013 19:44:01 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RJi0M4021008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Sep 2013 19:44:00 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.157]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 14:44:00 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] TURN server address via DHCP,	WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOu5p8y6zfKo6w9EyQ/vWuUguPDZnaUFoA
Date: Fri, 27 Sep 2013 19:44:00 +0000
Message-ID: 
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>    <9304FCD1-7727-4F98-A810-F75D48769128@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.232.25]
Content-Type: multipart/signed; boundary="Apple-Mail=_5C65E9AC-0AA3-4DA3-9084-33C272C002EA"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 27 Sep 2013 19:44:12 -0000

--Apple-Mail=_5C65E9AC-0AA3-4DA3-9084-33C272C002EA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5CC4EF7F-FC43-4D1F-B284-56BD5DD3C094"


--Apple-Mail=_5CC4EF7F-FC43-4D1F-B284-56BD5DD3C094
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

What is the usual "business model" for this? Assume in most cases the =
servers are hosted by folks who actually have a revenue stream from the =
app that is leveraging the servers.

Do we have some idea as to how the browser folks want to pay for the =
"WebRTC turn tax"?




On Sep 27, 2013, at 11:58 AM, Justin Uberti  wrote:

> Agree. I still think that extending PAC files to include TURN =
information is the right way to go.
>=20
> PAC files can already be discovered via DHCP or DNS, there is no need =
to reinvent this wheel.
>=20
>=20
> On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) =
 wrote:
>=20
> I think we need to give some advise to the browsers vendors on what =
they should implement to find turn servers
>=20
> On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com" =
 wrote:
>=20
> > Hi,
> >
> > Cullen Jennings wrote:
> >>
> >> I will note that browsers have many ways to learn about HTTP =
proxies from
> >> the network and it seems to me that using some of theses same =
technique
> >> might also be a good way to learn about TURN servers.
> >
> > I agree. I assume that in enterprises it would be the same people =
managing both of these.
> >
> > Is there something the IETF can or should do about this, or do we =
just assume it will happen? A new DHCP option is something the IETF =
could easily do, but I also doubt how usable that would be.
> >
> > Markus
> _______________________________________________
> 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


--Apple-Mail=_5CC4EF7F-FC43-4D1F-B284-56BD5DD3C094
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

What =
is the usual "business model" for this? Assume in most cases the servers =
are hosted by folks who actually have a revenue stream from the app that =
is leveraging the servers.

Do we have some idea as to =
how the browser folks want to pay for the "WebRTC turn =
tax"?







On Sep 27, 2013, at 11:58 AM, Justin Uberti <juberti@google.com> =
wrote:

Agree. I still think that extending =
PAC files to include TURN information is the right way to =
go.

PAC files can already be discovered via DHCP or =
DNS, there is no need to reinvent this wheel.





On =
Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:





I think we need to give some advise to the browsers vendors on what they =
should implement to find turn servers




On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com" =
<Markus.Isomaki@nokia.com> =
wrote:



> Hi,

>

> Cullen Jennings wrote:

>>

>> I will note that browsers have many ways to learn about HTTP =
proxies from

>> the network and it seems to me that using some of theses same =
technique

>> might also be a good way to learn about TURN servers.

>

> I agree. I assume that in enterprises it would be the same people =
managing both of these.

>

> Is there something the IETF can or should do about this, or do we =
just assume it will happen? A new DHCP option is something the IETF =
could easily do, but I also doubt how usable that would be.

>

> Markus

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




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

=

--Apple-Mail=_5CC4EF7F-FC43-4D1F-B284-56BD5DD3C094--

--Apple-Mail=_5C65E9AC-0AA3-4DA3-9084-33C272C002EA
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXjCCBWgw
ggRQoAMCAQICECjE3tiHj409zJpbH+09+ZIwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEwMTQwMDAwMDBaFw0x
MzEwMTYyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRkwFwYDVQQDFBBKZXJlbXkgTGF1cmVuc29uMSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0Bj
aXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5VaephAO+dvxdwX5nWo3E
iPJQFMXXNOwOcGSBQ85zlG/VjMK2I8zuyxl9YprteKE9pz/lJOtoZcsWHyu23OFHEqFitjtC5LIW
42pGYfgXmkvNGY2IPx1T+qW+4Y0Y59NocryrD/F8U2qUbwo3rU3xgycYAc8zJb7KEQdHxhpCmc22
YmrSV7H6pfHv72jE1H7sX1ypugbtFF0sGHId/y/Q+5B8+hBSt5ZXqA+UUSMeO/5YP/w5H07ZBK04
yYFbduY/5zKxhiNKMdi0C+cI+1HnAbux21Mn1E22nqU1NCAH9U+DfqyAmm8q6y9vfMkXKQp7Nw9U
QeP2Aeka/XXvrlRjAgMBAAGjgegwgeUwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB
BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD
AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUw
UAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5j
b20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBYwE5X9aC75a5MniG5
0l3/0uzrj8ABdzV/u3JYoY7RtrW5dbNHhJM7MWOE5Bbn8uqRigHnhJKfxUSTMPZc/5A3fM+AL4D2
4D+TAa2JVqXIY6jqYhDXgojBV8GtQtyhaiONQukDBEIo62bCEVidAi3RUMmgpY92WufSfwhcTXI4
IEn97XswjFXO8zi0dYNDYptTOa9hKkE4qHi78kJyt0ffqE0BJpC4M7ewSsM2M5YlxogmdSyb2aoB
Qniu/N8DHMRnuHRmiU+7tZ4DLKnVzfmU558saabx2aOUw/wpE7OCC1MUQhM3d8NAGHAXPME2jCCb
Wef22uUVOCwXLZI1fSP7MIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0B
AQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAt
IEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcN
MTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3Qg
VmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl
ciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJ
bBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2
WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8
Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3
r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi
44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUG
C2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMw
KgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmg
J6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYw
bgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYG
DLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4G
A1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5
R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
OjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9u
bHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlN
z0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDW
zE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSs
KpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3
uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV
7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAoxN7Yh4+NPcyaWx/tPfmSMAkG
BSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEz
MDkyNzE5NDM0NVowIwYJKoZIhvcNAQkEMRYEFB7Hm2iaBE5phW5wPPFMZX34CBhXMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCECjE3tiHj409zJpbH+09+ZIwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAoxN7Yh4+NPcya
Wx/tPfmSMA0GCSqGSIb3DQEBAQUABIIBAG+CMMlvzKlawJwdRoFvtWu3gDWU9aMmsN98YBhq9ekN
YD9wHoHCOziSUGBfBuzWAwiZEr+C21qiFYsx/aoG3Rvm4P/4wmZPi3Qbc/IvNPHpcdGe6vg67gPh
IEx5LwuRYePjjz28lxLslpMDDHUVFXM4hoj12qD+h8DDW5xwb3U8WMIPZoiY4Wrr0J49Eb69/vCo
OWhpjtbf6x8x/X1qhDJTSu506NWbFlAtFyXdbYoKiZLcvbe4Ubi7q5gOGj2AN3YVwAm4P8e/m1l6
zfxna1XEe0wNzs+2LGDBHbt4/vrtQmy9sOB3WfHREugY84guE3HGrynUzkm9DOm7llCa8ngAAAAA
AAA=

--Apple-Mail=_5C65E9AC-0AA3-4DA3-9084-33C272C002EA--

From juberti@google.com  Fri Sep 27 14:42:55 2013
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 9F6D121E8054 for ; Fri, 27 Sep 2013 14:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level: 
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1O5738GKM9M for ; Fri, 27 Sep 2013 14:42:55 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E64CC21E808C for ; Fri, 27 Sep 2013 14:42:41 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so5346632ief.1 for ; Fri, 27 Sep 2013 14:42:41 -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; bh=PwtKU3Y4NL2wHWsuNbPZbovsgn4lIKJ7oTWeiO2tutY=; b=dydje3cx4abjxHQpZFtRlhI544MHEA3wdrFS8MAjzVAG8wHqwT7XjDGlyvAbCAIpmP BC3JNtq6W/lJPA37ycmHzg/+yMCS7D+bD8gUB9cNj1pz/LX0NUGW3iST2J0qBM4h74DX TnBhYoApl2H0iI4K0+l3rGMiq3/rk8fB71ug0YP4L/zXa9NSzmqt+TgfroTLSMZEMAj6 bL0wqpYvey531smhB5Q/pkrFEVCAdC7rAw+eVLAFdHPZQ3SGp/WAsm7sAvS4t7l7BvQc neTWV9ZXHpqU6FYdA2nFSCPK+gd3khslDUtC4KLYrbz8YAJL2VboxKvmugeAZreIpy34 wfzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PwtKU3Y4NL2wHWsuNbPZbovsgn4lIKJ7oTWeiO2tutY=; b=USYHHgACqpttQ4dlM9MZXcMYS8qksQBSe3Wp8JX5Iy325B/fV1BwCGq6fRC/F/PkU4 KAXpVIX7/t1uhdvnpR0cwh16IqU0L6fqUSo+9AMgB7x/wIMJMlgRqo/UlUiZKhjWKCm6 53wXPsHx5aHcDGX0WQ66AGAy2HJvXWSJt8b/U+x9xaVy7MxTBx7so15Un2f+8/havowb vuQzBComigtJDIBV6lLfvzwcrX1B6DdRNr/f8fv0cPjmdwDkIz9hmJBwgV7bPyJ1MQcA scmIPzS4/+Noyt68SU3ngBWRwHp4aq1qF683zdoDVrdvfblJrW9V/IcgbdiyyKptotzB 1weg==
X-Gm-Message-State: ALoCoQkTad+rltVFuGzDl5n0Cw8uxBiSbQ6gECEMVPGSOwKIq+oU7Qe4sAaF01ulcHrFypxrcRASWdtlanBBlV4RZcCUIMk0y8zM0Hzugi2+X7aDhhA590zgfzgrhfSym8I8tAmG42d5lssKppb62Z9gy25pXvBiI+1g3BnGz8V+sHRFQpoQVJAOFiBllVffywbAF0vzqAcS
X-Received: by 10.50.13.104 with SMTP id g8mr4192570igc.30.1380318161375; Fri, 27 Sep 2013 14:42:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 14:42:21 -0700 (PDT)
In-Reply-To: 
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>    <9304FCD1-7727-4F98-A810-F75D48769128@cisco.com>  
From: Justin Uberti 
Date: Fri, 27 Sep 2013 14:42:21 -0700
Message-ID: 
To: "Jeremy Laurenson (jlaurens)" 
Content-Type: multipart/alternative; boundary=089e013c69c6afb54a04e7645daf
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 27 Sep 2013 21:42:55 -0000

--089e013c69c6afb54a04e7645daf
Content-Type: text/plain; charset=UTF-8

The business model is the same as for HTTP proxies. ISPs or enterprises
that want to better control their traffic will pay.


On Fri, Sep 27, 2013 at 12:44 PM, Jeremy Laurenson (jlaurens) <
jlaurens@cisco.com> wrote:

> What is the usual "business model" for this? Assume in most cases the
> servers are hosted by folks who actually have a revenue stream from the app
> that is leveraging the servers.
>
> Do we have some idea as to how the browser folks want to pay for the
> "WebRTC turn tax"?
>
>
>
>
> On Sep 27, 2013, at 11:58 AM, Justin Uberti  wrote:
>
> Agree. I still think that extending PAC files to include TURN information
> is the right way to go.
>
> PAC files can already be discovered via DHCP or DNS, there is no need to
> reinvent this wheel.
>
>
> On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <
> fluffy@cisco.com> wrote:
>
>>
>> I think we need to give some advise to the browsers vendors on what they
>> should implement to find turn servers
>>
>> On Sep 26, 2013, at 5:13 AM, "Markus.Isomaki@nokia.com" <
>> Markus.Isomaki@nokia.com> wrote:
>>
>> > Hi,
>> >
>> > Cullen Jennings wrote:
>> >>
>> >> I will note that browsers have many ways to learn about HTTP proxies
>> from
>> >> the network and it seems to me that using some of theses same technique
>> >> might also be a good way to learn about TURN servers.
>> >
>> > I agree. I assume that in enterprises it would be the same people
>> managing both of these.
>> >
>> > Is there something the IETF can or should do about this, or do we just
>> assume it will happen? A new DHCP option is something the IETF could easily
>> do, but I also doubt how usable that would be.
>> >
>> > Markus
>> _______________________________________________
>> 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
>
>

--089e013c69c6afb54a04e7645daf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The business model is the same as for HTTP proxies. ISPs o=
r enterprises that want to better control their traffic will pay.


On Fri, Sep 27, 2=
013 at 12:44 PM, Jeremy Laurenson (jlaurens) <jlaurens@cisco.com>=
 wrote:



What is =
the usual "business model" for this? Assume in most cases the ser=
vers are hosted by folks who actually have a revenue stream from the app th=
at is leveraging the servers.



Do we have some idea as to how the browser folks want to pay=
 for the "WebRTC turn tax"?

=






























On Sep 27, 2013, at 11:58 AM, Justin Uberti <juberti@google.com> wrote=
:

Agree. I still think =
that extending PAC files to include TURN information is the right way to go=
.



PAC files can already be discovered via DHCP or DNS, there i=
s no need to reinvent this wheel.





On Thu,=
 Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>=
; wrote:







I think we need to give some advise to the browsers vendors on what they sh=
ould implement to find turn servers




_______________________________________________
rtcweb mailing list
<=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/rtcweb





________________________=
_______________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e013c69c6afb54a04e7645daf--

From juberti@google.com  Fri Sep 27 14:48:42 2013
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 06FB421F9CA5 for ; Fri, 27 Sep 2013 14:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1XD4Bxxnw2Z for ; Fri, 27 Sep 2013 14:48:41 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5215321F9AE3 for ; Fri, 27 Sep 2013 14:48:31 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id qd12so5115926ieb.8 for ; Fri, 27 Sep 2013 14:48:30 -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; bh=Ddh5hhlHG6k+Z84n5M3hA6ChSfV2CLmMOMdtKm562bc=; b=L5ouCDMBbOQ8JxK302z5p8huVcrh7kay53v4mOupT9mGtfve0qDehwqZfI7D1LenFE 6oE6XfqKDdTO6Zk74R92p9teyYg769S70W0+jl7CIh2+OAwNfblOkcFfrX1RRzkYTtv9 KjOE0Oe9Iy2+nMp8W9WEMTPMMW10M7gBzzkIZuxpmLjbIR++nela/sk5hAuuTU6YuIvZ oViVs7CINfgAUMUQjvqW4YhFE8RitHB4HPFo7SKtTLa/U0/17sYosY3balIrGnq5DxQg 93lxh/QUHyx4rRSyeNxXqoGvvkpMpoxeNJDOzLamK8TKVc9n1oO2t8vBKRWHedv98iw9 VDDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ddh5hhlHG6k+Z84n5M3hA6ChSfV2CLmMOMdtKm562bc=; b=ZhDPNsz0dkgjhTkWta1dcbansZd9ezVo8P7tnY7naj1yxVQtJ6Qe4PVl7XbYVKXVuT uWOi1lfl/zwAXEjW6sJri2k/RTH0ZyUrQ2nvyV8FElOpNlBZCmd7PBURxVLVAclF7R/v ZEvOOf/3NY5vvi4BG9zPxy7UrOALO0zOxbPLSCIdn2E64poEiMGDyGTOiVqZcyQOGnNR EU6PQUXc97A3W4BYQIhpM61eEA5sZ0uzTUvKfs/0ZAEShmjg05DcuYU7TqLYV6ts9ght AAXDejj2lg4nfrqO82NuuQxg8wwDFWds1myG/1jzxClQR6Gny6QDz+QxjysvncEby2I3 8sfA==
X-Gm-Message-State: ALoCoQnxyuaYGCWFDTa59QyQBloPabgVV19eNB0IpWHAPjlZv6btHzwRKegAqapksVe5epjRybfRJOkUj2BAYeQtgUEnngUs9urhofMMdv/wrVjIMU5zEksyT2Z8Ar70oz7JQjYFwC2VwZSPf9E6EQZE0g3X9+o1BRIvW/hcRx1KAthpPHO24FVg7QCVo4p6FgHsqdPeo6Uc
X-Received: by 10.42.223.134 with SMTP id ik6mr8132349icb.4.1380318510641; Fri, 27 Sep 2013 14:48:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Fri, 27 Sep 2013 14:48:10 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>   <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>
From: Justin Uberti 
Date: Fri, 27 Sep 2013 14:48:10 -0700
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=001a11330a1681405f04e76472d2
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 27 Sep 2013 21:48:42 -0000

--001a11330a1681405f04e76472d2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 27, 2013 at 12:15 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> >>> Section 5.2.1:
> >>> -----------------
> >>>
> >>> Q_1:      o- line  initial value - deviation
> >>>
> >>> What is the reason for recommending a  zero value in th=
e
> initial Offer, when the RFC says SHOULD use an NTP format timestamp?
> >>>
> >>> I don=E2=80=99t have any strong feelings, but in general: whenever we=
 deviate
> from the =E2=80=9Cbase=E2=80=9D SDP procedures I think we should justify =
why.
> >>
>
> >> Lets use NTP
> >
>   > It's not necessary to use NTP, since the session-id is already
> random. Starting the session id at zero makes it easier for developers se=
e
> the changes to the session id. I can spell this out in the next version o=
f
> the document.
>
> I assume you mean the session version, because that is what is currently
> zero.
>

whoops :)


>
> But, I am sure there is a reason why SDP recommends NTP. So, again, if we
> want to change that, we shall discuss it in MMUSIC.
>
> And, if we agree to change it, clearly document and justify it.
>

As long as what we are proposing is consistent with 3261 (the suggestion of
NTP is only SHOULD strength), and we explain why it should be done this way
in the rtcweb document (which the document already does, to some degree), I
don't think we need to argue about it in mmusic.

There are bigger fish to fry...

>
>
>
> >>> Q_3:      RTP
> >>>
> >>> The text says:
> >>>
> >>> =E2=80=9CThe  field MUST be set to "RTP/SAVPF". =E2=80=9C
> >>>
> >>> But, that of course only applies to RTP based streams (not the data
> channel). Also, in general, it needs to be clear what information needs t=
o
> be in every m- line, and what information is protocol specific. I would
> suggest to have a =E2=80=9CGeneral=E2=80=9D sub-section, a =E2=80=9CRTP=
=E2=80=9D sub-section, etc.
> >>>
> >>>
> >> Yep - I think this should be offers are created with RTP/SAVPF for
> audio and video and system can reeve offers with SAVPF or SAVP
> >
> > Currently the document specifies what to do with media lines, with late=
r
> discussion of handling the SCTP line. Do you think the current informatio=
n
> is not sufficiently descriptive?
>
> My point was that we need to be more clear on what is generic, what is
> RTP, and what is SCTP. But, as you say SCTP text is still to be added, th=
at
> clarification can be done when the SCTP text is added.
>

Sorry I was unclear - there is SCTP-specific text in the current document.

>
>
>
> >> Q_4:      BUNDLE
> >>
> >> The text says:
> >>
> >> =E2=80=9CIf a m=3D section is not being bundled into another m=3D sect=
ion, it MUST
> >>                generate a unique set of ICE credentials and gather its
> own set of
> >>                candidates.  Otherwise, it MUST use the same ICE
> credentials and
> >>                candidates that were used in the m=3D section that it i=
s
> being bundled
> >>                into.=E2=80=9D
> >>
> >> As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?
> >
> >
> > no the initial offer will not have identical stuff other than on lines
> that "bundle-only"
>
> Assuming you by identical mean port zero, we'll still have to agree on
> that. But, that discussion belongs to MMUSIC.
>
>
>
>
>
>
>
> >>> Q_6:      BUNDLE
> >>>
> >>> We=E2=80=99ll probably also need some text about BUNDLE.
> >>>
> >>
>
> >> yep - but plan is to match up with unified plan
> >>
> >Can you be specific about what more you think needs to be said? The
> createAnswer treatment of BUNDLE is one clear thing that is currently
> missing.
>
>
>
> I want to have text covering both the 1st (unique address) and 2nd (share=
d
> address) Offer.
>
Acknowledged.

>
>
> And, when a PeerConnection is created due to forking (ie you use a
> separate PeerConnection for each forked leg of a session), I assume alrea=
dy
> the 1st Offer for that PeerConnection can have a shared address (as the
> remote entity has indicated support for BUNDLE). That also needs to be
> covered.
>
>
>
Yes. Which may indicate the need for a setting on a PeerConnection to use a
shared address on the initial offer, since it might have come from such a
fork.

>
>
> Regards,
>
>
>
> Christer
>
>
>
>

--001a11330a1681405f04e76472d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Sep 27, 2013 at 12:15 PM, Christer Holmberg <=
christer.holmberg@ericsson.com> wrote:













Hi,


=C2=A0


>>> Section 5.2.1:

>>> -----------------

>>>

>>> Q_1: =C2=A0 =C2=A0 =C2=A0o- line <sess-version> initial =
value - deviation

>>>

>>> What is the reason for recommending a <sess-version> zer=
o value in the initial Offer, when the RFC says SHOULD use an NTP format ti=
mestamp?

>>>

>>> I don=E2=80=99t have any strong feelings, but in general: when=
ever we deviate from the =E2=80=9Cbase=E2=80=9D SDP procedures I think we s=
hould justify why.

>>


>> Lets use NTP

>










> It's not necessary to use NTP, since the session-id is alread=
y random. Starting the session id at zero makes it easier for developers se=
e the changes to the session id. I can spell this out in the next version o=
f the document.




=C2=A0


I assume you mean the session version, because that is what is c=
urrently zero.



=

whoops :)
=C2=A0



=C2=A0


But, I am sure there is a reason why SDP recommends NTP. So, again, if=
 we want to change that, we shall discuss it in MMUSIC.


=C2=A0


And, if we agree to change it, clearly document and justify it.
<=
/div>

As long=
 as what we are proposing is consistent with 3261 (the suggestion of NTP is=
 only SHOULD strength), and we explain why it should be done this way in th=
e rtcweb document (which the document already does, to some degree), I don&=
#39;t think we need to argue about it in mmusic.=C2=A0




There are bigger fish to fry...





=C2=A0


=C2=A0


=C2=A0


>>> Q_3: =C2=A0 =C2=A0 =C2=A0RTP

>>>

>>> The text says:

>>>

>>> =E2=80=9CThe <proto> field MUST be set to "RTP/SAVP=
F". =E2=80=9C

>>>

>>> But, that of course only applies to RTP based streams (not the=
 data channel). Also, in general, it needs to be clear what information nee=
ds to be in every m- line, and what information is protocol specific. I wou=
ld suggest to have a =E2=80=9CGeneral=E2=80=9D sub-section,
 a =E2=80=9CRTP=E2=80=9D sub-section, etc.

>>>

>>>


>> Yep - I think this should be offers are created with RTP/SAVP=
F for audio and video and system can reeve offers with SAVPF or SAVP

>


> Currently the document specifies what to do with media lines, wit=
h later discussion of handling the SCTP line. Do you think the current info=
rmation is not sufficiently descriptive?=C2=A0


=C2=A0


My point was that we need to be more clear on what is generic, w=
hat is RTP, and what is SCTP. But, as you say SCTP text is still to be adde=
d, that clarification can be done when the SCTP text is added.




Sorry I was =
unclear - there is SCTP-specific text in the current document.=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">




=C2=A0


=C2=A0




>> Q_4: =C2=A0 =C2=A0 =C2=A0BUNDLE

>>

>> The text says:

>>

>> =E2=80=9CIf a m=3D section is not being bundled into another m=3D =
section, it MUST

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate a =
unique set of ICE credentials and gather its own set of

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates.=
 =C2=A0Otherwise, it MUST use the same ICE credentials and

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates =
that were used in the m=3D section that it is being bundled

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into.=E2=80=
=9D

>>

>> As, when BUNDLE is used, the initial Offer will contain identical =
ICE candidates, does that mean that we will also include identical address =
information in the initial Offer?

>

>


> no the initial offer will not have identical stuff other than on =
lines that "bundle-only"


=C2=A0


Assuming you by identical mean port zero, we'll still have t=
o agree on that. But, that discussion belongs to MMUSIC.


=C2=A0


=C2=A0


=C2=A0


>>> Q_6: =C2=A0 =C2=A0 =C2=A0BUNDLE

>>>

>>> We=E2=80=99ll probably also need some text about BUNDLE.

>>>

>>


>> yep - but plan is to match up with unified plan

>>

>Can you be specific about what more you think needs to be said? The cre=
ateAnswer treatment of BUNDLE is one clear thing that is currently missing.=



=C2=A0


I want to have text covering both=C2=A0the 1st (unique address) an=
d 2nd (shared address) Offer.
Acknowledged.=C2=A0





=C2=A0


And, when a PeerConnection is created due to forking (ie you use a separ=
ate PeerConnection for each forked leg of a session), I assume already the =
1st Offer for that PeerConnection can have a shared address (as the remote =
entity has indicated support for
 BUNDLE). That also needs to be covered.


=C2=A0
Yes. Whi=
ch may indicate the need for a setting on a PeerConnection to use a shared =
address on the initial offer, since it might have come from such a fork.=C2=
=A0







=C2=A0


Regards,


=C2=A0


Christer


=C2=A0




















--001a11330a1681405f04e76472d2--

From christer.holmberg@ericsson.com  Fri Sep 27 23:52:41 2013
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 58C3C11E817D for ; Fri, 27 Sep 2013 23:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level: 
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.571,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3k80DBUSl-Y for ; Fri, 27 Sep 2013 23:52:35 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F711E8126 for ; Fri, 27 Sep 2013 23:52:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-94-52467caf930b
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A5.03.22048.FAC76425; Sat, 28 Sep 2013 08:52:32 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 28 Sep 2013 08:52:31 +0200
From: Christer Holmberg 
To: Justin Uberti 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnZyWEAgAAwyzyAAAVFB4AACS8AgAC38feAAAGv7Q==
Date: Sat, 28 Sep 2013 06:52:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AE733@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>   <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre6GGrcgg+7jLBYdk9kstk4Vslj7 r53dgdljyu+NrB4LNpV6LFnykymAOYrLJiU1J7MstUjfLoErY3frVcaCrdYV81/MY2pg3GbY xcjJISFgIvF021p2CFtM4sK99WxdjFwcQgKHGSXWLp3KBOEsYZS49vIjUIaDg03AQqL7nzZI g4iAmsTDWbtYQWxmgQiJI6d62UBsYYFoiUcrJrJB1MRI7Dr/hQXCDpM4cXIhWJxFQFXi9rxP YDavgK/E+7UnoHY9YJJ40bqWEWQXp0CgRMsaDpAaRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOe GcIWlXj5+B8rSKuEgKLE8n45iPJ8ibdTHzFDrBKUODnzCcsERtFZSCbNQlI2C0kZRNxA4v25 +cwQtrbEsoWvoWx9iY1fzjJC2NYSf05eYEVWs4CRYxUje25iZk56ufkmRmDcHdzy22AH46b7 YocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaH0gbd6m2c1v3VY5vr53 fKX6S5+3TxS3XzT+IKCpcUVsQf07a7U9Tk/Y3m++8K5OZaH3t5+cb2t/rHHp5Hl9NsPTblPU 5aj/0pPZQ0TN/h07KPXwjofd5F3vnBbueOrx9j1jj++xn4JbuPwaj22rWey3wPf4zUV1Xhse xp2rVdtls+s6d5MQR6oSS3FGoqEWc1FxIgBdtFfriQIAAA==
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 28 Sep 2013 06:52:41 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,



>>>>> Q_3:      RTP
>>>>>
>>>>> The text says:
>>>>>
>>>>> =93The  field MUST be set to "RTP/SAVPF". =93
>>>>>
>>>>> But, that of course only applies to RTP based streams (not the data c=
hannel). Also, in general, it needs to be clear what information
>>>>> needs to be in every m- line, and what information is protocol specif=
ic. I would suggest to have a =93General=94 sub-section, a =93RTP=94 sub-se=
ction, etc.
>>>>>
>>>>>
>>>> Yep - I think this should be offers are created with RTP/SAVPF for aud=
io and video and system can reeve offers with SAVPF or SAVP
>>>
>>> Currently the document specifies what to do with media lines, with late=
r discussion of handling the SCTP line. Do you think the current informatio=
n is not sufficiently descriptive?
>>
>> My point was that we need to be more clear on what is generic, what is R=
TP, and what is SCTP. But, as you say SCTP text is still to be added, that =
clarification can be done when the SCTP text is added.

>Sorry I was unclear - there is SCTP-specific text in the current document.

Ok, so while the content itself might be ok, at some point I'd like to have=
 separate sub-sections for the generic stuff, the RTP specicif stuff, and t=
he SCTP specific stuff.



>>>>> Q_6:      BUNDLE
>>>>>
>>>>> We=92ll probably also need some text about BUNDLE.
>>>>>
>>>>

>>>> yep - but plan is to match up with unified plan
>>>>
>>>Can you be specific about what more you think needs to be said? The crea=
teAnswer treatment of BUNDLE is one clear thing that is currently missing.

>>

>> I want to have text covering both the 1st (unique address) and 2nd (shar=
ed address) Offer.

> Acknowledged.

>

>> And, when a PeerConnection is created due to forking (ie you use a separ=
ate PeerConnection for each forked leg of a session), I assume

>> already the 1st Offer for that PeerConnection can have a shared address =
(as the remote entity has indicated support for BUNDLE). That also needs to=
 be covered.

>>

> Yes. Which may indicate the need for a setting on a PeerConnection to use=
 a shared address on the initial offer, since it might have come from such =
a fork.

Excellent.

Regards,

Christer


--_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <430FD3D9713482449AA7CFFBB67BC001@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


























>>>>> Q_3:      RTP

>>>>>

>>>>> The text says:

>>>>>

>>>>> =93The <proto> field MUST be set to "RTP/SA=
VPF". =93

>>>>>

>>>>> But, that of course only applies to RTP based streams =
(not the data channel). Also, in general, it needs to be clear what informa=
tion


>>>>> needs to be in every m- line, and what infor=
mation is protocol specific. I would suggest to have a =93General=94 sub-se=
ction, a =93RTP=94 sub-section, etc.

>>>>>

>>>>>


>>>> Yep - I think this should be offers are created with =
RTP/SAVPF for audio and video and system can reeve offers with SAVPF or SAV=
P

>>>


>>> Currently the document specifies what to do with media li=
nes, with later discussion of handling the SCTP line. Do you think the curr=
ent information is not sufficiently descriptive? 


>>




>> My point was that we need to be more clear on what is generic=
, what is RTP, and what is SCTP. But, as you say SCTP text is still to be a=
dded, that clarification can be done when the SCTP text is added.





















>Sorry I was unclear - there is SCTP-specific text in the current d=
ocument. 


 


Ok, so while the content itself might be ok, at some point I'd like to=
 have separate sub-sections for the generic stuff, the RTP specicif stuff, =
and the SCTP specific stuff.



 


  


















>>>>> Q_6:      BUNDLE

>>>>>

>>>>> We=92ll probably also need some text about BUNDLE.

>>>>>

>>>>


>>>> yep - but plan is to match up with unified plan

>>>>

>>>Can you be specific about what more you think needs to be said?=
 The createAnswer treatment of BUNDLE is one clear thing that is currently =
missing.


>> 




>> I want to have text covering both the 1st (unique address)=
 and 2nd (shared address) Offer.
















> Acknowledged. 


















> 


>> And, when a PeerConnection is created due to forking (ie you us=
e a separate PeerConnection for each forked leg of a session), I assume



>> already the 1st Offer for that PeerConnection can have a shared=
 address (as the remote entity has indicated support for BUNDLE). That also=
 needs to be covered.


>>
















> Yes. Which may indicate the need for a setting on a PeerConnectio=
n to use a shared address on the initial offer, since it might have come fr=
om such a fork. 


 


Excellent.


 


Regards,


 


Christer


 














--_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_--

From sergio.garcia.murillo@gmail.com  Sat Sep 28 15:08:44 2013
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 7CED021E808C for ; Sat, 28 Sep 2013 15:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhFH6+305iow for ; Sat, 28 Sep 2013 15:08:43 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3F21E811F for ; Sat, 28 Sep 2013 15:08:41 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id cb5so2254587wib.9 for ; Sat, 28 Sep 2013 15:08:40 -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 :content-type; bh=yvIetwskAvqFp94GUGVIhjfx51Y5VSUgOmxSQcGUVgQ=; b=YLGfgMfU/VkSednRWx4duo5KtOvZpEYqk7ckPrjJyIbWnBLSeehAdoME5/EyUeMQVm 461lrIVFvF3FgTOqw9qsTbEh8exa/XsAQAE7Op6o1DfXWaIUgpGgLNscDHEchw4yuliF a9Hwjcy3KlxJsjEHIfm4/SZ3Kg+PFz27JFF9YXhH06Z5iccMvaxW8lE3kZ+PHqwgR6jo /glzSPL2iYP52J4ALqUnhZC4oycAFP5GmRm+wYZNOZU9TR7NmrStxzBLMkuSaJ8PDD15 +d8hsEdKGxDr2XOSTXw7wtwKEJLDK+GN627sbs0Q7PppS1I3gcbviv6hz8ME7pnC875N 5k7g==
X-Received: by 10.194.9.70 with SMTP id x6mr11035172wja.22.1380406120489; Sat, 28 Sep 2013 15:08:40 -0700 (PDT)
Received: from [192.168.1.2] ([90.165.209.121]) by mx.google.com with ESMTPSA id iz19sm10085808wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Sep 2013 15:08:39 -0700 (PDT)
Message-ID: <52475369.9040107@gmail.com>
Date: Sun, 29 Sep 2013 00:08:41 +0200
From: Sergio Garcia Murillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="------------010403020909070001000908"
Subject: [rtcweb] Camera rotation on mobile phones
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, 28 Sep 2013 22:08:44 -0000

This is a multi-part message in MIME format.
--------------010403020909070001000908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

Currently, in order to keep image property displayed on the receiver 
side if the sender rotates the phone (and the camera), it is needed that 
the sender rotates the image from WxH to HxW so it is sent in upward 
position over the wire. Also, if the receiver is a mobile phone and has 
it rotated, it will have to rotate it again to match the current phone 
orientation.

How about using Coordination of Video Orientation as in 3GPP TS 26.114 
(http://www.3gpp.org/ftp/Specs/html-info/26114.htm)?

Coordination of Video Orientation consists in signalling of the current 
orientation of the image captured on the sender side to the receiver for 
appropriate rendering and displaying. When CVO is succesfully negotiated 
it shall be signalled by the MTSI client. The signalling of the CVO uses 
RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte 
form of the header shall be used. CVO information for a 2 bit 
granularity of Rotation (corresponding to urn:3gpp:video-orientation) is 
carried as a byte formatted as follows:

Bit#76543210(LSB)
Definition0000CFR1R0

With the following definitions:

C = Camera: indicates the direction of the camera used for this video 
stream. It can be used by the MTSI client in receiver to e.g. display 
the received video differently depending on the source camera.

     0: Front-facing camera, facing the user. If camera direction is 
unknown by the sending MTSI client in the terminal then this is the 
default value used.

1: Back-facing camera, facing away from the user.

F = Flip: indicates a horizontal (left-right flip) mirror operation on 
the video as sent on the link.

0: No flip operation. If the sending MTSI client in terminal does not 
know if a horizontal mirror operation is necessary, then this is the 
default value used.

1: Horizontal flip operation

R1, R0 = Rotation: indicates the rotation of the video as transmitted on 
the link. The receiver should rotate the video to compensate that 
rotation. E.g. a 90° Counter Clockwise rotation should be compensated by 
the receiver with a 90° Clockwise rotation prior to displaying.

Table 7.2: Rotation signalling for 2 bit granularity

R1

	

R0

	

Rotation of the video as sent on the link

	

Rotation on the receiver before display

0

	

0

	

0° rotation

	

None

0

	

1

	

90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation

	

90° CW rotation

1

	

0

	

180° CCW rotation or 180° CW rotation

	

180° CW rotation

1

	

1

	

270° CCW rotation or 90° CW rotation

	

90° CCW rotation

CVO information for a higher granularity of Rotation (corresponding to 
urn:3GPP:video-orientation:6) is carried as a byteformatted as follows:**

Bit#76543210(LSB)
DefinitionR5R4R3R2CFR1R0

where Cand Fare as defined above and the bits R5,R4,R3,R2,R1,R0 
represent the Rotation, which indicates the rotation of the video as 
transmitted on the link. Table 7.3 describes the rotation to be applied 
by the receiver based on the rotation bits.

Table 7.3: Rotation signalling for 6 bit granularity

R1

	

R0

	

R5

	

R4

	

R3

	

R2

	

Rotation of the video as sent on the link

	

Rotation on the receiver before display

0

	

0

	

0

	

0

	

0

	

0

	

0° rotation

	

None

0

	

0

	

0

	

0

	

0

	

1

	

(360/64)° Counter Clockwise (CCW) rotation

	

(360/64)° CW rotation

0

	

0

	

0

	

0

	

1

	

0

	

(2*360/64)° CCW rotation

	

(2*360/64)° CW rotation

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

	

*.*

1

	

1

	

1

	

1

	

1

	

0

	

(62*360/64)° CCW rotation

	

(2*360/64)° CCW rotation

1

	

1

	

1

	

1

	

1

	

1

	

(63*360/64)° CCW rotation

	

(360/64)° CCW rotation

Best regards
Sergio


--------------010403020909070001000908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi all,

    

    Currently, in order to keep image property displayed on the 
    receiver side if the sender rotates the phone (and the camera), it
    is needed that the sender rotates the image from WxH to HxW so it is
    sent in upward position over the wire. Also, if the receiver is a
    mobile phone and has it rotated, it will have to rotate it again to
    match the current phone orientation.

    

    How about using  Coordination of Video Orientation as in 3GPP
    TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)? 

      

      Coordination of Video Orientation consists in signalling of the
      current orientation of the image captured on the sender side to
      the receiver for appropriate rendering and displaying. When CVO is
      succesfully negotiated it shall be signalled by the MTSI client.
      The signalling of the CVO uses RTP Header Extensions as specified
      in IETF RFC 5285 [95]. The one-byte form of the header shall be
      used. CVO information for a 2 bit granularity of Rotation
      (corresponding to urn:3gpp:video-orientation) is carried as a byte
      formatted as follows:
    
Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)

      Definition      0           0           0           0           C          F           R1          R0

    
With the following definitions:

    
C = Camera: indicates the direction of
        the camera used for this video stream. It can be used by the
        MTSI client in receiver to e.g. display the received video
        differently depending on the source camera.

    
    0: Front-facing camera, facing the user. If
        camera direction is unknown by the sending MTSI client in the
        terminal then this is the default value used.

    
1: Back-facing
        camera, facing away from the user.

    
F = Flip: indicates a horizontal (left-right flip)
        mirror operation on the video as sent on the link.

    
    0: No
        flip operation. If the sending MTSI client in terminal does not
        know if a horizontal mirror operation is necessary, then this is
        the default value used.

    
    1:
        Horizontal flip operation

    
R1, R0 = Rotation: indicates
        the rotation of the video as transmitted on the link. The
        receiver should rotate the video to compensate that rotation.
        E.g. a 90° Counter Clockwise rotation should be compensated by
        the receiver with a 90° Clockwise rotation prior to displaying.

    
Table 7.2: Rotation

        signalling for 2 bit granularity

    

      

        
          

            
              
R1

            		
            
              
R0

            		
            
              
Rotation of the video as sent on the link

            		
            
              
Rotation on the receiver before display

            		
          

          

            
              
0

            		
            
              
0

            		
            
              
0°
                  rotation

            		
            
              
None

            		
          

          

            
              
0

            		
            
              
1

            		
            
              
90°
                  Counter Clockwise (CCW) rotation or 270° Clockwise
                  (CW) rotation

            		
            
              
90° CW
                  rotation

            		
          

          

            
              
1

            		
            
              
0

            		
            
              
180° CCW
                  rotation or 180° CW rotation

            		
            
              
180° CW
                  rotation

            		
          

          

            
              
1

            		
            
              
1

            		
            
              
270° CCW
                  rotation or 90° CW rotation

            		
            
              
90° CCW
                  rotation

            		
          

        
      

    

    
 

    
CVO information for a higher
        granularity of Rotation (corresponding to
        urn:3GPP:video-orientation:6) is carried as a byte  formatted as follows:

    
Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)

      Definition      R5          R4          R3          R2          C          F           R1          R0

    
where C and F are as
        defined above and the bits R5,R4,R3,R2,R1,R0 represent the
        Rotation, which indicates the rotation of the video as
        transmitted on the link. Table 7.3 describes the rotation to be
        applied by the receiver based on the rotation bits.

    
Table 7.3: Rotation signalling for
        6 bit granularity

    

      

        
          

            
              
R1

            		
            
              
R0

            		
            
              
R5

            		
            
              
R4

            		
            
              
R3

            		
            
              
R2

            		
            
              
Rotation of the video as sent on the link

            		
            
              
Rotation on the receiver before display

            		
          

          

            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0°
                  rotation

            		
            
              
None

            		
          

          

            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
1

            		
            
              
(360/64)°
                  Counter Clockwise (CCW) rotation

            		
            
              
(360/64)°
                  CW rotation

            		
          

          

            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
0

            		
            
              
1

            		
            
              
0

            		
            
              
(2*360/64)°
                  CCW rotation

            		
            
              
(2*360/64)°
                  CW rotation

            		
          

          

            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
          

          

            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
          

          

            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
            
              
.

            		
          

          

            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
0

            		
            
              
(62*360/64)°
                  CCW rotation

            		
            
              
(2*360/64)°
                  CCW rotation

            		
          

          

            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
1

            		
            
              
(63*360/64)°
                  CCW rotation

            		
            
              
(360/64)°
                  CCW rotation

            		
          

        
      

    

    
 

    Best regards

    Sergio

    

  


--------------010403020909070001000908--

From martin.thomson@gmail.com  Sat Sep 28 15:53:27 2013
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 1B5E821F9CF3 for ; Sat, 28 Sep 2013 15:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5buVDmxb3-6 for ; Sat, 28 Sep 2013 15:53:19 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55611E8127 for ; Sat, 28 Sep 2013 15:53:13 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id l18so2093554wgh.4 for ; Sat, 28 Sep 2013 15:53:12 -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=Xf8BTvlD+S2ea+5ZKm2dM48Y+LN362HHk0rrN1hmBEs=; b=KlYUOGazalULbIOFsHGHWiHkgpSfnA8Csp95Rl+OnnFqIrpseKAFdmymKtNAQHo1/b Hqfgr9Mj2wpwEFlUCroBF7suV77XlAUTG/0tGJdzMqlHJyBLQrr9R6Tua9+GQCrOMJ5e Fn8qDufcnovGF19HVYSJFBQSe1YPGWX1RGuI0KBUkQ5x+aHtQJ6866bV0HQfQNLl2X82 wwAZ/Bj4PO1ua/Th8Hrd53s+yBNrAZNoeT88uQEEg06pOXBPqtvtLftGlniER9Qqq8/n EG/tG4lvurYNYbRQm0KMI2nP27pgLFny6aY5j6yOW5HmsOJfI80TVse4oFFr7Inq5Q7O hbJg==
MIME-Version: 1.0
X-Received: by 10.180.187.2 with SMTP id fo2mr7766164wic.65.1380408792751; Sat, 28 Sep 2013 15:53:12 -0700 (PDT)
Received: by 10.194.158.227 with HTTP; Sat, 28 Sep 2013 15:53:12 -0700 (PDT)
Received: by 10.194.158.227 with HTTP; Sat, 28 Sep 2013 15:53:12 -0700 (PDT)
In-Reply-To: <5244104D.4010401@alvestrand.no>
References:  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>   <5244104D.4010401@alvestrand.no>
Date: Sat, 28 Sep 2013 15:53:12 -0700
Message-ID: 
From: Martin Thomson 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=001a11c38c82bca43404e7797707
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 28 Sep 2013 22:53:27 -0000

--001a11c38c82bca43404e7797707
Content-Type: text/plain; charset=UTF-8

On Sep 26, 2013 8:46 PM, "Harald Alvestrand"  wrote:
> So far, neither the POSIX standard nor any OS vendor has offered a
generic facility to access information made available in DHCP packets.

Actually, Windows does provide an API for this exact purpose, it's just not
particularly well-suited to what geopriv needed, i.e. getting changing
values. It is good enough for the purpose we are taking about. That isn't
much help for other operating systems, I'll concede.

Applications can send their own DHCP requests...maybe. You need to listen
on port 69 (from memory) for which you have to have the usual special
dispensation, and you have to compete with the OS DHCP agent. It's not
pretty either way.

--001a11c38c82bca43404e7797707
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> So far, neither the POSIX standard nor any OS vendor has offered a gen=
eric facility to access information made available in DHCP packets.


Actually, Windows does provide an API for this exact purpose=
, it's just not particularly well-suited to what geopriv needed, i.e. g=
etting changing values. It is good enough for the purpose we are taking abo=
ut. That isn't much help for other operating systems, I'll concede.=




Applications can send their own DHCP requests...maybe. You n=
eed to listen on port 69 (from memory) for which you have to have the usual=
 special dispensation, and you have to compete with the OS DHCP agent. It&#=
39;s not pretty either way.





--001a11c38c82bca43404e7797707--

From bernard_aboba@hotmail.com  Sat Sep 28 17:40:52 2013
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 BBC3621E8141 for ; Sat, 28 Sep 2013 17:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level: 
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIcYd1oP1+vp for ; Sat, 28 Sep 2013 17:40:47 -0700 (PDT)
Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id D11FE21E8138 for ; Sat, 28 Sep 2013 17:40:46 -0700 (PDT)
Received: from BLU169-W98 ([65.55.116.8]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 28 Sep 2013 17:40:46 -0700
X-TMN: [6PkYO/dt+YPxT6JhR/8Zicij7M7i46qV]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_c98599e2-c4f1-43c2-85ed-6b1c12957b25_"
From: Bernard Aboba 
To: Harald Alvestrand 
Date: Sat, 28 Sep 2013 17:40:46 -0700
Importance: Normal
In-Reply-To: 
References: , <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>, , , <5244104D.4010401@alvestrand.no>, 
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Sep 2013 00:40:46.0717 (UTC) FILETIME=[8979A2D0:01CEBCAC]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 29 Sep 2013 00:40:52 -0000

--_c98599e2-c4f1-43c2-85ed-6b1c12957b25_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Sep 26=2C 2013 8:46 PM=2C "Harald Alvestrand"  wro=
te:
"So far=2C neither the POSIX standard nor any OS vendor has offered a gener=
ic facility to access information made available in DHCP packets."
[BA] The Windows DHCP client API does provide this: http://msdn.microsoft.c=
om/en-us/library/windows/desktop/aa363351(v=3Dvs.85).aspx
In particular=2C the SendParams argument to the DhcpRequestParams function =
can be used to request a particular parameter (e.g. TURN server address)=2C=
 which will then be returned in the RecdParams variable. =20
Nevertheless=2C I still think that using DHCP to configure the TURN server =
address in a browser isn't a good idea.  For one thing=2C since DHCP is eff=
ectively unsecured=2C this mechanism could be used by a rogue DHCP server t=
o force traffic to a rogue turnserver.   Great for surveillance!
 		 	   		  =

--_c98599e2-c4f1-43c2-85ed-6b1c12957b25_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





On Sep 26=2C 2013=
 8:46 PM=2C "Harald Alvestrand" <=3Bharald@alvestrand.no>=3B wrote:
"So far=2C neither the POSIX st=
andard nor any OS vendor has offered a generic facility to access informati=
on made available in DHCP packets."

[BA] The Windows DHCP client API does provide this: =3B
http://msdn.microsoft.com/en-us/li=
brary/windows/desktop/aa363351(v=3Dvs.85).aspx

In particular=2C the SendParams argument to the DhcpReques=
tParams function =3Bcan be used to r=
equest a particular parameter (e.g. TURN server address)=2C which will then=
 be returned in the RecdParams variable.  =3B
=

Nevertheless=2C I still think that using DHCP to c=
onfigure the TURN server address in a browser isn't a good idea.  =3BFor one thing=2C since DHCP is effe=
ctively unsecured=2C this mechanism could be used by a rogue DHCP server to=
 force traffic to a rogue turnserver.  =3B Great for surveillance!

 		 	   		  

=

--_c98599e2-c4f1-43c2-85ed-6b1c12957b25_--

From jlaurens@cisco.com  Sat Sep 28 17:49:48 2013
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 2274421E813F for ; Sat, 28 Sep 2013 17:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LNjBXrnbXSB for ; Sat, 28 Sep 2013 17:49: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 E292421F9B91 for ; Sat, 28 Sep 2013 17:49:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4327; q=dns/txt; s=iport; t=1380415782; x=1381625382; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=opMLxF7r6RNmVoI//ExHvWUoRTntal6E1HnkeTmQ+uE=; b=XNMVCUv/KRpTts2i0ndbIrdL8TpazvA1SL+632Iy3DHDQ+1SWQpMI5hh 52f5D0ZRd4cv5fGbSBCkxre8NVVxqA0rYjhPkecLbji4Mx8IRvGlBDgOH aCvj4s/CUaMLmrLoI2PN36cxIUck0zwLItBMGo/r9YT1YtM03HwdMXkhi o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAFAIp4R1KtJV2d/2dsb2JhbABZgkNEOK5uihSHeEqBIRZtB4ImAQEEAQEBaxsCAQgEOwcnCxQDAQ0CBBOHdAMPDLpPjGaCZwuDH4EDA5YXgWiBL4sWhTSBZoE+
X-IronPort-AV: E=Sophos;i="4.90,1002,1371081600";  d="scan'208,217";a="265772926"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 29 Sep 2013 00:49:40 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8T0neQW021151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 29 Sep 2013 00:49:40 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sat, 28 Sep 2013 19:49:40 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOvKyWX1UMcPyVcEy1G/MdfbXyXJnb4jVy
Date: Sun, 29 Sep 2013 00:49:40 +0000
Message-ID: <3CD8C0AB-3E69-4E95-9ED7-198AA4568A25@cisco.com>
References: ,  <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>, , , <5244104D.4010401@alvestrand.no>, , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_3CD8C0AB3E694E959ED7198AA4568A25ciscocom_"
MIME-Version: 1.0
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 29 Sep 2013 00:49:48 -0000

--_000_3CD8C0AB3E694E959ED7198AA4568A25ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Why not have this at least optionally specified in JavaScript in the browse=
r? This way those who "own" the apps have control and aren't relying on cor=
rect implementation of others (necessarily)

On Sep 28, 2013, at 8:41 PM, "Bernard Aboba" > wrote:


On Sep 26, 2013 8:46 PM, "Harald Alvestrand" > wrote:
"So far, neither the POSIX standard nor any OS vendor has offered a generic=
 facility to access information made available in DHCP packets."


[BA] The Windows DHCP client API does provide this:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.85)=
.aspx


In particular, the SendParams argument to the DhcpRequestParams function ca=
n be used to request a particular parameter (e.g. TURN server address), whi=
ch will then be returned in the RecdParams variable.


Nevertheless, I still think that using DHCP to configure the TURN server ad=
dress in a browser isn't a good idea.  For one thing, since DHCP is effecti=
vely unsecured, this mechanism could be used by a rogue DHCP server to forc=
e traffic to a rogue turnserver.   Great for surveillance!


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

--_000_3CD8C0AB3E694E959ED7198AA4568A25ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Why not have this at least optionally specified in JavaScript in the b=
rowser? This way those who "own" the apps have control and aren't=
 relying on correct implementation of others (necessarily)






On Sep 28, 2013, at 8:41 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:












On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <<=
a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> wrote:<=
br>
"So far, neither the POSIX standard nor any OS vendor has offered a ge=
neric facility to access information made available in DHCP packets."<=
/p>






[BA] The Windows DHCP client API does provide this: 

http://msdn.microsoft.co=
m/en-us/library/windows/desktop/aa363351(v=3Dvs.85).aspx







In particular, the SendParams argument to the DhcpRequestPar=
ams function can be used to request a=
 particular parameter (e.g. TURN server address), which will then be return=
ed in the RecdParams variable.  







Nevertheless, I still think=
 that using DHCP to configure the TURN server address in a browser isn't a =
good idea.  For one thing, sin=
ce DHCP is effectively unsecured, this mechanism
 could be used by a rogue DHCP server to force traffic to a rogue turnserve=
r.   Great for surveillance!















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.=
ietf.org/mailman/listinfo/rtcweb








--_000_3CD8C0AB3E694E959ED7198AA4568A25ciscocom_--

From christer.holmberg@ericsson.com  Mon Sep 30 01:08:32 2013
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 BCECD21F9D42 for ; Mon, 30 Sep 2013 01:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.673
X-Spam-Level: 
X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgWfW65W8mbD for ; Mon, 30 Sep 2013 01:08:25 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5678E21F9D1C for ; Mon, 30 Sep 2013 01:08:08 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-ba-52493167f9ca
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E9.00.22048.76139425; Mon, 30 Sep 2013 10:08:07 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 30 Sep 2013 10:07:48 +0200
From: Christer Holmberg 
To: "rtcweb@ietf.org" 
Thread-Topic: JSEP: Order of m- lines in multiple PeerConnections
Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/A==
Date: Mon, 30 Sep 2013 08:07:47 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AFB57ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvrW66oWeQwZKlYhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/H+mIKdyhWdLUINjOfkuhg5OSQETCTafq9mh7DFJC7cW8/W xcjFISRwmFFi++9XLBDOEkaJT09Xs3YxcnCwCVhIdP/TBmkQEVCXuPzwAlizsICNxIxFncwQ cUeJrTs+M0HYehIfrrcwgbSyCKhKTN9pCBLmFfCV2LF3G1grI9De76fWgJUzC4hL3Hoynwni HgGJJXvOM0PYohIvH/9jhbAVJT6+2scIUZ8vcfLtV2aImYISJ2c+YZnAKDQLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLzTcxAgP+4JbfBjsYN90XO8Qo zcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGxjDNMN1Zxy8cPPRA5nriBc/5 cqceGrRuWKTgIzSVceMUpkuHNVliX8Yzpfim72y+nBvMrXTGb3rZl/QHK9L7tqsuXOEjwiX/ xrDBy+B8s4ul7FkBK6v8xpuJfgZXJQM+bntukj/pc3zpsp+ubf//Ce7zE7O/lip0xKmw7lLJ l142Da4Q34dKLMUZiYZazEXFiQD3p5d+RgIAAA==
Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
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, 30 Sep 2013 08:08:32 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4AFB57ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

JSEP talks about the usage of multiple PeerConnection to support forking, i=
.e. for each new forked leg (SIP: early dialog) a new PeerConnection is cre=
ated.

As has been indicated, as each new PeerConnection will have its own set of =
address properties, ICE properties etc, so a new Offer will have to be crea=
ted and sent to inform the remote about the new properties.

So far so I good.

I also assume that the same camera/mic/etc sources are connection to each P=
eerConnection, so the number of m- lines in the Offer of the new PeerConnec=
tion should be the same.

However, according the 3264, the ORDER of the m- lines also need to be kept=
 the same.

So, my question is: how can I ensure that the order of the m- lines in an O=
ffer for a new PeerConnection is the same as in an Offer for an old PeerCon=
nection?

Regards,

Christer


--_000_7594FB04B1934943A5C02806D1A2204B1C4AFB57ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


JSEP talks about the usage of multiple PeerConnectio=
n to support forking, i.e. for each new forked leg (SIP: early dialog) a ne=
w PeerConnection is created.


 


As has been indicated, as each new PeerConnection wi=
ll have its own set of address properties, ICE properties etc, so a new Off=
er will have to be created and sent to inform the remote about the new prop=
erties.


 


So far so I good.


 


I also assume that the same camera/mic/etc sources a=
re connection to each PeerConnection, so the number of m- lines in the Offe=
r of the new PeerConnection should be the same.


 


However, according the 3264, the ORDER of the m- =
lines also need to be kept the same.


 


So, my question is: how can I ensure that the order =
of the m- lines in an Offer for a new PeerConnection is the same as in an O=
ffer for an old PeerConnection?


 


Regards,


 


Christer


 






--_000_7594FB04B1934943A5C02806D1A2204B1C4AFB57ESESSMB209erics_--

From kevindempsey70@gmail.com  Mon Sep 30 01:51:07 2013
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 848BF21F9C8B for ; Mon, 30 Sep 2013 01:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgbFx+cCW6e3 for ; Mon, 30 Sep 2013 01:51:06 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E400521F9C8E for ; Mon, 30 Sep 2013 01:51:04 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id x18so4281995lbi.3 for ; Mon, 30 Sep 2013 01:51: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=HdHgAEApyMOw626H4WSfOZcaJ4hmx1S4/MreMGxpqTM=; b=l/OtGE1iqcaHxjZ+P1ZtEUQerrF50OaXypcoLDSqwsNfWRE3mO7jN6XYBKydKzy7Y/ wIF+vCh+3S7s+zVha0fpP/N4cRFRlCTXv9sxif/vmUgS2vBCFauDTfmNhXBPIzK5YLGj 6AqnmQ+JXfVLwNM01bsAJrgTVgBeScOO+ce6wA6Mx640UylY2y2eorD2jniPlbdCKiZQ M4kRH5cWzoeALLND/8IskHL48DsomFvAxreIdN+rfsYIO0BxZacB64Rm8AovwydLLqG+ BFNc+UU7m/6UyOiMm+++IZ0SDeXYsc0O+t5dvCZaPh0Y1s6UaWBKg3TswAjGcK3YSa9D p44A==
MIME-Version: 1.0
X-Received: by 10.112.167.66 with SMTP id zm2mr722587lbb.46.1380531058875; Mon, 30 Sep 2013 01:50:58 -0700 (PDT)
Received: by 10.114.181.226 with HTTP; Mon, 30 Sep 2013 01:50:58 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AE733@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>   <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4AE733@ESESSMB209.ericsson.se>
Date: Mon, 30 Sep 2013 09:50:58 +0100
Message-ID: 
From: Kevin Dempsey 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=001a11c38ba25da19f04e795ef1a
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 30 Sep 2013 08:51:07 -0000

--001a11c38ba25da19f04e795ef1a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Can someone explain why the proto field is 'RTP/SAVPF' rather than
'UDP/TLS/RTP/SAVPF'?
We are using DTLS-SRTP after all.



On 28 September 2013 07:52, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
>>     >>>>> Q_3:      RTP
>> >>>>>
>> >>>>> The text says:
>> >>>>>
>> >>>>> =93The  field MUST be set to "RTP/SAVPF". =93
>> >>>>>
>> >>>>> But, that of course only applies to RTP based streams (not the dat=
a
>> channel). Also, in general, it needs to be clear what information
>> >>>>> needs to be in every m- line, and what information is protocol
>> specific. I would suggest to have a =93General=94 sub-section, a =93RTP=
=94
>> sub-section, etc.
>> >>>>>
>> >>>>>
>> >>>> Yep - I think this should be offers are created with RTP/SAVPF for
>> audio and video and system can reeve offers with SAVPF or SAVP
>> >>>
>> >>> Currently the document specifies what to do with media lines, with
>> later discussion of handling the SCTP line. Do you think the current
>> information is not sufficiently descriptive?
>> >>
>>  >> My point was that we need to be more clear on what is generic, what
>> is RTP, and what is SCTP. But, as you say SCTP text is still to be added=
,
>> that clarification can be done when the SCTP text is added.
>>
>
>  >Sorry I was unclear - there is SCTP-specific text in the current
> document.
>
> Ok, so while the content itself might be ok, at some point I'd like to
> have separate sub-sections for the generic stuff, the RTP specicif stuff,
> and the SCTP specific stuff.
>
>
>
>>     >>>>> Q_6:      BUNDLE
>> >>>>>
>> >>>>> We=92ll probably also need some text about BUNDLE.
>> >>>>>
>> >>>>
>>
>> >>>> yep - but plan is to match up with unified plan
>> >>>>
>> >>>Can you be specific about what more you think needs to be said? The
>> createAnswer treatment of BUNDLE is one clear thing that is currently
>> missing.
>>
>> >>
>>
>> >> I want to have text covering both the 1st (unique address) and 2nd
>> (shared address) Offer.
>>
> > Acknowledged.
>
>>    >
>>
>> >> And, when a PeerConnection is created due to forking (ie you use a
>> separate PeerConnection for each forked leg of a session), I assume
>>
>> >> already the 1st Offer for that PeerConnection can have a shared
>> address (as the remote entity has indicated support for BUNDLE). That al=
so
>> needs to be covered.
>>
>> >>
>>
> > Yes. Which may indicate the need for a setting on a PeerConnection to
> use a shared address on the initial offer, since it might have come from
> such a fork.
>
> Excellent.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c38ba25da19f04e795ef1a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Can someone explain why the proto field is 'RTP/SAVPF&=
#39; rather than 'UDP/TLS/RTP/SAVPF'? We are using DTLS-SRTP after all.
=





On 28 September 2013 07:52, Christer Holmberg <<=
a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer=
.holmberg@ericsson.com> wrote:












Hi,


=A0


























>>>>> Q_3: =A0 =A0 =A0RTP

>>>>>

>>>>> The text says:

>>>>>

>>>>> =93The <proto> field MUST be set to "RTP/SA=
VPF". =93

>>>>>

>>>>> But, that of course only applies to RTP based streams =
(not the data channel). Also, in general, it needs to be clear what informa=
tion


>>>>>=A0needs to be in every m- line, and what informat=
ion is protocol specific. I would suggest to have a =93General=94 sub-secti=
on, a =93RTP=94 sub-section, etc.

>>>>>

>>>>>


>>>> Yep - I think this should be offers are created with =
RTP/SAVPF for audio and video and system can reeve offers with SAVPF or SAV=
P

>>>


>>> Currently the document specifies what to do with media li=
nes, with later discussion of handling the SCTP line. Do you think the curr=
ent information is not sufficiently descriptive?=A0


>>




>> My point was that we need to be more clear on what is generic=
, what is RTP, and what is SCTP. But, as you say SCTP text is still to be a=
dded, that clarification can be done when the SCTP text is added.






















>Sorry I was unclear - there is SCTP-specific text in the current d=
ocument.=A0


=A0


Ok, so while the content itself might be ok, at some point I'=
;d like to have separate sub-sections for the generic stuff, the RTP specic=
if stuff, and the SCTP specific stuff.



=A0


=A0=A0


















>>>>> Q_6: =A0 =A0 =A0BUNDLE

>>>>>

>>>>> We=92ll probably also need some text about BUNDLE.

>>>>>

>>>>


>>>> yep - but plan is to match up with unified plan

>>>>

>>>Can you be specific about what more you think needs to be said?=
 The createAnswer treatment of BUNDLE is one clear thing that is currently =
missing.


>>=A0




>> I want to have text covering both=A0the 1st (unique address) an=
d 2nd (shared address) Offer.
















> Acknowledged.=A0


















>=A0


>> And, when a PeerConnection is created due to forking (ie you us=
e a separate PeerConnection for each forked leg of a session), I assume



>> already the 1st Offer for that PeerConnection can have a shared=
 address (as the remote entity has indicated support for BUNDLE). That also=
 needs to be covered.


>>
















> Yes. Which may indicate the need for a setting on a PeerConnectio=
n to use a shared address on the initial offer, since it might have come fr=
om such a fork.=A0


=A0


Excellent.


=A0


Regards,


=A0


Christer


=A0















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c38ba25da19f04e795ef1a--

From christer.holmberg@ericsson.com  Mon Sep 30 02:49:51 2013
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 E3E9921F90E5 for ; Mon, 30 Sep 2013 02:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.679
X-Spam-Level: 
X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.569,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYFV1jFXYtZm for ; Mon, 30 Sep 2013 02:49:45 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E197A21F8F07 for ; Mon, 30 Sep 2013 02:49:42 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-da-524949357482
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F8.B4.03802.53949425; Mon, 30 Sep 2013 11:49:41 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 30 Sep 2013 11:49:39 +0200
From: Christer Holmberg 
To: Kevin Dempsey 
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnZyWEAgAAwyzyAAAVFB4AACS8AgAC38feAAAGv7YADJDgAgAAwKQA=
Date: Mon, 30 Sep 2013 09:49:38 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AFDAF@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>   <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4AE733@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AFDAFESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvra6pp2eQwbFJJhYdk9kstk4Vsrg5 /y2Lxdp/7ewOLB5Tfm9k9dg56y67x4JNpR5LlvxkCmCJ4rJJSc3JLEst0rdL4Mo4sr6PueB+ fcW7D+/ZGhiPF3QxcnJICJhIfN7znBXCFpO4cG89WxcjF4eQwGFGiZ0vZzJBOEsYJb6e3sLS xcjBwSZgIdH9TxukQURAR+Lg/cnsIDazQI3E2aZ3YLawQLTEoxUT2SBqYiR2nf/CAmEnSSxc d4IRxGYRUJW40bwVzOYV8JXY/2gP1OK3zBIz780FG8QpEChxvfc0mM0IdN33U2uYIJaJS9x6 Mp8J4moBiSV7zjND2KISLx//g/pGUeLjq32MEPX5EjvOnYVaJihxcuYTlgmMorOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73caBMjMO4ObvmtuoPxzjmR Q4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBs2KB+9LPtF6kLcqkxC5/8 2SIcmi6vdSrvyZQZZ59NfjyB3aB2xYH3K7ijNt4WMl7ou/OzyWn11pU9WsGmKTpJ96omaM0K eXD7wJPndw957LSqe8O6rUBtvsiKxxVhL2SNrsw5G3MzXcfKd1tNW19u1btym7/b4n9ZGwme 5/UJXhupfX3PsSnCSizFGYmGWsxFxYkAVj7s+IkCAAA=
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 30 Sep 2013 09:49:51 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4AFDAFESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Kevin,

I agree. According to RFC 5763 the correct value is UDP/TLS/RTP/SAVP.

Regards,

Christer

From: Kevin Dempsey [mailto:kevindempsey70@gmail.com]
Sent: 30. syyskuuta 2013 11:51
To: Christer Holmberg
Cc: Justin Uberti; Cullen Jennings (fluffy); rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (1=
9th september)

Can someone explain why the proto field is 'RTP/SAVPF' rather than 'UDP/TLS=
/RTP/SAVPF'? We are using DTLS-SRTP after all.


On 28 September 2013 07:52, Christer Holmberg > wrote:

Hi,


>>>>> Q_3:      RTP
>>>>>
>>>>> The text says:
>>>>>
>>>>> "The  field MUST be set to "RTP/SAVPF". "
>>>>>
>>>>> But, that of course only applies to RTP based streams (not the data c=
hannel). Also, in general, it needs to be clear what information
>>>>> needs to be in every m- line, and what information is protocol specif=
ic. I would suggest to have a "General" sub-section, a "RTP" sub-section, e=
tc.
>>>>>
>>>>>
>>>> Yep - I think this should be offers are created with RTP/SAVPF for aud=
io and video and system can reeve offers with SAVPF or SAVP
>>>
>>> Currently the document specifies what to do with media lines, with late=
r discussion of handling the SCTP line. Do you think the current informatio=
n is not sufficiently descriptive?
>>
>> My point was that we need to be more clear on what is generic, what is R=
TP, and what is SCTP. But, as you say SCTP text is still to be added, that =
clarification can be done when the SCTP text is added.

>Sorry I was unclear - there is SCTP-specific text in the current document.

Ok, so while the content itself might be ok, at some point I'd like to have=
 separate sub-sections for the generic stuff, the RTP specicif stuff, and t=
he SCTP specific stuff.



>>>>> Q_6:      BUNDLE
>>>>>
>>>>> We'll probably also need some text about BUNDLE.
>>>>>
>>>>

>>>> yep - but plan is to match up with unified plan
>>>>
>>>Can you be specific about what more you think needs to be said? The crea=
teAnswer treatment of BUNDLE is one clear thing that is currently missing.

>>

>> I want to have text covering both the 1st (unique address) and 2nd (shar=
ed address) Offer.
> Acknowledged.

>

>> And, when a PeerConnection is created due to forking (ie you use a separ=
ate PeerConnection for each forked leg of a session), I assume

>> already the 1st Offer for that PeerConnection can have a shared address =
(as the remote entity has indicated support for BUNDLE). That also needs to=
 be covered.

>>
> Yes. Which may indicate the need for a setting on a PeerConnection to use=
 a shared address on the initial offer, since it might have come from such =
a fork.

Excellent.

Regards,

Christer


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


--_000_7594FB04B1934943A5C02806D1A2204B1C4AFDAFESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Kevin,


 <=
/p>

I agree. According to
RFC 5763 the correct value is UDP/TLS/RTP/SAVP.


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>

From: Kevin De=
mpsey [mailto:kevindempsey70@gmail.com]


Sent: 30. syyskuuta 2013 11:51

To: Christer Holmberg

Cc: Justin Uberti; Cullen Jennings (fluffy); rtcweb@ietf.org

Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5=
.2.2 (19th september)


 




Can someone explain why the proto field is 'RTP/SAVP=
F' rather than 'UDP/TLS/RTP/SAVPF'? We are using DTLS-SRTP after all.=





 








 




On 28 September 2013 07:52, Christer Holmberg <christer.=
holmberg@ericsson.com> wrote:






Hi,


 






























>>>>> Q_3:     =
 RTP

>>>>>

>>>>> The text says:

>>>>>

>>>>> “The <proto> field MUST be set to "RT=
P/SAVPF". “

>>>>>

>>>>> But, that of course only applies to RTP based streams =
(not the data channel). Also, in general, it needs to be clear what informa=
tion






>>>>> needs to be in=
 every m- line, and what information is protocol specific. I would suggest =
to have a “General” sub-section, a “RTP” sub-sectio=
n, etc.

>>>>>

>>>>>






>>>> Yep - I think this shou=
ld be offers are created with RTP/SAVPF for audio and video and system can =
reeve offers with SAVPF or SAVP

>>>






>>> Currently the document spec=
ifies what to do with media lines, with later discussion of handling the SC=
TP line. Do you think the current information is not sufficiently
 descriptive? 






>> 








>> My point was that we need to be=
 more clear on what is generic, what is RTP, and what is SCTP. But, as you =
say SCTP text is still to be added, that clarification can be
 done when the SCTP text is added.




















 






>Sorry I was unclear - there is SCTP-=
specific text in the current document. 






 








Ok, so while the content itself might be=
 ok, at some point I'd like to have separate sub-sections for the generic s=
tuff, the RTP specicif stuff, and the SCTP specific stuff.









 






  




















>>>>> Q_6:      BUNDLE

>>>>>

>>>>> We’ll probably also need some text about BUNDLE.=


>>>>>

>>>>


>>>> yep - but plan is to match up with unified =
plan

>>>>

>>>Can you be specific about what more you think needs to be said?=
 The createAnswer treatment of BUNDLE is one clear thing that is currently =
missing.


>> 




>> I want to have text covering both the 1st (uni=
que address) and 2nd (shared address) Offer.


















> Acknowledged. 


















> 


>> And, when a PeerConnection is created due to forkin=
g (ie you use a separate PeerConnection for each forked leg of a session), =
I assume



>> already the 1st Offer for that PeerConnection can h=
ave a shared address (as the remote entity has indicated support for BUNDLE=
). That also needs to be covered.


>> 


















> Yes. Which may indicate the need fo=
r a setting on a PeerConnection to use a shared address on the initial offe=
r, since it might have come from such a fork. 






 








Excellent.






 






Regards,






 





Christer=







 

















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb




 








--_000_7594FB04B1934943A5C02806D1A2204B1C4AFDAFESESSMB209erics_--

From uwe.rauschenbach@nsn.com  Mon Sep 30 08:28:27 2013
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 A2DF021F9C8B for ; Mon, 30 Sep 2013 08:28:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe7o-GAKYR73 for ; Mon, 30 Sep 2013 08:28:22 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4571F21F88FB for ; Mon, 30 Sep 2013 08:28:22 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r8UFSKI2013903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Sep 2013 17:28:20 +0200
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r8UFSKB9004616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Sep 2013 17:28:20 +0200
Received: from DEMUHTC016.nsn-intra.net (10.159.42.47) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Sep 2013 17:28:19 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC016.nsn-intra.net ([10.159.42.47]) with mapi id 14.03.0123.003; Mon, 30 Sep 2013 17:28:19 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" 
To: "rtcweb@ietf.org" 
Thread-Topic: No a=ice-lite in JSEP-04
Thread-Index: Ac698bCDm/FvoM3PQXG8Sb8kVVaqug==
Date: Mon, 30 Sep 2013 15:28:18 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.97]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 409
X-purgate-ID: 151667::1380554900-00004A43-DB7A91F8/0-0/0-0
Subject: [rtcweb] No a=ice-lite in JSEP-04
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, 30 Sep 2013 15:28:27 -0000

Hi Justin, Cullen,

JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is incompat=
ible with I-D.ietf-rtcweb-rtp-usage.
Can you point out which specific aspect of this draft ICE Lite is incompati=
ble with?

In deployments where one endpoint is a browser and another one is a gateway=
 connected to the public Internet, it makes sense to allow ICE lite.

=A0
Kind regards,
Uwe=20


From ibc@aliax.net  Mon Sep 30 08:33:10 2013
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 3D8A921F9C46 for ; Mon, 30 Sep 2013 08:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMqGJ7thlnBG for ; Mon, 30 Sep 2013 08:33:05 -0700 (PDT)
Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0508121F8887 for ; Mon, 30 Sep 2013 08:33:04 -0700 (PDT)
Received: by mail-qe0-f46.google.com with SMTP id x7so3917465qeu.33 for ; Mon, 30 Sep 2013 08:33:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9kdqg0YwL7bJL1p0RX7WLAxgKDrza9VCee0FmOqZ9JA=; b=dEEzp4/AmCHAuYXiP0o8+liwfmLD0lkJ69hoyaGQgClk+s/MrHFcnSGdn3sqtbNUWJ ML+ZuEIUvcwJNd4QrDdAnR4iO//I62tewmvDlFxudoZhJa8bJfhoH79IDQQXuLrJMOU0 9rIhHPT7j+k5bRdsfGWFqbYHd1wian8FKYk1o2SxxKl7TdPeyiNmxUzKlU7oZDhJ8MDN wlWH6Jkkfos2kxYmxWkhONRC1KteomV3QGTGldJc3ydtNV8cES1TVNKNWpuoCh44ACIJ f6PEy8S1heXhci0+uAB2l5v/vsmYrIifbwqaSo6DpjOIGZQHsuoTB+pSSzVxbyNhkDZz OLsg==
X-Gm-Message-State: ALoCoQlj4OZ4JahxsX2sNNC/l29f2rUPs9Uoypxo44YYMHN9k5S9hose8P8y4b+L27nE9EFLYmgT
X-Received: by 10.224.135.193 with SMTP id o1mr2734914qat.114.1380555184464; Mon, 30 Sep 2013 08:33:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.16.71 with HTTP; Mon, 30 Sep 2013 08:32:43 -0700 (PDT)
In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net>
References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 30 Sep 2013 17:32:43 +0200
Message-ID: 
To: "Rauschenbach, Uwe (NSN - DE/Munich)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04
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, 30 Sep 2013 15:33:10 -0000

2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) :
> JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is incomp=
atible with I-D.ietf-rtcweb-rtp-usage.
> Can you point out which specific aspect of this draft ICE Lite is incompa=
tible with?
>
> In deployments where one endpoint is a browser and another one is a gatew=
ay connected to the public Internet, it makes sense to allow ICE lite.

Without reading JSEP-04 I expect that it is not allowed for a web
browser to indicate "a=3Dice-lite", but a server can do that. Anyhow,
AFAIR the usage of ICE lite is fully transparent for the non ICE lite
endpoint.


--=20
I=C3=B1aki Baz Castillo


From juberti@google.com  Mon Sep 30 15:30:30 2013
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 37B5421F9AA1 for ; Mon, 30 Sep 2013 15:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.752
X-Spam-Level: 
X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0JIFwppLEhZ for ; Mon, 30 Sep 2013 15:30:29 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6D21F8F3C for ; Mon, 30 Sep 2013 15:30:29 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id aq17so11972975iec.13 for ; Mon, 30 Sep 2013 15:30:29 -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; bh=H89WXXkKbm1Pk85PvtEb/ZF7etfN20Xr5pTt8IpQRCw=; b=cO3F9kJjrJXICWHz+ymsbgX64AUhxFCPWWJtf8zNDUROHrZg9zGWdJrz22haMij4fy XZXK9lSuWob2w3rNDbkWFWh96Dnhriro5b40EsNwf2O96vxcB65jkJvewUpT2nS1RV3G Du3WZ4a87ZH5mM2sPfEdKHjwiSyZly857uIN1+xx6EXOeMxB5ZnLnVK8wVSYnZpYBUPR IG6dZlV//maOVfWocx8ytwYPRHQmPIIIC3wvCIOkWyZnIvds167+YtuPdkC6g2AcftaA kl8mMd60gDyukgZl8+iCiHhD5NYIIhyX7ULSDDK4Zu1WUCQOqLJaZ5PbzqNA+4SMDDFJ NRCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H89WXXkKbm1Pk85PvtEb/ZF7etfN20Xr5pTt8IpQRCw=; b=CIu7lU6IKwCuOR5aIOjbG8isenoIkOeNxE9z/gEnhOIT3qioy9kC+frg/rZwLeBolz 4j1r5mOCNIkF/QfjTX3i71eBd/59GYRWolIyfyEaneLCSLhbOnSm8oyR0h2yYUm+d0FX tI5nJeHWeITYN8elNBL/W1XLtLIABFwFE4zK39LFUIVfV7ml0/XhO+Bdx0fCGET90Smu N1RFazRG9RsCgODhdFKzZckmeVoepm8Sacit/xsPWOstfimVfSQL+uU3k4QFcKea6TUY ST5Y+FjTiEuixjj95JFuYTjB/GtNC1RTsJhccnM9Yc0Y5t0T1BtE5YG01RCtzCPRMc8+ jjeQ==
X-Gm-Message-State: ALoCoQlQS5l5kBBk8MWaXB8mUoo3Hzbd1fJBFOa4br5vQmfTz2usnZVwKxLuCylqNCV0L/mCiNsMLqAz67mSjrP5o5mJ25Qhhhh/g51HjS0GhKvOL5PE7JD9S6/3LctHINJ3GBE9374JvAvB/7LNBolDbpTojhxjTqnwSAzgggcDS70PuVJZY4WT/pUb33Wp1fY/YwBfd2Kf
X-Received: by 10.42.250.201 with SMTP id mp9mr18236955icb.0.1380580228884; Mon, 30 Sep 2013 15:30:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.104 with HTTP; Mon, 30 Sep 2013 15:30:08 -0700 (PDT)
In-Reply-To: 
References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> 
From: Justin Uberti 
Date: Mon, 30 Sep 2013 15:30:08 -0700
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=20cf300e529d20898404e7a16250
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04
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, 30 Sep 2013 22:30:30 -0000

--20cf300e529d20898404e7a16250
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes. In the offers and answers that WebRTC endpoints create, a=3Dice-lite i=
s
prohibited, since WebRTC endpoints must support "Full" ICE.

The remote endpoint may of course support only ICE Lite, and WebRTC
implementations must work properly with such endpoints.

This isn't normatively indicated anywhere that I could find, so I plan to
add specifics on this to the next version of JSEP.




On Mon, Sep 30, 2013 at 8:32 AM, I=C3=B1aki Baz Castillo  wr=
ote:

> 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) :
> > JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is
> incompatible with I-D.ietf-rtcweb-rtp-usage.
> > Can you point out which specific aspect of this draft ICE Lite is
> incompatible with?
> >
> > In deployments where one endpoint is a browser and another one is a
> gateway connected to the public Internet, it makes sense to allow ICE lit=
e.
>
> Without reading JSEP-04 I expect that it is not allowed for a web
> browser to indicate "a=3Dice-lite", but a server can do that. Anyhow,
> AFAIR the usage of ICE lite is fully transparent for the non ICE lite
> endpoint.
>
>
> --
> I=C3=B1aki Baz Castillo
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--20cf300e529d20898404e7a16250
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes. In the offers and answers that WebRTC endpoints creat=
e, a=3Dice-lite is prohibited, since WebRTC endpoints must support "Fu=
ll" ICE.=C2=A0

The remote endpoint may of course su=
pport only ICE Lite, and WebRTC implementations must work properly with suc=
h endpoints.





This isn't normatively indicated anywhere that I co=
uld find, so I plan to add specifics on this to the next version of JSEP.





On Mon, Sep 30, 2013 at 8:32 AM, I=C3=B1aki =
Baz Castillo <ibc@aliax.net> wrote:



2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbach@nsn.com>:


> JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it i=
s incompatible with I-D.ietf-rtcweb-rtp-usage.

> Can you point out which specific aspect of this draft ICE Lite is inco=
mpatible with?

>

> In deployments where one endpoint is a browser and another one is a ga=
teway connected to the public Internet, it makes sense to allow ICE lite.



Without reading JSEP-04 I expect that it is not allowed for a web

browser to indicate "a=3Dice-lite", but a server can do that. Any=
how,

AFAIR the usage of ICE lite is fully transparent for the non ICE lite

endpoint.





--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>=
;


_______________________________________________

rtcweb mailing list

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





--20cf300e529d20898404e7a16250--

From karl.stahl@intertex.se  Mon Sep 30 17:13:26 2013
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 4531D21F9B6A for ; Mon, 30 Sep 2013 17:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYI1ijR2pEyQ for ; Mon, 30 Sep 2013 17:13:21 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF721F87BB for ; Mon, 30 Sep 2013 17:13:17 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310010213135552; Tue, 01 Oct 2013 02:13:13 +0200
From: "Karl Stahl" 
To: "'Bernard Aboba'" , "'Harald Alvestrand'" , "'Justin Uberti'" , "'Cullen Jennings \(fluffy\)'" , 
References: , <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com>, , , <5244104D.4010401@alvestrand.no>,  
In-Reply-To: 
Date: Tue, 1 Oct 2013 02:13:15 +0200
Message-ID: <017f01cebe3b$06368fb0$12a3af10$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01CEBE4B.C9BF5FB0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac68rJPGf1nVlxN8TCCe8Rc2sVrIsQBdij2Q
Content-Language: sv
Cc: rtcweb@ietf.org
Subject: [rtcweb]  [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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, 01 Oct 2013 00:13:26 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0180_01CEBE4B.C9BF5FB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I happily withdraw my suggestion to use DHCP to find a network provider
offered TURN server in favor of the DNS-Based Service Discovery method
(inserted last below). The major problem with the DHCP usage was that =
you
then also have to do something similar for: RA - Router Advertisement - =
in
IPv6, addition to the IPCP protocol for PPPoE and something for the =
mobile
OTT channel =96 wherever DHCP is NOT the method to give you an IP =
address.

=20

Further:

> On Thu, Sep 27, 2013 Justin Uberti wrote:

> Agree. I still think that extending PAC files to include TURN =
information
is the right way to go.

> PAC files can already be discovered via DHCP or DNS, there is no need =
to
reinvent this wheel.

=20

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <
 fluffy@cisco.com> wrote:

>>I think we need to give some advise to the browsers vendors on what =
they
should implement to find turn servers

=20

I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file =
can
be picked up through a URL based on the device name. Similar could work =
for
finding a TURN server on a LAN, but what about the case with a network
provider offered TURN server? The network provider hands out an IP =
address
and wants to announce a related TURN server address: =96 Is there a =
=93PAC-way=94
to announce it to a device on a LAN (behind a NAT/firewall)? The device =
must
find such configuration file based on its public IP address (that he can
find using STUN as in the suggestion below).

=20

But generally, finding a TURN-server is a network-thing, ICE (or even =
TURN
not using ICE), not a Web-thing, so for that reason the DNS-Based =
Service
Discovery method is at a better level. Such method could also be used by =
SIP
clients (even a Skype client could implement it to benefit from a =
real-time
path with better quality, if the network provider offers such path =
through
his TURN server).

=20

The DNS-Based Service Discovery method should be easy to implement in a
WebRTC browser (doing complex ICE things anyway). The question is rather =
how
easy it is for the network provider to provision. Do they all do reverse =
DNS
like with found with mobile operators TeliaSonera and Tele2 in Sweden? =
Then
it should not be too difficult.

=20

Or is there yet another better method to announce a TURN server address =
with
the IP address offered?

=20

/Karl

=20

=20

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Bernard
Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: rtcweb@ietf.org
=C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

=20

On Sep 26, 2013 8:46 PM, "Harald Alvestrand"  =
wrote:
"So far, neither the POSIX standard nor any OS vendor has offered a =
generic
facility to access information made available in DHCP packets."

=20

[BA] The Windows DHCP client API does provide this:=20

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8=
5).as
px

=20

In particular, the SendParams argument to the DhcpRequestParams function =
can
be used to request a particular parameter (e.g. TURN server address), =
which
will then be returned in the RecdParams variable. =20

=20

Nevertheless, I still think that using DHCP to configure the TURN server
address in a browser isn't a good idea.  For one thing, since DHCP is
effectively unsecured, this mechanism could be used by a rogue DHCP =
server
to force traffic to a rogue turnserver.   Great for surveillance!

=20

=20

On Sep 27, 2013 1:27 AM, "Karl Stahl" < 
karl.stahl@intertex.se> wrote:

Here comes the suggestion I got from my developer that would allow a =
network
provider to offer his TURN server for the WebRTC browser to use. This =
would
require NO new DHCP-options or similar, and NO OS changes (I do realize
those should be avoided if possible...).

The idea is still, that whoever is responsible for giving a device an IP
address (the network provider or a LAN administrator) can also announce =
a
TURN server for the WebRTC browser to use.

The suggestion is to use RFC6763 (DNS-Based Service Discovery, see =
chapter
11) where the network provider (the owner of the IP address) has set up =
a
DNS PTR record for the TURN server in the in-addr.arpa domain.

If the device got IP 173.164.252.149, then make a query for the PTR =
record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV record would return the actual address to the TURN server =
(and
you may find several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the =
WAN
IP you get via STUN in the ICE process. But if the LAN administrator
provides a local TURN server, then he also should have blocked STUN in =
the
firewall, and the browser should query the device's local host address =
(as
in the ICE procedure) and the local LAN DNS server should answer the =
query
to give the local TURN server address on the LAN.

Shouldn't this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work nicely for mobile devices, whenever the device is =
on
a "WebRTC-ready access" (actually good for everything using ICE), =
whether
fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
mechanism).

Not to slow down every call setup by doing this in the ICE process, I =
guess
this could be done when starting the browser and when the device gets a =
new
IP address, to have the TURN server address ready for later use.

/Karl


------=_NextPart_000_0180_01CEBE4B.C9BF5FB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I happily =
withdraw my suggestion to use DHCP to find a network provider offered =
TURN server in favor of the DNS-Based Service Discovery method (inserted =
last below). The major problem with the DHCP usage was that you then =
also have to do something similar for: RA - Router Advertisement - in =
IPv6, addition to the IPCP protocol for PPPoE and something for the =
mobile OTT channel – wherever DHCP is NOT the method to give you =
an IP address.
 
=

Further:
> On Thu, Sep 27, 2013 =
Justin Uberti =
wrote:
> Agree. I still think =
that extending PAC files to include TURN information is the right way to =
go.
> PAC files can already =
be discovered via DHCP or DNS, there is no need to reinvent this =
wheel.
 
=

>>On Thu, Sep 26, =
2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> =
wrote:
>>I think we need to =
give some advise to the browsers vendors on what they should implement =
to find turn servers
 
=

I Googled a bit on PAC and =
WPAD and saw that a HTTP proxy config JS file can be picked up through a =
URL based on the device name. Similar could work for finding a TURN =
server on a LAN, but what about the case with a network provider offered =
TURN server? The network provider hands out an IP address and wants to =
announce a related TURN server address: – Is there a =
“PAC-way” to announce it to a device on a LAN (behind a =
NAT/firewall)? The device must find such configuration file based on its =
public IP address (that he can find using STUN as in the suggestion =
below).
 
=

But generally, finding a =
TURN-server is a network-thing, ICE (or even TURN not using ICE), not a =
Web-thing, so for that reason the DNS-Based Service Discovery method is =
at a better level. Such method could also be used by SIP clients (even a =
Skype client could implement it to benefit from a real-time path with =
better quality, if the network provider offers such path through his =
TURN server).
 
=

The DNS-Based Service =
Discovery method should be easy to implement in a WebRTC browser (doing =
complex ICE things anyway). The question is rather how easy it is for =
the network provider to provision. Do they all do reverse DNS like with =
found with mobile operators TeliaSonera and Tele2 in Sweden? Then it =
should not be too difficult.
 
=

Or is there yet another =
better method to announce a TURN server address with the IP address =
offered?
 
=

/Karl
<=
p class=3DMsoNormal> 
 
Fr=E5n: =
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Bernard Aboba
Skickat: den 29 september 2013 =
02:41
Till: Harald Alvestrand
Kopia: =
rtcweb@ietf.org
=C4mne: Re: [rtcweb] TURN server address via =
DHCP, WGLC of =
draft-ietf-rtcweb-use-cases-and-requirements-11
 
On =
Sep 26, 2013 8:46 PM, "Harald Alvestrand" <harald@alvestrand.no> =
wrote:
"So far, neither the POSIX standard nor any OS vendor has =
offered a generic facility to access information made available in DHCP =
packets."
 
=

[BA] The Windows DHCP =
client API does provide this: 
http://msdn.microsoft.com/en-us/library/windows/desktop=
/aa363351(v=3Dvs.85).aspx
 
=

In particular, the =
SendParams argument to the DhcpRequestParams function can be used =
to request a particular parameter (e.g. TURN server address), which will =
then be returned in the RecdParams variable. =
 
 
=

Nevertheless, I still think =
that using DHCP to configure the TURN server address in a browser isn't =
a good idea.  For one thing, since DHCP is effectively unsecured, =
this mechanism could be used by a rogue DHCP server to force traffic to =
a rogue turnserver.   Great for =
surveillance!
 
 
On Sep =
27, 2013 1:27 AM, "Karl Stahl" <karl.stahl@intertex.se> =
wrote:
Here =
comes the suggestion I got from my developer that would allow a =
network
provider to offer his TURN server for the WebRTC browser to =
use. This would
require NO new DHCP-options or similar, and NO OS =
changes (I do realize
those should be avoided if =
possible...).

The idea is still, that whoever is responsible for =
giving a device an IP
address (the network provider or a LAN =
administrator) can also announce a
TURN server for the WebRTC browser =
to use.

The suggestion is to use RFC6763 (DNS-Based Service =
Discovery, see chapter
11) where the network provider (the owner of =
the IP address) has set up a
DNS PTR record for the TURN server in =
the in-addr.arpa domain.

If the device got IP 173.164.252.149, =
then make a query for the PTR =
record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the =
SRV record would return the actual address to the TURN server =
(and
you may find several for load balancing and failover I =
guess)

If the device is on a LAN, the IP 173.164.252.149 to query =
would be the WAN
IP you get via STUN in the ICE process. But if the =
LAN administrator
provides a local TURN server, then he also should =
have blocked STUN in the
firewall, and the browser should query the =
device's local host address (as
in the ICE procedure) and the local =
LAN DNS server should answer the query
to give the local TURN server =
address on the LAN.

Shouldn't this work to allow network provider =
to offer his TURN server
"automatically and =
generally"?

And wouldn't this work nicely for mobile =
devices, whenever the device is on
a "WebRTC-ready access" =
(actually good for everything using ICE), whether
fixed, WiFi or =
3G/4G OTT, you get also a TURN server (and the network
provider =
hopefully offers a prioritized pipe there as one usage of =
this
mechanism).

Not to slow down every call setup by doing =
this in the ICE process, I guess
this could be done when starting the =
browser and when the device gets a new
IP address, to have the TURN =
server address ready for later use.

/Karl

------=_NextPart_000_0180_01CEBE4B.C9BF5FB0--