From nobody Mon Jul 3 16:14:40 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5B13174F; Mon, 3 Jul 2017 16:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912366835.16111.10954741007068053324@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:14:28 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:14:28 -0000 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 of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-06.txt Pages : 12 Date : 2017-07-03 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-06 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 nobody Mon Jul 3 16:16:01 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 995C8131769; Mon, 3 Jul 2017 16:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912376059.16184.12664147737078507077@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:16:00 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:16:01 -0000 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 of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-04.txt Pages : 9 Date : 2017-07-03 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-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 nobody Mon Jul 3 16:34:31 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E55601317DA; Mon, 3 Jul 2017 16:34:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912486990.16168.4328541013171427294@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:34:29 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-21.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:34:30 -0000 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 of the IETF. Title : JavaScript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-21.txt Pages : 113 Date : 2017-07-03 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-21 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 nobody Mon Jul 3 17:09:00 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0881317FA for ; Mon, 3 Jul 2017 17:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TVD_SPACE_RATIO=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1V7ik8zjizW for ; Mon, 3 Jul 2017 17:08:56 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A362E1316B7 for ; Mon, 3 Jul 2017 17:08:56 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id f194so224981yba.3 for ; Mon, 03 Jul 2017 17:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=v3hCHLTPeitWDIgPIlugOkTl6+TchPjDKLc6MLLFScY=; b=oNK8wseOD0LsqAHhmGsjEjHmeeDlS4R6k4w4DhFwLz9MVxTwvuRxw9HO153gIHUVcL /xoQYttDRdI/Ugvsp3bf2sRXRJiaGLf3jlhH27vqLjXUHrwlbGUEXVs0PWdjoEBPT0iA yOlnw+n0ZULfOuhlH7YjPbeH6A5/No9ioDgSh5jK6rOgkgFqRKMEPbOD+AG0aH9KmNnq wS768hLU0Qu/P4d+3UiXG9ywbti7Big7NCWkHqqUlO0hNBkWt6ux2xYjz9el+CVUntMy okae7NABVWyqiMScoD7ABzLzYhue895Gwh3kvWJbAgMUzrruUIA1V80UDic4D7QcfSz+ ikbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v3hCHLTPeitWDIgPIlugOkTl6+TchPjDKLc6MLLFScY=; b=Uf/nctZBvRBWvHXjfeTPsDfX5ZCSES16GMGkZHjnFeW96wu7aFTlpNS14WwW5QRqdf eW4xjGGKWV/hG2n+ADw2aVt4QSIApUQvcWK2/zpE2T1Zjoosoa5wqt99aH3wycLaR7o7 MXhOC+1ZYRGaEXJgOPVQUDUHwsbSe09At+ITCGQb/5NChhgfEu8ePzUNXAiJnto5gTGP 6VW8ZktrO0jYrA4UorynTHuGsvjg38Gyv2aWI6Ww7xAjebXO9MQ1bJUaS3nIZuC6Z3oU 4KBaI/RnMo3oDRToXE/UkKSUrMomJKgvPJmc7utAB+LcYIFJwjShJLUIzDtzYxW69mpN pPvw== X-Gm-Message-State: AKS2vOzzY4OlbH5qymLxcqgXKzEGQDh4MaZJsSZlFLtPhI+J7OsYFrxf T+13hAPxwtF9B6bh7rupM7axktu7jpxE98GKCw== X-Received: by 10.37.48.67 with SMTP id w64mr29340489ybw.89.1499126935542; Mon, 03 Jul 2017 17:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 3 Jul 2017 17:08:14 -0700 (PDT) From: Eric Rescorla Date: Mon, 3 Jul 2017 17:08:14 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a114899c477739d055372b0f3" Archived-At: Subject: [rtcweb] Updated JSEP specification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:08:58 -0000 --001a114899c477739d055372b0f3 Content-Type: text/plain; charset="UTF-8" JSEP-21 is now up at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21 -Ekr --001a114899c477739d055372b0f3 Content-Type: text/html; charset="UTF-8" --001a114899c477739d055372b0f3-- From nobody Tue Jul 4 19:45:46 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4D127977 for ; Tue, 4 Jul 2017 19:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbP6s0nrM15D for ; Tue, 4 Jul 2017 19:45:42 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7471243FE for ; Tue, 4 Jul 2017 19:45:42 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v202so107348388itb.0 for ; Tue, 04 Jul 2017 19:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nUYl2+SyNxFO1YIXQSOu9rIQ/Rx8ryJefwE0fsn1HWo=; b=lzzS01G90r5NC7n/tiLFKnXLjO/WbMDtQyYxmDhjBRgMqlQVf2uDrV1SkPg1ZTiZXE /zQUaLiVviuqBvjJ458zHD0Fixxl62bfF/Z2UQ6vKuvMd/yM0icXbZN4hxyAmqi0J64Q LPlHxvH2IiX5bG9PEyP4NRJQ8zDDsFakygcB/WAqiIrGJvWN+XcYrNST8CWvhvPJkwxm RO0JXvDtb4/Dg6pUbkwMMDduty0aCfEP2ezGqy8A24aQz9DvNUZ4A/aA4Qha2Ss2q/3Z pPsEX8tW64THwsF/MrRG06X9sR0Av9stLC2npa1iInJ2Rj96YkSSlcF9G1vLvc59rrW3 7g0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nUYl2+SyNxFO1YIXQSOu9rIQ/Rx8ryJefwE0fsn1HWo=; b=kx0Ztd4rGdjacmmiJsKar7l684Hh3lrHTK9DYtgRXgn4GDt9UQu8zalXeC2WpFr99o wuGD458kEfxFVlgGIsB7qamPQv5QMyktbMpJAGWndqP9RSNpehXW5opumXTHc60arcws 5D2ZQe7kSKBZEULuvk0bcsW62cIjKwdjU10pZ4xexI5/siROgnvSfZacOPl9guPA9VOS pXm9Xt9ob4yj3JnppC40qxwdS4qfHK5ibpRwcylGoDNeezYsgklt54p6pgOU1TqslHGb 6GF9OJ47OCYv0lxfExJoSl0IP+UbHBbJ6trx04ElJTu0YCFXltL1ZoUUPrg6QpDnogG/ kWkw== X-Gm-Message-State: AIVw1115xeyvVJQvRDXjQ5RtsLt2n458HK1yNtqtvQ2pTOr6OzfUE8kr I/DE3sSU8DJk/5+B45ESjZqWeSoZissf X-Received: by 10.36.33.210 with SMTP id e201mr15710372ita.112.1499222741540; Tue, 04 Jul 2017 19:45:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:45:20 -0700 (PDT) In-Reply-To: References: <1ddd77ef-da4a-1a89-e538-aa20742c11a4@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B0714@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD7B084E@DGGEMM506-MBX.china.huawei.com> <9a38ffd6-e4f6-632a-b5a3-df5ded305a2e@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B08CD@DGGEMM506-MBX.china.huawei.com> <3a83f119-34a0-a9dc-da07-d63f1e912851@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B090B@DGGEMM506-MBX.china.huawei.com> From: Justin Uberti Date: Tue, 4 Jul 2017 19:45:20 -0700 Message-ID: To: Roni Even Cc: Sergio Garcia Murillo , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a11474a72f360a8055388fe41" Archived-At: Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:45:45 -0000 --001a11474a72f360a8055388fe41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is now addressed in the latest version of the draft - https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06, Section 3. On Mon, Apr 24, 2017 at 11:31 AM, Justin Uberti wrote: > Agree - the differences in protection that you mention are what I was > planning to discuss in the new text. > > On Mon, Apr 24, 2017 at 2:59 AM, Roni Even wrote: > >> Hi Sergio, >> >> I understand your distinction between FEC (ulpfec) and RED with regards >> to the RTP header. Still, the RTP header extensions have their own >> redundancy recommendations so they less less problem for packet loss. >> >> Maybe it will be good in section 3 to add a section that mention that FE= C >> will protect the whole RTP packet while RED and in-band fec will only >> protect the RTP payload. >> >> >> >> >> >> Roni >> >> >> >> *From:* Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >> *Sent:* =D7=99=D7=95=D7=9D =D7=91 24 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017= 12:09 >> *To:* Roni Even; Justin Uberti >> *Cc:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 >> >> >> >> AFAIK, FEC (at least ulpfec) protects the full packet, including header >> extensions. When we are addressing the usage of RED vs FEC for audio we >> should note the difference in behavior and it's possible consequences. >> >> Best regards >> Sergio >> >> On 24/04/2017 11:04, Roni Even wrote: >> >> Hi Sergio, >> >> What I said that the redundancy of RTP header extensions in not a FEC >> issue. FEC addresses the payload and not the RTP header. RTP header >> extensions are discussed in the RFC5285-bis draft and each new RTP heade= r >> extension must address the issue of loss since RTP over UDP is unreliabl= e. >> >> I am not sure we need any text in rtcweb-fec about RTP header >> extensions. General RTP usage in RTCweb is in the RTCweb RTP usage and >> this is where general redundancy of RTP is discussed, and as a general R= TP >> usage it points at redundancy for payload and for RTP header extensions >> reference RFC5285 (rfc5285-bis will obsolete it and have a section about >> transmission consideration. >> >> >> >> In this rtcweb-fec document audio/red is a payload; it is not an RTP >> packet for which you need to address the RTP header redundancy. >> >> >> >> Roni Even >> >> >> >> *From:* Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com >> ] >> *Sent:* =D7=99=D7=95=D7=9D =D7=91 24 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017= 11:28 >> *To:* Roni Even; Justin Uberti >> *Cc:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 >> >> >> >> Hi Roni, >> >> Not following you. Neither RFC 5265 nor RFC 5265-bis references >> red/audio, also webrtc-rtp-usage references the fec draft when speaking >> about redundancy. >> >> Also, please note that I am not proposing to change current RED behavior >> or its usage within webrtc, just proposing to add a "warning" note to ma= ke >> it implicit what is the current situation: When using rtp red for audio, >> only payload is protected, and rtp headers are not, which is almost >> harmless currently but could cause some issues in the future if not take= n >> into consideration when using new rtp header extensions. >> >> Best regards >> Sergio >> >> On 24/04/2017 7:43, Roni Even wrote: >> >> Hi Justin, >> >> I am not sure that this is something to discuss here, RTP header >> extensions are discussed in https://tools.ietf.org/html/dr >> aft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 soon to be >> replaced by the rfc5285-bis draft. >> >> The bis draft has a section about transmission considerations see >> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis- >> 09#section-4.1.1 discussing reliability of RTP header extension delivery >> by sending them in multiple RTP packets. >> >> >> >> If you still want to say something you can probably add to section 1 =E2= =80=9C >> Web Real-Time Communication (WebRTC) Media Transport and Use of RTP are >> discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26= =E2=80=9D >> >> >> >> Roni >> >> >> >> >> >> *From:* Justin Uberti [mailto:juberti@google.com ] >> *Sent:* =D7=99=D7=95=D7=9D =D7=90 23 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017= 21:48 >> *To:* Roni Even >> *Cc:* Sergio Garcia Murillo; rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 >> >> >> >> >> >> >> >> On Sat, Apr 22, 2017 at 10:32 PM, Roni Even wrote= : >> >> Hi, >> Inline >> Roni Even >> >> > -----Original Message----- >> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio >> Garcia >> > Murillo >> > Sent: =D7=99=D7=95=D7=9D =D7=95 21 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017= 12:30 >> > To: rtcweb@ietf.org; Justin Uberti >> > Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 >> > >> > Hi all, Justin, >> > >> > I have been reviewing current FEC draft and I have a couple of comment= s: >> > >> > 1. Usage of RED and in band FEC and header extensions in Sections 3.2, >> > 3.3 and 4 >> > >> > I think it would be worth noting that neither red/audio nor in-band fe= c >> allows >> > to recover RTP header extensions from previous packets. The impact of >> > loosing the header extensions will be dependent of its meaning as, for >> > example, this would cause minor problems to SFUs as client to mixer >> audio >> > level info of previous packets will be lost, but could make it unusabl= e >> for >> > PERC (as it is currently defined) as it requires the OHB header >> extension. >> >> >> [Roni Even] This is not a FEC problem but general RTP header extensions >> reliability discussed in RFC5285 and RC5285-bis draft and in the specifi= c >> RTP header extension. >> >> >> >> Roni, what would you suggest we say in this document? >> >> >> >> > >> > 2. Adaptive use of FEC for bandwidth probing (section 8) >> > >> > I think it would be a good addition to recommend FEC usage for bandwid= th >> > proving instead of other alternatives like RTX or padding only packets= . >> > >> > Best regards >> > >> > Sergio >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> >> >> > > --001a11474a72f360a8055388fe41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is now addressed in the latest version of the draft -= =C2=A0http= s://tools.ietf.org/html/draft-ietf-rtcweb-fec-06, Section 3.

On Mon, Apr 24, 2017 a= t 11:31 AM, Justin Uberti <juberti@google.com> wrote:
Agree - the differences in pr= otection that you mention are what I was planning to discuss in the new tex= t.

On Mon, Apr 24, 2017 at 2:59 AM, Roni Even <roni.even@huawei.co= m> wrote:

Hi Sergio,<= /span>

I understand your distinc= tion between FEC (ulpfec) and=C2=A0 RED with regards to the RTP header. Sti= ll, the RTP header extensions have their own redundancy recommendations so they less less problem for packet loss.

Maybe it will be good in = section 3 to add a section that mention that FEC will protect the whole RTP= packet while RED and in-band fec will only protect the RTP payload.

=C2=A0

=C2=A0

Roni=

=C2=A0

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=91 2= 4 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017 12:09
To: Roni Even; Justin Uberti
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04=

=C2=A0

AFAIK, FEC (at least ulpfec) protects the full packe= t, including header extensions. When we are addressing the usage of RED vs = FEC for audio we should note the difference in behavior=C2=A0 and it's = possible consequences.

Best regards
Sergio

On 24/04/2017 11:04, Roni Even wrote:

Hi Sergio,<= u>

What I said that the redu= ndancy of RTP header extensions in not a FEC issue. FEC addresses the paylo= ad and not the RTP header.=C2=A0 RTP header extensions are discussed in the RFC5285-bis draft and each new RTP header extension must address th= e issue of loss since RTP over UDP is unreliable.

I am not sure we need any= text in rtcweb-fec about RTP header extensions.=C2=A0 General RTP usage in= RTCweb is in the RTCweb RTP usage and this is where general redundancy of RTP is discussed, and as a general RTP usage it points at re= dundancy for payload and for RTP header extensions reference RFC5285 (rfc52= 85-bis will obsolete it and have a section about transmission consideration= .

=C2=A0

In this rtcweb-fec docume= nt audio/red is a payload; it is not an RTP packet for which you need to ad= dress the RTP header redundancy.

=C2=A0

Roni Even

=C2=A0

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=91 2= 4 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017 11:28
To: Roni Even; Justin Uberti
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

=C2=A0

Hi Roni,

Not following you. Neither RFC 5265 nor RFC 5265-bis references red/audio, = also webrtc-rtp-usage references the fec draft when speaking about redundan= cy.

Also, please note that I am not proposing to change current RED behavior or= its usage within webrtc, just proposing to add a "warning" note = to make it implicit what is the current situation: When using rtp red for a= udio, only payload is protected, and rtp headers are not, which is almost harmless currently but could cause some issues in= the future if not taken into consideration when using new rtp header exten= sions.

Best regards
Sergio

On 24/04/2017 7:43, Roni Even wrote:

Hi Justin,

I am not sure that this is something to= discuss here, RTP header extensions are discussed in https://tools.ietf.org/html/= draft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 so= on to be replaced =C2=A0by the rfc5285-bis draft.

The bis draft has a section about trans= mission considerations see https://tools.ietf.org/html/draft-iet= f-avtcore-rfc5285-bis-09#section-4.1.1 discussing reliability of RTP header extension delivery= by sending them in multiple RTP packets.

=C2=A0

If you still want to say something you = can probably add to section 1 =E2=80=9C Web Real-Time Communication (WebRTC= ) Media Transport and Use of RTP are discussed in https://tools.ietf.org/html/= draft-ietf-rtcweb-rtp-usage-26=E2=80=9D

=C2=A0

Roni

=C2=A0

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=90 2= 3 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017 21:48
To: Roni Even
Cc: Sergio Garcia Murillo; rtcweb@ietf.org
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

=C2=A0

=C2=A0

=C2=A0

On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <roni.even@huawei.com<= /a>> wrote:

Hi,
Inline
Roni Even

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia > Murillo
> Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=95 21 =D7=90=D7=A4=D7=A8=D7=99=D7=9C 2017 12:30
> To: rtcweb@ietf.o= rg; Justin Uberti
> Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>
> Hi all, Justin,
>
> I have been reviewing current FEC draft and I have a couple of comment= s:
>
> 1. Usage of RED and in band FEC and header extensions in Sections 3.2,=
> 3.3 and 4
>
> I think it would be worth noting that neither red/audio nor in-band fe= c allows
> to recover RTP header extensions from previous packets. The impact of<= br> > loosing the header extensions will be dependent of its meaning as, for=
> example, this would cause minor problems to SFUs as client to mixer au= dio
> level info of previous packets will be lost, but could make it unusabl= e for
> PERC (as it is currently defined) as it requires the OHB header extens= ion.


[Roni Even] This is not a FEC problem but general RTP header extensions rel= iability discussed in RFC5285 and RC5285-bis draft and in the specific RTP = header extension.

=C2=A0

Roni, what would you suggest we say in this document= ?

=C2=A0

>
> 2. Adaptive use of FEC for bandwidth probing (section 8)
>
> I think it would be a good addition to recommend FEC usage for bandwid= th
> proving instead of other alternatives like RTX or padding only packets= .
>
> Best regards
>
> Sergio
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0

=C2=A0

=C2=A0



--001a11474a72f360a8055388fe41-- From nobody Tue Jul 4 19:46:35 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B638127977 for ; Tue, 4 Jul 2017 19:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmKangUX0Pmv for ; Tue, 4 Jul 2017 19:46:30 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81A012EBFD for ; Tue, 4 Jul 2017 19:46:30 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id r36so78857801ioi.1 for ; Tue, 04 Jul 2017 19:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcLe1YGzbSgGgtNpocoWpUek4YDzSz6wqu2xn7kda4w=; b=eSd/Sv90XrbNgfpXY18tk93ezUmY+xVmmsDVunjIdS18MFffmsuZFz1uT7ublrwuAJ y4BiFfOMnoSydPXnPBRPHYY0Bdp0TnkC5n8RpyoZRh50qrhta+T9OVWoyES2I2jqj2Yk nMZtvGhp5faRh36FLsSWLPeGk38us8bk+v8qr7l2IXcO/G0xPMclYe7yDl6Ja0H0tz/w tMM5E7TuLmYwEwMFns68aDxB8dYRTsnv9S3j1OXoYIPyGs+Teulbp7ksXWxfBCkpRKKH 5nrVxYJc4isCQlFz0RgoigauQfEy/FC4IurBZXkoz8cw/LQNPAwy507c0pA0RDdcVxf9 8CCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RcLe1YGzbSgGgtNpocoWpUek4YDzSz6wqu2xn7kda4w=; b=qPvuiDRPr1+8+URe3gWaS+zDYppWjDIpOWB6A5EMhs3Hv2gLTdu3oG4qCrLgfZXdM1 WrxU2Zp6VSC24hW5kl/CYG61h/UvXbfZkA7kGCIzQd3+zoFJ93vXbou66LnjFDie4FT9 69vjfLniim5YieNEuCfuqbrWTRknAhNQUIgaWAZiadCO/U/4yHPyt+XVNihLnR63st2b eCM+L2mKFeET4QmiY4lR72eQJMb9plblpPMuu37IJr1fTVafAMicQhNgTphnYwZv904A 0qCiWGwWOE7QVlqX/Lxmv3n2swxkuBjmadGLxeapjHwtbI0zSWxSDsm+S93k31lc6t9l 52nQ== X-Gm-Message-State: AKS2vOyncAQrvsO7qlJBAG8Brypeyehgy+ZIkla1Ce0YOQGheRMAjo4Z uYGuCf16ALb/HEvVLyM5rx9qnVKBg4aR X-Received: by 10.107.133.84 with SMTP id h81mr39933563iod.230.1499222789877; Tue, 04 Jul 2017 19:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:46:09 -0700 (PDT) In-Reply-To: References: <39c31585-7e15-383d-a534-9efe8888695a@ericsson.com> From: Justin Uberti Date: Tue, 4 Jul 2017 19:46:09 -0700 Message-ID: To: Magnus Westerlund Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113f13a6d52fef05538901f3" Archived-At: Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:46:33 -0000 --001a113f13a6d52fef05538901f3 Content-Type: text/plain; charset="UTF-8" Thanks for the review. These issues have all been resolved in the latest version of the draft, https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06. On Sat, Apr 22, 2017 at 12:46 PM, Justin Uberti wrote: > > > On Fri, Apr 21, 2017 at 2:07 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> I have review the -04 version of the FEC. I think the document is mostly >> done. I only have these few comments that should be addressed before going >> forward. >> >> 1. Section 4.2: >> >> Support for redundant encoding MUST be indicated by offering "red" as >> a supported payload type in the offer. >> >> I think it is unclear what "red" refers to here. This as it is not made >> clear that RFC 2198 has the media type audio/red and text/red. I think >> there are two things that would make this clearer. One would be to change >> "red" into media type "audio/red". The other would be to add the reference >> afterwards. > > > Adding the reference seems like a good idea. With that, the fact that it > is audio/red seems implicit. > > https://github.com/juberti/draughts/issues/46 > >> > > >> 2. Section 12.1: >> >> It is missing this normative reference: [3GPP.26.114] >> > > Agreed. I need to remember how to format such non-IETF references. > > https://github.com/juberti/draughts/issues/28 > >> >> 3. Section 12.1: >> >> I think that the following references have usages in the text that make >> them normative: >> >> [RFC7587] and [RFC4867] >> > > Agreed. > > https://github.com/juberti/draughts/issues/47 > --001a113f13a6d52fef05538901f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review. These issues have all been resolved= in the latest version of the draft,=C2=A0https://tools.ietf.org/html/draft-ietf-rtcw= eb-fec-06.

On Sat, Apr 22, 2017 at 12:46 PM, Justin Uberti <juberti@google.com> wrote:

=

= On Fri, Apr 21, 2017 at 2:07 AM, Magnus Westerlund <magnus.we= sterlund@ericsson.com> wrote:
Hi,

I have review the -04 version of the FEC. I think the document is mostly do= ne. I only have these few comments that should be addressed before going fo= rward.

1. Section 4.2:

=C2=A0 =C2=A0Support for redundant encoding MUST be indicated by offering &= quot;red" as
=C2=A0 =C2=A0a supported payload type in the offer.

I think it is unclear what "red" refers to here. This as it is no= t made clear that RFC 2198 has the media type audio/red and text/red. I thi= nk there are two things that would make this clearer. One would be to chang= e "red" into media type "audio/red". The other would be= to add the reference afterwards.

Ad= ding the reference seems like a good idea. With that, the fact that it is a= udio/red seems implicit.=C2=A0

=C2=A0

2. Section 12.1:

It is missing this normative reference: [3GPP.26.114]
=
Agreed. I need to remember how to format such non-IET= F references.=C2=A0


3. Section 12.1:

I think that the following references have usages in the text that make the= m normative:

[RFC7587] and [RFC4867]

Agreed.= =C2=A0


--001a113f13a6d52fef05538901f3-- From nobody Tue Jul 4 19:48:11 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF35712EC69 for ; Tue, 4 Jul 2017 19:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfC1aZAJwA-U for ; Tue, 4 Jul 2017 19:48:06 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C342412EBFD for ; Tue, 4 Jul 2017 19:48:05 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id h134so78961902iof.2 for ; Tue, 04 Jul 2017 19:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AoyvhqMTrpLQwL/UdSY3hwym8VFpEJv9srMbGCcJUw0=; b=QMhwtXUFsXRJcJ+EbBTogd/HjBOvtWhflvpJum2WUF2SZaepXQovJlo/nKNOuaZFXU oH89c161yLC+Df6Kh9jLZHzbdpcalwJTRVYfSIKcYdMwal6Q4T7yoYpFwmftHGbsO6VP sl78xRWJEoQgT+xSMiUHvDJWEl0+FQTLpsfEBPzHfUCXSWJh01p6rigD10N26wvABO/v 0SR8NL3lkM+zvcJBnq1G3R75vCzQfqHKzH6iAGwUmPy9iNEYVEDGgA9qnEUtNnVDVbzZ +hLA9XPW16Xp1vtrL9tBLPhl/fwn3KeyEC27wAf0k1dJWjNrkhMeKc9LDz7O31nsVubk LckA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AoyvhqMTrpLQwL/UdSY3hwym8VFpEJv9srMbGCcJUw0=; b=StscJmaSapgd3c51EF9h6csPuxBzU8jN8rxZmhCEujvI4MVwWq/cBHJOqMcE5vZcEG 82Vk5n4tojUeaJsT40g25zEOKCJL7NUzdqe4aitnFtj62NqE1oFUXHzoY5i8A9kQy9zB p/KTKCsxUZE5q+oBr6JEEi4FZnYxGB0H9IYnQYg2t46VshZL/mCTMjlCA8TvNwarR+Ou z3LQp+QrqQ10PGOZ69c/VtifgUNT9yJt/pPBDQvgVaNtOx4Rxcn/Ax//7aub813N7Bh0 oRDthoyQQpOx2+W4hKJ5DM0Ne/4OmKjYyN7Hkt2YBD4TTkIgKvvqyoaE7bFwIp4wYyVQ cf6A== X-Gm-Message-State: AKS2vOy+tUI9wlBZwQd+76bzIlqSCUwYkXytVe51MGsEW34Z9ycib0Rj 89r9qgaeG/RUtSrSfJIHxA3+kFWy75grouEFnw== X-Received: by 10.107.184.8 with SMTP id i8mr41509742iof.153.1499222884841; Tue, 04 Jul 2017 19:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:47:44 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 4 Jul 2017 19:47:44 -0700 Message-ID: To: "Mo Zanaty (mzanaty)" Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07712a7e6e8805538907fa" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:48:10 -0000 --94eb2c07712a7e6e8805538907fa Content-Type: text/plain; charset="UTF-8" These issues have all been resolved in the latest version of the draft, https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06. On Sat, Apr 22, 2017 at 12:39 PM, Justin Uberti wrote: > > > On Mon, Apr 17, 2017 at 12:07 PM, Mo Zanaty (mzanaty) > wrote: > >> Agreed on all responses, except some further clarifications inline, see >> Mo:. >> >> From: Justin Uberti >> Date: Friday, April 14, 2017 at 6:45 PM >> To: mzanaty >> Cc: "rtcweb@ietf.org" >> Subject: Re: Review of draft-ietf-rtcweb-fec >> >> Thanks for this detailed review. >> >> On Fri, Apr 7, 2017 at 7:17 PM, Mo Zanaty (mzanaty) >> wrote: >> >>> Here is my review of draft-ietf-rtcweb-fec-04. >>> >>> 4.1. Recommended Mechanism (for audio FEC), first paragraph says: >>> >>> *OLD:* >>> "When using the Opus codec, use of the built-in Opus FEC mechanism is >>> RECOMMENDED. This provides reasonable protection of the audio stream >>> against typical losses, with modest overhead. Note that as indicated >>> above the built-in Opus FEC only provides single-frame redundancy; if >>> multi-packet protection is needed, the built-in FEC *should be* >>> *combined with [RFC2198] redundancy to protect the N-2th, N-3rd, etc.* >>> *packets."* >>> >>> The last sentence about multi-packet protection should not be >>> recommended due to overhead. Packing multiple full-size Opus frames, each >>> with their own built-in prior-frame FEC, into RED packets is akin to >>> packing multiple PCMU frames into RED packets. The latter is discouraged 3 >>> paragraphs later: >>> >>> "When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] >>> redundant encoding MAY be used, but note that this will result in a >>> potentially significant bitrate increase, and that suddenly >>> increasing bitrate to deal with losses from congestion may actually >>> make things worse." >>> >>> These same warnings would apply to multi-packet Opus RED. Therefore I >>> suggest rewording the first paragraph as follows. >>> >>> *NEW:* >>> "When using the Opus codec, use of the built-in Opus FEC mechanism is >>> RECOMMENDED. This provides reasonable protection of the audio stream >>> against typical losses, with modest overhead. Note that as indicated >>> above the built-in Opus FEC only provides single-frame redundancy; if >>> multi-packet protection is needed, the built-in FEC *MAY be* >>> *combined with [RFC2198] redundancy to protect prior packet pairs,* >>> *but note this will result in significant bitrate increase which may* >>> *aggravate congestion losses."* >>> >> >> This isn't quite as bad as full PCMU frames, because Opus frames will >> typically be smaller, but I agree it is inconsistent. >> >> https://github.com/juberti/draughts/issues/38 >> >> >>> >>> 4.2. Negotiating Support, first sentence says: >>> >>> *OLD:* >>> *"Support for redundant encoding* MUST be indicated by offering >>> "red"..." >>> >>> This may be misinterpreted as mandating that WebRTC endpoints MUST offer >>> "red", rather than merely indicating that if they choose to support >>> redundant encoding (which is only RECOMMENDED for VBR codecs without >>> internal FEC in the prior section), then it MUST be indicated by offering >>> "red". I suggest rewording this as: >>> >>> *NEW:* >>> *"If redundant encoding is supported, it* MUST be indicated by offering >>> "red"..." >>> >>> The intent here was that all clients should support receipt of 2198, >> even if they don't support sending a redundant encoding (which is only, as >> you say, RECOMMENDED). IOW, "red" would be a MTI format. >> >> Mo: MTI "red" only if you support VBR codecs without internal FEC (which >> are optional not MTI audio codecs), right? If so, I would explicitly >> indicate this via *"Support for redundant encoding of VBR codecs without >> internal FEC MUST.*.." >> Or do you mean MTI regardless of codecs, like even for Opus? That would >> surprise me, to make "red" MTI when it is not recommended for the MTI audio >> codecs, and no browser advertises "red" for audio. >> > > This makes sense to me. As indicated above, there isn't enough rationale > to mandate "red" support. > > However, I am thinking of making "red" support SHOULD strength, since at > present it's our best available tool for handling burst losses. > > https://github.com/juberti/draughts/issues/39 > > >> >> >>> Same comment for Opus in the following paragraph: >>> >>> *OLD:* >>> *"For Opus, a receiver MUST indicate that it is prepared to use* >>> *incoming FEC data with* the "useinbandfec=1" parameter..." >>> >>> *NEW:* >>> *"For Opus, a receiver that it is prepared to use incoming FEC data* >>> *MUST include* the "useinbandfec=1" parameter..." >>> >> >> Similarly here - for WebRTC, the intent was to mandate support for >> receiving and using Opus FEC. >> >> Mo: Ok, this one makes sense to be MTI. >> >> >>> 5.1. Recommended Mechanism (for video FEC) says: >>> >>> *OLD:* >>> "For video content, use of a separate FEC stream with the RTP payload >>> format described in [I-D.ietf-payload-flexible-fec-scheme] is >>> RECOMMENDED. The receiver can demultiplex the incoming FEC stream by >>> SSRC and correlate it with the primary stream *via the SSRC field* >>> *present in the FEC header."* >>> >>> Flex FEC moved the SSRC binding from the FEC header to the CSRC list. >>> Only the retransmission format still has the SSRC field in the FEC header. >>> Reword as: >>> >>> *NEW:* >>> "For video content, use of a separate FEC stream with the "flexfec" RTP >>> payload >>> format described in [I-D.ietf-payload-flexible-fec-scheme] is >>> RECOMMENDED. The receiver can demultiplex the incoming FEC stream by >>> SSRC and correlate it with the primary stream*(s) via the CSRC(s)* >>> *in the RTP header of the FEC repair packet, or via the SSRC field* >>> *in the FEC header for retransmissions."* >>> >> >> OK. https://github.com/juberti/draughts/issues/40 >> >>> >>> The next paragraph suggests multiple source streams is a problem. >>> >>> *OLD:* >>> "Support for protecting multiple primary streams with a single FEC >>> stream is complicated by WebRTC's 1-m-line-per-stream policy, which >>> does not allow for a m-line dedicated specifically to FEC." >>> >>> But Flex FEC already supports this with SSRC(s) of primary stream(s) as >>> CSRC(s) of the FEC stream, so *strike the above OLD paragraph.* >>> >>> It's still not clear how this should work. Which m= lines would carry >> FEC info for which other m= lines? >> >> Mo: Flex FEC can protect multiple primary streams as long as they are in >> the same RTP session (SSRC space), e.g. when bundled. There is no SDP >> association between source and repair streams for Flex FEC. The association >> is at the RTP level with SSRCs, so a Flex FEC packet can protect any RTP >> packet(s) in the same RTP session. In SDP, any bundled m= line(s) can >> declare the flexfec PT. JSEP requires all of them to declare it, which >> seems best. >> >> If we are going to support this, I think we need to detail in this >> document how it should work, and it may have downstream ramifications on >> JSEP. >> >> Mo: JSEP says the FEC PT must be included in all m= lines, which seems >> best/correct. >> > > OK, this is a welcome development. I will update this section accordingly > to give an overview of how this should work, which will be a nontrivial > update. > > https://github.com/juberti/draughts/issues/45 > >> >> >>> 8. Adaptive Use of FEC, first paragraph says: >>> >>> *OLD:* >>> "...methods like *RTX [RFC4588]*, which only transmits redundant data >>> when..." >>> >>> Flex FEC also supports retransmissions, so reword as: >>> >>> *NEW:* >>> "...methods like *RTX [RFC4588] or the "flexfec" retransmission format*, >>> which only transmits redundant data when..." >>> >> >>> Same comment in the next paragraph. >>> >>> *OLD:* >>> "Given this, WebRTC implementations SHOULD consider using *RTX* >>> instead..." >>> >>> *NEW:* >>> "Given this, WebRTC implementations SHOULD consider using *RTX or* >>> *the "flexfec" retransmission format* instead..." >>> >>> >> https://github.com/juberti/draughts/issues/41 >> >> >>> 9. Security Considerations >>> >>> Add a final paragraph on the order of FEC and SRTP operations. >>> >>> *NEW:* >>> *"SRTP [RFC3711] defines the default order of FEC and SRTP as FEC >>> followed by SRTP at the sender, and SRTP followed by FEC at the receiver. >>> DTLS-SRTP [RFC5764] uses this same default order for all SRTP Protection >>> Profiles."* >>> >> >> https://github.com/juberti/draughts/issues/42 >> >>> >>> Editorial: >>> >>> Abstract and Introduction should use WebRTC "endpoint" as defined in >>> -overview. >>> Abstract: "... FEC ... used by WebRTC *applications*" -> WebRTC >>> *endpoints* >>> Introduction: "... FEC ... for WebRTC *client implementations*" -> >>> WebRTC *endpoints* >>> Or you could be very generic and just say WebRTC implementations >>> everywhere. >>> >> >> I think WebRTC implementations is best, since these are guidelines for >> WebRTC implementors, not application implementors. >> >> https://github.com/juberti/draughts/issues/43 >> > > --94eb2c07712a7e6e8805538907fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These issues have all been resolved in the latest version = of the draft, https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06.

On Sat, Apr 22, 2017 at 1= 2:39 PM, Justin Uberti <juberti@google.com> wrote:

<= br>
On Mon, Apr 17, 2017 a= t 12:07 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
Agreed on all responses, except some further clarifications inline, se= e Mo:.

From: Justin Uberti <juberti@google.com>
Date: Friday, April 14, 2017 at 6:4= 5 PM
To: mzanaty <mzanaty@cisco.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: Review of draft-ietf-r= tcweb-fec

Thanks for this detailed review.=C2=A0

On Fri, Apr 7, 2017 at 7:17 PM, Mo Zanaty (mzana= ty) <mzanaty@cisco.co= m> wrote:
Here is my review of draft-ietf-rtcweb-fec-04.

4.1. Recommended Mechanism (for audio FEC), first paragraph says:

OLD:
"When using the Opus codec, use of the built-in Opus FEC mechanis= m is
RECOMMENDED. This provides reasonable protection of the audio stream
against typical losses, with modest overhead. Note that as indicated
above the built-in Opus FEC only provides single-frame redundancy; if<= /div>
multi-packet protection is needed, the built-in FEC should be
combined with [RFC2198] redundancy to protect the N-2th, N-3rd, etc= .
packets."

The last sentence about multi-packet protection should not be recommen= ded due to overhead. Packing multiple full-size Opus frames, each with thei= r own built-in prior-frame FEC, into RED packets is akin to packing multipl= e PCMU frames into RED packets. The latter is discouraged 3 paragraphs later:

"When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198]<= /div>
redundant encoding MAY be used, but note that this will result in a
potentially significant bitrate increase, and that suddenly
increasing bitrate to deal with losses from congestion may actually
make things worse."

These same warnings would apply to multi-packet Opus RED. Therefore I = suggest rewording the first paragraph as follows.

NEW:
"When using the Opus codec, use of the built-in Opus FEC mechanis= m is
RECOMMENDED. This provides reasonable protection of the audio stream
against typical losses, with modest overhead. Note that as indicated
above the built-in Opus FEC only provides single-frame redundancy; if<= /div>
multi-packet protection is needed, the built-in FEC MAY be
combined with [RFC2198] redundancy to protect prior packet pairs,
but note this will result in significant bitrate increase which may=
aggravate congestion losses."

This isn't quite as bad as full PCMU frames, because Opus frames w= ill typically be smaller, but I agree it is inconsistent.

=C2=A0

4.2. Negotiating Support, first sentence says:

OLD:
"Support for redundant encoding MUST be indicated by offer= ing "red"..."

This may be misinterpreted as mandating that WebRTC endpoints MUST off= er "red", rather than merely indicating that if they choose to su= pport redundant encoding (which is only RECOMMENDED for VBR codecs without = internal FEC in the prior section), then it MUST be indicated by offering "red". I suggest rewording this as= :

NEW:
"If redundant encoding is supported, it MUST be indicated = by offering "red"..."

The intent here was that all clients should support receipt of 2198, e= ven if they don't support sending a redundant encoding (which is only, = as you say, RECOMMENDED). IOW, "red" would be a MTI format.

Mo: MTI "red" only if you support VBR codecs without interna= l FEC (which are optional not MTI audio codecs), right? If so, I would expl= icitly indicate this via "Support for redundant encoding of VBR codecs without internal FEC = MUST..."
Or do you mean MTI regardless of codecs, like even for Opus? That woul= d surprise me, to make "red" MTI when it is not recommended for t= he MTI audio codecs, and no browser advertises "red" for audio.

This makes sense to = me. As indicated above, there isn't enough rationale to mandate "r= ed" support.

However, I am thinking of making= "red" support SHOULD strength, since at present it's our bes= t available tool for handling burst losses.

=C2=A0
=
=C2=A0
Same comment for Opus in the following paragraph:

OLD:
"For Opus, a receiver MUST indicate that it is prepared to use=
incoming FEC data with the "useinbandfec=3D1" paramet= er..."

NEW:
"For Opus, a receiver that it is prepared to use incoming FEC = data
MUST include the "useinbandfec=3D1" parameter..."= ;

Similarly here - for WebRTC, the intent was to mandate support for receivi= ng and using Opus FEC.

Mo: Ok, this one makes sense to be MTI.
=C2=A0
5.1. Recommended Mechanism (= for video FEC) says:

OLD:
"For video content, use of a separate FEC stream with the RTP pay= load
format described in [I-D.ietf-payload-flexible-fec-scheme] is
RECOMMENDED. The receiver can demultiplex the incoming FEC stream by
SSRC and correlate it with the primary stream via the SSRC field
present in the FEC header."

Flex FEC moved the SSRC binding from the FEC header to the CSRC list. = Only the retransmission format still has the SSRC field in the FEC header. = Reword as:

NEW:
"For video content, use of a separate FEC stream with the "f= lexfec" RTP payload
format described in [I-D.ietf-payload-flexible-fec-scheme] is
RECOMMENDED. The receiver can demultiplex the incoming FEC stream by
SSRC and correlate it with the primary stream(s) via the CSRC(s)
in the RTP header of the FEC repair packet, or via the SSRC field
in the FEC header for retransmissions."


The next paragraph suggests multiple source streams is a problem.

OLD:
"Support for protecting multiple primary streams with a single FE= C
stream is complicated by WebRTC's 1-m-line-per-stream policy, whic= h
does not allow for a m-line dedicated specifically to FEC."

But Flex FEC already supports this with SSRC(s) of primary stream(s) a= s CSRC(s) of the FEC stream, so strike the above OLD paragraph.

It's still not clear how this should work. Which m=3D lines would = carry FEC info for which other m=3D lines?

Mo: Flex FEC can protect multiple primary streams as long as they a= re in the same RTP session (SSRC space), e.g. when bundled. There is no SDP= association between source and repair streams for Flex FEC. The associatio= n is at the RTP level with SSRCs, so a Flex FEC packet can protect any RTP packet(s) in the same RTP session. I= n SDP, any bundled m=3D line(s) can declare the flexfec PT. JSEP requires a= ll of them to declare it, which seems best.=C2=A0

If we are going to support this, I think we need to detail in this doc= ument how it should work, and it may have downstream ramifications on JSEP.=

Mo: JSEP says the FEC PT must be included in all m=3D lines, which = seems best/correct.

OK, this is a welcome development. I wi= ll update this section accordingly to give an overview of how this should w= ork, which will be a nontrivial update.=C2=A0

=C2=A0
8. Adaptive Use of FEC, firs= t paragraph says:

OLD:
"...methods like RTX= [RFC4588], which only transmits redundant data when..."

Flex FEC also supports retra= nsmissions, so reword as:

NEW:
"...methods like RTX [RFC4588] or the "flexfec" retr= ansmission format,
which only transmits redundant data when..."=C2=A0

Same comment in the next paragraph.

OLD:
"Given this, WebRTC imp= lementations SHOULD consider using RTX instead..."

NEW:
"Given this, WebRTC imp= lementations SHOULD consider using RTX or
the "flexfec" r= etransmission format instead..."


=C2=A0
9. Security Considerations

Add a final paragraph on the= order of FEC and SRTP operations.

NEW:
"SRTP [RFC3711] defi= nes the default order of FEC and SRTP as FEC followed by SRTP at the sender= , and SRTP followed by FEC at the receiver. DTLS-SRTP [RFC5764] uses this s= ame default order for all SRTP Protection Profiles."


Editorial:

Abstract and Introduction sh= ould use WebRTC "endpoint" as defined in -overview.
Abstract: "... FEC ... = used by WebRTC applications" -> WebRTC endpoints
Introduction: "... FEC = ... for WebRTC client implementations" -> WebRTC endpoints
Or you could be very generic= and just say WebRTC implementations everywhere.

I think WebRTC implementations is best, since these are guidelines for= WebRTC implementors, not application implementors.



--94eb2c07712a7e6e8805538907fa-- From nobody Tue Jul 4 19:48:51 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08C13164B for ; Tue, 4 Jul 2017 19:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIhxqAcB6YzY for ; Tue, 4 Jul 2017 19:48:42 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A5A1243FE for ; Tue, 4 Jul 2017 19:48:36 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id h64so78808436iod.0 for ; Tue, 04 Jul 2017 19:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7RKzUbx0cpKUyHFZ5CUly28CtChMAPA037JtwfJfZec=; b=EgZTNURZPu9yahlb/Ug2yOlBTtPfaGxAAueo1REXvLdMS5YuOdmFNLdHPZBnBkjT0A qZBRT1+PPeVYt/Ul2ffWBGVUJVXRVSEuxDb/R9xxo/kJN0Jj0KlBRyVVrkWZE4ZnA+s/ xRLsVV28R1O90pMk756G7wTKP+87IkQ+IXpgGgXoPTR9oCFPV+dlE17Z83748auDdBzl TW7TxYYwES0DYSI41mv6Pthe0TV3FERr4MvKavp3ei9IIAqkwTdWmU139oMcLvHstDob tnAa9e++LrmrIkAqAlSRf8Ecw7rMQL4c3yVgpLJX1dGS9J268opRz09/6lGvY+pQHF48 Ht5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7RKzUbx0cpKUyHFZ5CUly28CtChMAPA037JtwfJfZec=; b=ZgypGh1fKQwq6ygB+cinR00zvjnxIxas6pFlpPZYzE5qfFpcg8yMHCAEh5Az4aPcxc wq0EhCA9BCZhb3TzfaQzhfEtE6cyrT023xZC6mIMZWLa+tbIl5874qTyRcDghOTBjidh NyNXNXHazCfF3aMmqmx6bMdzEjKy8irWvWCYk8FttzuE+MLsiL2fY5of5aea3pGSskT8 Iaw4/TDfCPzWfyvGjnOpC1Vop72jkdYJbFvbPkoOW0ptZYQ3l4/QxZTgq1Cko1r2HftF UDh6zX46fsmA7y63/wod20EKogWzKif2oSyVEk84Rs+OaWRRjokztx6cxlVSfZYsK05/ e2Iw== X-Gm-Message-State: AKS2vOz5aRmg0RZ1ZLUDlJKrWsOyzd4PvwRdEe3M7e7QACCXcARTHxro oGYBWEgM4/iLI8Ucc+uww1XfcA4Tjmou X-Received: by 10.107.133.84 with SMTP id h81mr39937381iod.230.1499222915472; Tue, 04 Jul 2017 19:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:48:14 -0700 (PDT) In-Reply-To: References: <149560430512.28459.18017801020136502401@ietfa.amsl.com> From: Justin Uberti Date: Tue, 4 Jul 2017 19:48:14 -0700 Message-ID: To: Barry Dingle Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113f13a6512b3305538909a3" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:48:49 -0000 --001a113f13a6512b3305538909a3 Content-Type: text/plain; charset="UTF-8" Resolved in the latest version of the draft, https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06. On Thu, Jun 1, 2017 at 1:24 AM, Barry Dingle wrote: > The start of Section 3 of draft-ietf-rtcweb-fec-05.txt says: "By its name, > FEC describes ...." > > The words 'By its name' are not needed. I suggest they be removed. > > Barry Dingle > Melbourne, Australia > > On Thu, May 25, 2017 at 9:59 AM, Justin Uberti wrote: > >> Note that is simply a version bump for freshness. >> >> On Tue, May 23, 2017 at 10:38 PM, 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 >>> of the IETF. >>> >>> Title : WebRTC Forward Error Correction Requirements >>> Author : Justin Uberti >>> Filename : draft-ietf-rtcweb-fec-05.txt >>> Pages : 10 >>> Date : 2017-05-23 >>> >>> Abstract: >>> This document provides information and requirements for how Forward >>> Error Correction (FEC) should be used by WebRTC applications. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-rtcweb-fec-05 >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-05 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-05 >>> >>> >>> 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 >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a113f13a6512b3305538909a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Resolved in the latest version of the draft,=C2=A0https://tools.iet= f.org/html/draft-ietf-rtcweb-fec-06.
On Thu, Jun 1, 2017 at 1:24 AM, Barry Dingle <= span dir=3D"ltr"><btdingle@gmail.com> wrote:
The start of Section 3 of draft-ietf-rtcweb-fec-05.= txt says: "By its name, FEC describes ...."

The word= s 'By its name' are not needed. I suggest they be removed.

Bar= ry Dingle
Melbourne, Australia
<= /div>

On Thu, May 25, 2017 at 9:59 AM, Justin Uber= ti <juberti@google.com> wrote:
Note that is simply a version bum= p for freshness.

On Tue, May 23, 2017 at 10:38 PM, <interne= t-drafts@ietf.org> wrote:

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 of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-23

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-fec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcw= eb-fec-05
https://datatracker.ietf.org/doc/= html/draft-ietf-rtcweb-fec-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-fec-05


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


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


--001a113f13a6512b3305538909a3-- From nobody Tue Jul 4 19:53:44 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0912ECB8 for ; Tue, 4 Jul 2017 19:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUBmtfV7_9ev for ; Tue, 4 Jul 2017 19:53:40 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7134B1243FE for ; Tue, 4 Jul 2017 19:53:40 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id r36so78907522ioi.1 for ; Tue, 04 Jul 2017 19:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3v+TKokClFlB00Eebt/p5rT85tmMe8UKvgbs96RtCYo=; b=nUhnIhBQgwYSwZiEwH6ypQXAwLABCtLKaNTJ8WP5hObUYj0cLvK3ukpI6UTWxni3Lz Ehc8JYHWfxPoutTvYRail/b7iJtAzVWZsQsH2q5GKbUN68orhZgT70UqyU3qDt3qM7dj zFmfHtGRIpX70vl6wflmvCm+sKpThH2PZ8yRq19e7eJALJsm3GRe/azsS16lO0Wq4Pe6 XXGooSx4QfQO0lEPGaeUR7c9FEGf3t7Glip8oZTuOCKU5cIcyuu2URUj1AMq1odaqvKU FXbwUNSKYSUWakrPVrYi8Fa4hUQsDrX05QfGDRN0fO0umaQ4ZZI5UbdcIbVGNPQY9yjZ BGBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3v+TKokClFlB00Eebt/p5rT85tmMe8UKvgbs96RtCYo=; b=Bxvb0nCoO8OxZQU7PHgU6bs1oMvzBehKnKXgbNaqPS2Sl0SgCszu4TXiR0+nkC4sef YCtwDpMfcZP/reFX2wYLDZ+nVpLuYKB0g1N10RxH/D6rjQOg2MUwzb1HeXExUFZh+hfa D9N4pEg3ntEm5+PqrXfsOwM1cffYkFhog17Yx56w7gf6OOjNc8aX/tUEVHnoEp7FEdy6 DsOUS0nqOM+tlc9TkihHGvU55L147/hfeCpWqKo04IWr0CNHYVAFhApuoVwfWnsAaWwG RkX71xb/fAlP44MvOtR9AwYTXj4Ik/gvzWxW5bfVjOCXFY/HbY9pzUAhbnWT/sZv4tSR hlUw== X-Gm-Message-State: AKS2vOw2qGqihhqhMmz7bwrWJ09QKixbV8PdjsfmmlGmxkxWWf3ge8tw L2TPQnF9xB1R8jrWmRHQS1sxR2BJiKgY X-Received: by 10.107.58.135 with SMTP id h129mr40632516ioa.25.1499223219074; Tue, 04 Jul 2017 19:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:53:18 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 4 Jul 2017 19:53:18 -0700 Message-ID: To: Bernard Aboba Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a114ac88669edc50553891bfc" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-ip-handling (part 1) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:53:43 -0000 --001a114ac88669edc50553891bfc Content-Type: text/plain; charset="UTF-8" Thanks for the review. Most of these comments have been resolved in the latest version of the document, https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04. On Tue, May 9, 2017 at 3:43 PM, Bernard Aboba wrote: > > > General points: > > a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.). > Done. > > > > Details > > 1 . Introduction > > > As a technology that supports peer-to-peer connections, WebRTC may > send data over different network paths than the path used for HTTP > traffic. This may allow a web application to learn additional > information about the user, which may be problematic in certain > cases. This document summarizes the concerns, and makes > recommendations on how best to handle the tradeoff between privacy > and media performance. > > > [BA] There are a number of distinct privacy issues that WebRTC > > needs to address. I believe this document is focussed on IP > > address info that can be gleaned by Web applications (the > > second sentence). That is somewhat distinct from what information > > a web server might glean, or what a passive observer might be > > able to obtain looking at traffic generated by a WebRTC client. > > The first sentence therefore is a bit confusing to me. > > > A suggestion: > > > "As a technology that attempts to optimize peer-to-peer > > connections by testing connectivity between available > > addresses, WebRTC may allow a web application to learn > > additional information about the user compared to an > > application which only utilizes HTTP. This may be > > problematic in certain cases." > > Done. > > 2 . Problem Statement > > > WebRTC enables real-time peer-to-peer communications by enumerating > network interfaces and discovering the best route through the ICE > [RFC5245 ]protocol. During the ICE process, the peers involved in a > session gather and exchange all the IP addresses they can discover, > so that the connectivity of each IP pair can be checked, and the best > path chosen. The addresses that are gathered usually consist of an > endpoint's private physical/virtual addresses, and its public > Internet addresses. > > > [BA] The terms "route" and "path" used here do not refer to IP > > routing and so is a bit confusing. How about this? > > > "In order to enable peer-to-peer communications, WebRTC > > peers utilize ICE [RFC5245] which gathers and exchanges > > all the IP addresses it can discover, so that the > > connectivity of each IP pair can be checked, and the best > pair can be chosen. The addresses that are gathered > > usually consist of an endpoint's private physical/virtual > > addresses, and its public Internet addresses." > > Done. > > > 2. If the client tries to hide its physical location through a VPN, > and the VPN and local OS support routing over multiple interfaces > (i.e., a "split-tunnel" VPN), WebRTC will discover the public > address for the VPN as well as the ISP public address that the > VPN runs over. > > > [BA] Even if the local OS doesn't support split-tunnel, > > isn't it still possible for an ICE implementation to > > discover other addresses? > > > > Yes, but these addresses are typically RFC1918 addresses, and thereby covered by the prior bullet. > 3 . Goals > > Being peer-to-peer, WebRTC represents a privacy-enabling technology, > and therefore we want to avoid solutions that disable WebRTC or make > it harder to use. This means that WebRTC should be configured by > default to only reveal the minimum amount of information needed to > establish a performant WebRTC session, while providing options to > reveal additional information upon user consent, or further limit > this information if the user has specifically requested this. > Specifically, WebRTC should: > > > o Provide a privacy-friendly default behavior which strikes the > right balance between privacy and media performance for most users > and use cases. > > > o For users who care more about one versus the other, provide a > means to customize the experience. > > > [BA] This section might state whether it is a > > goal to enable WebRTC to be used with > > The Onion Routing network (Tor). There > > are a number of reasons why enabling Javascript > > for use with Tor may represent a problem so that > > use of WebRTC might not be advisable: > > https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor > > I checked, and it looks like the default Tor bundle does allow use of JS, which makes it somewhat problematic to argue against here, given that one could support Tor with Mode 4. Tracking this issue in https://github.com/juberti/draughts/issues/60. > 4 . Detailed Design > > > 1. By default, WebRTC should follow normal IP routing rules, to the > extent that this is easy to determine (i.e., not considering > proxies). This can be accomplished by binding local sockets to > the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which > allows the OS to route WebRTC traffic the same way as it would > HTTP traffic, and allows only the 'typical' public addresses to > be discovered. > > > [BA] This paragraph discusses routing behavior and > address binding together and leads me to wonder whether > some assumptions aren't being made (e.g. weak versus > strong host model). My suggestion is to simplify the > the paragraph and leave details to later on. For example: > > "1. By default WebRTC should only allow applications > to discover the same address information made available > by an HTTP application: the 'typical' public address > > " > > Agree that the info about wildcard binding could be moved later to the mode definitions, although I don't follow exactly what you mean by 'weak vs strong host model'. Tracking in https://github.com/juberti/draughts/issues/61. --001a114ac88669edc50553891bfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review. Most of these comments have been re= solved in the latest version of the document,=C2=A0https://tools.ietf.org/htm= l/draft-ietf-rtcweb-ip-handling-04.

<= div class=3D"gmail_quote">On Tue, May 9, 2017 at 3:43 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:


Gener= al points:

a. Please expand acronyms on first use = (e.g. HTTP, VPN, ICE, etc.).=C2=A0

<= div>Done.



Details

1.  Introducti=
on

   As a technology that supports peer-to-p=
eer connections, WebRTC may
   send data over different network paths than the path used for HTTP
   traffic.  This may allow a web application to learn additional
   information about the user, which may be problematic in certain
   cases.  This document summarizes the concerns, and makes
   recommendations on how best to handle the tradeoff between privacy
   and media performance.

[BA] There are a number of distinct privacy issues that WebR=
TC
needs=
 to address. I believe this document is focussed on IP
address info that can be gle=
aned by Web applications (the
second sentence).  That is somewhat distinct from wha=
t information
a web server might glean, or what a passive observer might be
able to obtain = looking at traffic generated by a WebRTC client.
The first sentence therefore is a =
bit confusing to me.

A suggestion:

"As a technology that attempts to optimize peer-to-peer
connectio=
ns by testing connectivity between available
addresses, WebRTC may allow a web appl=
ication to learn
additional information about the user compared to an
application which onl=
y utilizes HTTP.  This may be
problematic in certain cases."
=

Done.

<=
span class=3D"gmail-m_-7014505138885832957gmail-h2" style=3D"line-height:0p=
t;display:inline;font-size:1em;font-weight:bold">
2.  Problem Stateme=
nt

   WebRTC enables re=
al-time peer-to-peer communications by enumerating
   network interfaces and discovering the best route through the ICE
   [RF=
C5245]protocol.  During the ICE process, the peers involved in a
   session gather and exchange all the IP addresses they can discover,
   so that the connectivity of each IP pair can be checked, and the best
   path chosen.  The addresses that are gathered usually consist of an
   endpoint's private physical/virtual addresses, and its public
   Internet addresses.
[BA] The terms "r=
oute" and "path" used here do not refer to IP
routing and so is a bit confusing.  How=
 about this? 

<=
pre class=3D"gmail-m_-7014505138885832957gmail-newpage" style=3D"font-size:=
13.3333px;margin-top:0px;margin-bottom:0px">
   "In order to enable peer-to-peer communications, WebR=
TC
   peers utilize ICE [=
RFC5245] which gathers and exchanges
   all the IP addresses it can discover, so that the 
   connectivity of each IP pair ca=
n be checked, and the best
   pair can be chosen.  The addresses that are gathered
   usually consist of an endpoint's priv=
ate physical/virtual
   a=
ddresses, and its public Internet addresses."
<= /div>

Done.
=C2=A0
=

   2.  If the client tries to hide its phys=
ical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.
[BA] Even if the local =
OS doesn't support split-tunnel,
isn't it still possible for an ICE implementation to
<=
pre class=3D"gmail-m_-7014505138885832957gmail-newpage" style=3D"font-size:=
13.3333px;margin-top:0px;margin-bottom:0px">discover other addresses? 
<=
/pre>
3.  Goals


   Being peer-to-peer, WebRTC represents a privacy-enabling technology,
   and therefore we want to avoid solutions that disable WebRTC or make
   it harder to use.  This means that WebRTC should be configured by
   default to only reveal the minimum amount of information needed to
   establish a performant WebRTC session, while providing options to
   reveal additional information upon user consent, or further limit
   this information if the user has specifically requested this.
   Specifically, WebRTC should:

   o  Provide a privacy-friendly default be=
havior which strikes the
      right balance between privacy and media performance for most users
      and use cases.


   o  For users who care=
 more about one versus the other, provide a
      means to customize the experience.

[BA]=
 This section might state whether it is a 
goal to enable WebRTC to be used with 
The Onion Routing network (Tor). There
are a number of reasons why e=
nabling Javascript
for  u=
se with Tor may represent a problem so that
use of WebRTC might not be advisable:
https:/=
/security.stackexchange.com/questions/95046/why-disable-javascrip=
t-in-tor

I checked, and it looks like the default Tor bundle= does allow use of JS, which makes it somewhat problematic to argue against= here, given that one could support Tor with Mode 4.=C2=A0

Tracking this issue in=C2=A0https://github.com/juberti/draughts/issues/60.
 
4.  Detailed Design

   1.  By default, WebRTC should =
follow normal IP routing rules, to the
       extent that this is easy to determine (i.e., not considering
       proxies).  This can be accomplished by binding local sockets to
       the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
       allows the OS to route WebRTC traffic the same way as it would
       HTTP traffic, and allows only the 'typical' public addresses=
 to
       be discovered.


[BA] This paragraph discusses routing behavior an=
d
address binding together and leads me to wonder whether
some assumptions aren't being made (e.g. weak versus
stron= g host model). My suggestion is to simplify the
the paragraph an= d leave details to later on. For example:

"1.= By default WebRTC should only allow applications
to discover the= same address information made available
by an HTTP application: = the 'typical' public address=C2=A0
"

Agree that the info= about wildcard binding could be moved later to the mode definitions, altho= ugh I don't follow exactly what you mean by 'weak vs strong host mo= del'.

Tracking in=C2=A0https://github.com/juberti/draughts/issues/61.

--001a114ac88669edc50553891bfc-- From nobody Tue Jul 4 19:55:38 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A546E12EAFF for ; Tue, 4 Jul 2017 19:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHxgJMESeRBr for ; Tue, 4 Jul 2017 19:55:34 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A131243FE for ; Tue, 4 Jul 2017 19:55:34 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m84so79240712ita.0 for ; Tue, 04 Jul 2017 19:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9DMadBKAjhPOUhUU+xjg+9Wmz4SyZHR8GCzXogdvmQc=; b=S+iVNhKd6721FN7G1WA0kGWq6v7tAfi3nIm8rKn48e+bsWToGyH/zXlEgEoShXcHX0 ItxTsCCdObz+vhvjBCkdZYu5FfvSROHJBDZmnottQNklze7467Ap+b5PaO3tTAteqDgf vwXAPCCEOOHPcgeDGeG5xqJjQKfbNUd7S/oSoKhde82rj+sIymc3dpHzKQCCyc0FEy2w wA9mEvdB47Cwbahc0QUJE48Xe+2YIIklRvre4NlqNIGlX9K72dRDt9pEw+pn9/Ti5BjU 16N+wFTdSoxPsK46okbLLb8hd5BodiEPILyYcTYy82r417eK/pylWCajFAj1/I0pGod8 uE2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9DMadBKAjhPOUhUU+xjg+9Wmz4SyZHR8GCzXogdvmQc=; b=r7C8SZ4ty8v4M3tenguy/1ZOGHg3YXypdkHiOSkPoHmWO4MiaJYyOCKOcwwhSmPw3J snEBKukNNFecgFlNxwlLi9l3IJXYLiB7DQ0PC3bSh6sIeCMKnt3qnRv1UZusm9OdGg+o ryot/DooIlOMqNvMLmtREkkEGWolzT1fKNB/xnIay+By0dTS972SMVXKa5C/6L9S3s4x eLpZDEyQ0YdC6k5SXRalbRYQKEPYS/J1gIlNkiHzVFkHN0fhDEs9mCqqRS1ZQghNmZbG bnKDpk4rsDMZP0Ecx0m5VtEf7iR1kxqbW9luD1kd24i/5dqS/RWS638NkkGa0FVCwe/1 8TVw== X-Gm-Message-State: AIVw1110dSxRTCmkbLsVwgRFv76WPcirQWuiOnZaPUBDsj1zT4FbMKG7 nonnyD3adpMAxMUFl0tZDAK69YbADdkH X-Received: by 10.36.33.210 with SMTP id e201mr15729292ita.112.1499223333277; Tue, 04 Jul 2017 19:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:55:12 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 4 Jul 2017 19:55:12 -0700 Message-ID: To: Martin Thomson Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a11474a7238a48905538922db" Archived-At: Subject: Re: [rtcweb] Review of ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:55:36 -0000 --001a11474a7238a48905538922db Content-Type: text/plain; charset="UTF-8" Thanks for the review. Most of these comments have been resolved in the latest version of the document, https://tools.ietf. org/html/draft-ietf-rtcweb-ip-handling-04, aside from the Section 3 and RETURN issues, which I hope to address shortly. On Tue, May 9, 2017 at 6:46 PM, Martin Thomson wrote: > In Section 3, please don't imply that WebRTC is only for privacy. At > a minimum "Being peer-to-peer, WebRTC represents a technology that > could improve privacy," Though I'd avoid this sort of statement > altogether. One interesting side effect of unintermediated or > peer-to-peer communications is that there is now network-level > metadata showing who was communicating. There is a direct flow > between peers. The privacy gain (no single middleman with access to > communications metadata) becomes a potential loss (passive network > observers can see who was talking more easily). > > I think that Section 3 could be more simply stated as: > > Provide a framework for understanding the problem so that controls > might be provided to make different trade-offs regarding performance > and privacy concerns with WebRTC. Using that framework, define > settings that enable peer-to-peer communications each with a different > balance between performance and privacy. Finally, provide > recommendations about settings that provide reasonable performance > without also exposing addressing information in a way that might > violate user expectations. > > In Section 4, the mention of RETURN isn't really necessary and it will > stall progress of this draft. The framing of RETURN ensures that it > falls into the "proxy" definition quite neatly, so it will work > without changing this draft. Though RETURN would reduce the > performance downsides of the higher-numbered modes - significantly - > it doesn't really need a special mention here. > > I'm not very enthusiastic about this bullet in Section 5: > > o Future versions of browsers may present an indicator to signify > that the page is using WebRTC to set up a peer-to-peer connection. > Applications MUST only use WebRTC in a fashion that is consistent > with user expectations. > > The indicator thing is kinda speculative; based on my experience with > these things, I'd say that the chances that we did that would be close > to zero. Also, the MUST here is completely toothless to the point > that I think it's dangerous. Applications will care to the extent > that they care, and yelling at them isn't going to influence that one > iota. > > Also, since the whole point of this document is to establish a > framework for thinking about this specific problem, I think that it's > safe to remove this sentence. I would remove the entire bullet point. > > Nits: > > Many of the references need to have a space after the closing bracket. > > Remove the reference to 8.8.8.8. It's actually a good example, but > it's not necessary and it is likely to cause some people's heads to > explode. As much as I might personally enjoy that, it's not my > document; you might be better avoiding this. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11474a7238a48905538922db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review. Most of these comments have been re= solved in the latest version of the document,=C2=A0https://= tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04, aside f= rom the Section 3 and RETURN issues, which I hope to address shortly.


On T= ue, May 9, 2017 at 6:46 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
In Section 3, ple= ase don't imply that WebRTC is only for privacy.=C2=A0 At
a minimum "Being peer-to-peer, WebRTC represents a technology that
could improve privacy,"=C2=A0 Though I'd avoid this sort of statem= ent
altogether.=C2=A0 One interesting side effect of unintermediated or
peer-to-peer communications is that there is now network-level
metadata showing who was communicating.=C2=A0 There is a direct flow
between peers.=C2=A0 The privacy gain (no single middleman with access to communications metadata) becomes a potential loss (passive network
observers can see who was talking more easily).

I think that Section 3 could be more simply stated as:

Provide a framework for understanding the problem so that controls
might be provided to make different trade-offs regarding performance
and privacy concerns with WebRTC.=C2=A0 Using that framework, define
settings that enable peer-to-peer communications each with a different
balance between performance and privacy.=C2=A0 Finally, provide
recommendations about settings that provide reasonable performance
without also exposing addressing information in a way that might
violate user expectations.

In Section 4, the mention of RETURN isn't really necessary and it will<= br> stall progress of this draft.=C2=A0 The framing of RETURN ensures that it falls into the "proxy" definition quite neatly, so it will work without changing this draft.=C2=A0 Though RETURN would reduce the
performance downsides of the higher-numbered modes - significantly -
it doesn't really need a special mention here.

I'm not very enthusiastic about this bullet in Section 5:

=C2=A0 =C2=A0o=C2=A0 Future versions of browsers may present an indicator t= o signify
=C2=A0 =C2=A0 =C2=A0 that the page is using WebRTC to set up a peer-to-peer= connection.
=C2=A0 =C2=A0 =C2=A0 Applications MUST only use WebRTC in a fashion that is= consistent
=C2=A0 =C2=A0 =C2=A0 with user expectations.

The indicator thing is kinda speculative; based on my experience with
these things, I'd say that the chances that we did that would be close<= br> to zero.=C2=A0 Also, the MUST here is completely toothless to the point
that I think it's dangerous.=C2=A0 Applications will care to the extent=
that they care, and yelling at them isn't going to influence that one iota.

Also, since the whole point of this document is to establish a
framework for thinking about this specific problem, I think that it's safe to remove this sentence.=C2=A0 I would remove the entire bullet point.=

Nits:

Many of the references need to have a space after the closing bracket.

Remove the reference to 8.8.8.8.=C2=A0 It's actually a good example, bu= t
it's not necessary and it is likely to cause some people's heads to=
explode.=C2=A0 As much as I might personally enjoy that, it's not my document; you might be better avoiding this.

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

--001a11474a7238a48905538922db-- From nobody Tue Jul 4 20:30:52 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D4131673 for ; Tue, 4 Jul 2017 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7IiMgGZfzut for ; Tue, 4 Jul 2017 20:30:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009C9131671 for ; Tue, 4 Jul 2017 20:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30772; q=dns/txt; s=iport; t=1499225446; x=1500435046; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WEYt9iAg/R8l7br+PkMVWHaDTme/gFbvcToLqj68b9o=; b=cUDlnefp5heXjZR5E4374dUXu08lM6x9g1hYxRlFz/cabyIq3wbT+FIU drh+T4TJrTos0ahUdUZ5y+/TX5tqIUnenVaGro/N1ANm+kTvECH9ntb3O GIxDohJC1jcJdrNVi0jYxcixx0fep/G2OOIS4ITzgT7M6kBu7r9+pr+HU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AAADXVxZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4EQjgmRUCKWAIEyA1wshSFPAoMKPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMnUhACAQgOAwMBAh4DBwcyFAkIAgQOBYlLZBC0MjqLPAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgyeDTIFhKwuCboUKFoMNgjEFlymHXQKHRYNFiHmCDJA?= =?us-ascii?q?SiTWLfQEfOEw+dRVJEgGER4I7dohpAQEB?= X-IronPort-AV: E=Sophos;i="5.40,310,1496102400"; d="scan'208,217";a="268966687" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 03:30:45 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v653Uj7L002471 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Jul 2017 03:30:45 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Jul 2017 22:30:44 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 4 Jul 2017 22:30:45 -0500 From: "Mo Zanaty (mzanaty)" To: Justin Uberti CC: "rtcweb@ietf.org" Thread-Topic: Review of draft-ietf-rtcweb-fec Thread-Index: AQHS9Tki66/2+ROPeE2IVOtnyOXoSKJEk7nD Date: Wed, 5 Jul 2017 03:30:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_BCEFB767206742D7BD2E7579E542CEB3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 03:30:51 -0000 --_000_BCEFB767206742D7BD2E7579E542CEB3ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All changes look good to me. Thanks, Mo On Jul 4, 2017, at 10:48 PM, Justin Uberti > wrote: These issues have all been resolved in the latest version of the draft, htt= ps://tools.ietf.org/html/draft-ietf-rtcweb-fec-06. On Sat, Apr 22, 2017 at 12:39 PM, Justin Uberti > wrote: On Mon, Apr 17, 2017 at 12:07 PM, Mo Zanaty (mzanaty) > wrote: Agreed on all responses, except some further clarifications inline, see Mo:= . From: Justin Uberti > Date: Friday, April 14, 2017 at 6:45 PM To: mzanaty > Cc: "rtcweb@ietf.org" > Subject: Re: Review of draft-ietf-rtcweb-fec Thanks for this detailed review. On Fri, Apr 7, 2017 at 7:17 PM, Mo Zanaty (mzanaty) > wrote: Here is my review of draft-ietf-rtcweb-fec-04. 4.1. Recommended Mechanism (for audio FEC), first paragraph says: OLD: "When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against typical losses, with modest overhead. Note that as indicated above the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the built-in FEC should be combined with [RFC2198] redundancy to protect the N-2th, N-3rd, etc. packets." The last sentence about multi-packet protection should not be recommended d= ue to overhead. Packing multiple full-size Opus frames, each with their own= built-in prior-frame FEC, into RED packets is akin to packing multiple PCM= U frames into RED packets. The latter is discouraged 3 paragraphs later: "When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] redundant encoding MAY be used, but note that this will result in a potentially significant bitrate increase, and that suddenly increasing bitrate to deal with losses from congestion may actually make things worse." These same warnings would apply to multi-packet Opus RED. Therefore I sugge= st rewording the first paragraph as follows. NEW: "When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against typical losses, with modest overhead. Note that as indicated above the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the built-in FEC MAY be combined with [RFC2198] redundancy to protect prior packet pairs, but note this will result in significant bitrate increase which may aggravate congestion losses." This isn't quite as bad as full PCMU frames, because Opus frames will typic= ally be smaller, but I agree it is inconsistent. https://github.com/juberti/draughts/issues/38 4.2. Negotiating Support, first sentence says: OLD: "Support for redundant encoding MUST be indicated by offering "red"..." This may be misinterpreted as mandating that WebRTC endpoints MUST offer "r= ed", rather than merely indicating that if they choose to support redundant= encoding (which is only RECOMMENDED for VBR codecs without internal FEC in= the prior section), then it MUST be indicated by offering "red". I suggest= rewording this as: NEW: "If redundant encoding is supported, it MUST be indicated by offering "red"= ..." The intent here was that all clients should support receipt of 2198, even i= f they don't support sending a redundant encoding (which is only, as you sa= y, RECOMMENDED). IOW, "red" would be a MTI format. Mo: MTI "red" only if you support VBR codecs without internal FEC (which ar= e optional not MTI audio codecs), right? If so, I would explicitly indicate= this via "Support for redundant encoding of VBR codecs without internal FE= C MUST..." Or do you mean MTI regardless of codecs, like even for Opus? That would sur= prise me, to make "red" MTI when it is not recommended for the MTI audio co= decs, and no browser advertises "red" for audio. This makes sense to me. As indicated above, there isn't enough rationale to= mandate "red" support. However, I am thinking of making "red" support SHOULD strength, since at pr= esent it's our best available tool for handling burst losses. https://github.com/juberti/draughts/issues/39 Same comment for Opus in the following paragraph: OLD: "For Opus, a receiver MUST indicate that it is prepared to use incoming FEC data with the "useinbandfec=3D1" parameter..." NEW: "For Opus, a receiver that it is prepared to use incoming FEC data MUST include the "useinbandfec=3D1" parameter..." Similarly here - for WebRTC, the intent was to mandate support for receivin= g and using Opus FEC. Mo: Ok, this one makes sense to be MTI. 5.1. Recommended Mechanism (for video FEC) says: OLD: "For video content, use of a separate FEC stream with the RTP payload format described in [I-D.ietf-payload-flexible-fec-scheme] is RECOMMENDED. The receiver can demultiplex the incoming FEC stream by SSRC and correlate it with the primary stream via the SSRC field present in the FEC header." Flex FEC moved the SSRC binding from the FEC header to the CSRC list. Only = the retransmission format still has the SSRC field in the FEC header. Rewor= d as: NEW: "For video content, use of a separate FEC stream with the "flexfec" RTP pay= load format described in [I-D.ietf-payload-flexible-fec-scheme] is RECOMMENDED. The receiver can demultiplex the incoming FEC stream by SSRC and correlate it with the primary stream(s) via the CSRC(s) in the RTP header of the FEC repair packet, or via the SSRC field in the FEC header for retransmissions." OK. https://github.com/juberti/draughts/issues/40 The next paragraph suggests multiple source streams is a problem. OLD: "Support for protecting multiple primary streams with a single FEC stream is complicated by WebRTC's 1-m-line-per-stream policy, which does not allow for a m-line dedicated specifically to FEC." But Flex FEC already supports this with SSRC(s) of primary stream(s) as CSR= C(s) of the FEC stream, so strike the above OLD paragraph. It's still not clear how this should work. Which m=3D lines would carry FEC= info for which other m=3D lines? Mo: Flex FEC can protect multiple primary streams as long as they are in th= e same RTP session (SSRC space), e.g. when bundled. There is no SDP associa= tion between source and repair streams for Flex FEC. The association is at = the RTP level with SSRCs, so a Flex FEC packet can protect any RTP packet(s= ) in the same RTP session. In SDP, any bundled m=3D line(s) can declare the= flexfec PT. JSEP requires all of them to declare it, which seems best. If we are going to support this, I think we need to detail in this document= how it should work, and it may have downstream ramifications on JSEP. Mo: JSEP says the FEC PT must be included in all m=3D lines, which seems be= st/correct. OK, this is a welcome development. I will update this section accordingly t= o give an overview of how this should work, which will be a nontrivial upda= te. https://github.com/juberti/draughts/issues/45 8. Adaptive Use of FEC, first paragraph says: OLD: "...methods like RTX [RFC4588], which only transmits redundant data when...= " Flex FEC also supports retransmissions, so reword as: NEW: "...methods like RTX [RFC4588] or the "flexfec" retransmission format, which only transmits redundant data when..." Same comment in the next paragraph. OLD: "Given this, WebRTC implementations SHOULD consider using RTX instead..." NEW: "Given this, WebRTC implementations SHOULD consider using RTX or the "flexfec" retransmission format instead..." https://github.com/juberti/draughts/issues/41 9. Security Considerations Add a final paragraph on the order of FEC and SRTP operations. NEW: "SRTP [RFC3711] defines the default order of FEC and SRTP as FEC followed b= y SRTP at the sender, and SRTP followed by FEC at the receiver. DTLS-SRTP [= RFC5764] uses this same default order for all SRTP Protection Profiles." https://github.com/juberti/draughts/issues/42 Editorial: Abstract and Introduction should use WebRTC "endpoint" as defined in -overv= iew. Abstract: "... FEC ... used by WebRTC applications" -> WebRTC endpoints Introduction: "... FEC ... for WebRTC client implementations" -> WebRTC end= points Or you could be very generic and just say WebRTC implementations everywhere= . I think WebRTC implementations is best, since these are guidelines for WebR= TC implementors, not application implementors. https://github.com/juberti/draughts/issues/43 --_000_BCEFB767206742D7BD2E7579E542CEB3ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All changes look good to me. 

Thanks,
Mo

On Jul 4, 2017, at 10:48 PM, Justin Uberti <juberti@google.com> wrote:

These issues have all been resolved in the latest version = of the draft, https://to= ols.ietf.org/html/draft-ietf-rtcweb-fec-06.

On Sat, Apr 22, 2017 at 12:39 PM, Justin Uberti = <juberti@google.= com> wrote:


On Mon, Apr 17, 2017 at 12:07 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.co= m> wrote:
Agreed on all responses, except some further clarifications inline, se= e Mo:.

From: Justin Uberti <juberti@google.com>
Date: Friday, April 14, 2017 at 6:4= 5 PM
To: mzanaty <mzanaty@cisco.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: Review of draft-ietf-r= tcweb-fec

Thanks for this detailed review. 

On Fri, Apr 7, 2017 at 7:17 PM, Mo Zanaty (mzana= ty) <mzanaty@cisco.co= m> wrote:
Here is my review of draft-ietf-rtcweb-fec-04.

4.1. Recommended Mechanism (for audio FEC), first paragraph says:

OLD:
"When using the Opus codec, use of the built-in Opus FEC mechanis= m is
RECOMMENDED. This provides reasonable protection of the audio stream
against typical losses, with modest overhead. Note that as indicated
above the built-in Opus FEC only provides single-frame redundancy; if<= /div>
multi-packet protection is needed, the built-in FEC should be
combined with [RFC2198] redundancy to protect the N-2th, N-3rd, etc= .
packets."

The last sentence about multi-packet protection should not be recommen= ded due to overhead. Packing multiple full-size Opus frames, each with thei= r own built-in prior-frame FEC, into RED packets is akin to packing multipl= e PCMU frames into RED packets. The latter is discouraged 3 paragraphs later:

"When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198]<= /div>
redundant encoding MAY be used, but note that this will result in a
potentially significant bitrate increase, and that suddenly
increasing bitrate to deal with losses from congestion may actually
make things worse."

These same warnings would apply to multi-packet Opus RED. Therefore I = suggest rewording the first paragraph as follows.

NEW:
"When using the Opus codec, use of the built-in Opus FEC mechanis= m is
RECOMMENDED. This provides reasonable protection of the audio stream
against typical losses, with modest overhead. Note that as indicated
above the built-in Opus FEC only provides single-frame redundancy; if<= /div>
multi-packet protection is needed, the built-in FEC MAY be
combined with [RFC2198] redundancy to protect prior packet pairs,
but note this will result in significant bitrate increase which may=
aggravate congestion losses."

This isn't quite as bad as full PCMU frames, because Opus frames will = typically be smaller, but I agree it is inconsistent.

 

4.2. Negotiating Support, first sentence says:

OLD:
"Support for redundant encoding MUST be indicated by offer= ing "red"..."

This may be misinterpreted as mandating that WebRTC endpoints MUST off= er "red", rather than merely indicating that if they choose to su= pport redundant encoding (which is only RECOMMENDED for VBR codecs without = internal FEC in the prior section), then it MUST be indicated by offering "red". I suggest rewording this as= :

NEW:
"If redundant encoding is supported, it MUST be indicated = by offering "red"..."

The intent here was that all clients should support receipt of 2198, e= ven if they don't support sending a redundant encoding (which is only, as y= ou say, RECOMMENDED). IOW, "red" would be a MTI format.

Mo: MTI "red" only if you support VBR codecs without interna= l FEC (which are optional not MTI audio codecs), right? If so, I would expl= icitly indicate this via "Support for redundant encoding of VBR codecs without internal FEC = MUST..."
Or do you mean MTI regardless of codecs, like even for Opus? That woul= d surprise me, to make "red" MTI when it is not recommended for t= he MTI audio codecs, and no browser advertises "red" for audio.

This makes sense to me. As indicated above, there isn't enough rationa= le to mandate "red" support.

However, I am thinking of making "red" support SHOULD streng= th, since at present it's our best available tool for handling burst losses= .

 
 
Same comment for Opus in the following paragraph:

OLD:
"For Opus, a receiver MUST indicate that it is prepared to use=
incoming FEC data with the "useinbandfec=3D1" paramet= er..."

NEW:
"For Opus, a receiver that it is prepared to use incoming FEC = data
MUST include the "useinbandfec=3D1" parameter..."= ;

Similarly here - for WebRTC, the intent was to mandate support for receivi= ng and using Opus FEC.

Mo: Ok, this one makes sense to be MTI.
 
5.1. Recommended Mechanism (= for video FEC) says:

OLD:
"For video content, use of a separate FEC stream with the RTP pay= load
format described in [I-D.ietf-payload-flexible-fec-scheme] is
RECOMMENDED. The receiver can demultiplex the incoming FEC stream by
SSRC and correlate it with the primary stream via the SSRC field
present in the FEC header."

Flex FEC moved the SSRC binding from the FEC header to the CSRC list. = Only the retransmission format still has the SSRC field in the FEC header. = Reword as:

NEW:
"For video content, use of a separate FEC stream with the "f= lexfec" RTP payload
format described in [I-D.ietf-payload-flexible-fec-scheme] is
RECOMMENDED. The receiver can demultiplex the incoming FEC stream by
SSRC and correlate it with the primary stream(s) via the CSRC(s)
in the RTP header of the FEC repair packet, or via the SSRC field
in the FEC header for retransmissions."


The next paragraph suggests multiple source streams is a problem.

OLD:
"Support for protecting multiple primary streams with a single FE= C
stream is complicated by WebRTC's 1-m-line-per-stream policy, which
does not allow for a m-line dedicated specifically to FEC."

But Flex FEC already supports this with SSRC(s) of primary stream(s) a= s CSRC(s) of the FEC stream, so strike the above OLD paragraph.

It's still not clear how this should work. Which m=3D lines would carr= y FEC info for which other m=3D lines?

Mo: Flex FEC can protect multiple primary streams as long as they are in t= he same RTP session (SSRC space), e.g. when bundled. There is no SDP associ= ation between source and repair streams for Flex FEC. The association is at the RTP level with SSRCs, so a Flex FE= C packet can protect any RTP packet(s) in the same RTP session. In SDP, any= bundled m=3D line(s) can declare the flexfec PT. JSEP requires all of them= to declare it, which seems best. 

If we are going to support this, I think we need to detail in this doc= ument how it should work, and it may have downstream ramifications on JSEP.=

Mo: JSEP says the FEC PT must be included in all m=3D lines, which seems b= est/correct.

OK, this is a welcome development. I will update this section accordin= gly to give an overview of how this should work, which will be a nontrivial= update. 

 
8. Adaptive Use of FEC, firs= t paragraph says:

OLD:
"...methods like RTX= [RFC4588], which only transmits redundant data when..."

Flex FEC also supports retra= nsmissions, so reword as:

NEW:
"...methods like RTX [RFC4588] or the "flexfec" retr= ansmission format,
which only transmits redundant data when..." 

Same comment in the next paragraph.

OLD:
"Given this, WebRTC imp= lementations SHOULD consider using RTX instead..."

NEW:
"Given this, WebRTC imp= lementations SHOULD consider using RTX or
the "flexfec" r= etransmission format instead..."


 
9. Security Considerations

Add a final paragraph on the= order of FEC and SRTP operations.

NEW:
"SRTP [RFC3711] defi= nes the default order of FEC and SRTP as FEC followed by SRTP at the sender= , and SRTP followed by FEC at the receiver. DTLS-SRTP [RFC5764] uses this s= ame default order for all SRTP Protection Profiles."


Editorial:

Abstract and Introduction sh= ould use WebRTC "endpoint" as defined in -overview.
Abstract: "... FEC ... = used by WebRTC applications" -> WebRTC endpoints
Introduction: "... FEC = ... for WebRTC client implementations" -> WebRTC endpoints
Or you could be very generic= and just say WebRTC implementations everywhere.

I think WebRTC implementations is best, since these are guidelines for= WebRTC implementors, not application implementors.



--_000_BCEFB767206742D7BD2E7579E542CEB3ciscocom_-- From nobody Wed Jul 5 13:18:15 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C5131DD6 for ; Wed, 5 Jul 2017 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m55swLyAU03 for ; Wed, 5 Jul 2017 13:18:13 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86E9131DCC for ; Wed, 5 Jul 2017 13:18:12 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id r30so195965130qtc.0 for ; Wed, 05 Jul 2017 13:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rqiIj+vwDErI7CcmCmde8HTfvSNSQoQPhIGV5qb0lFQ=; b=ELTXGszawdqkw7Ue3uDOZLZVJfvSGSodh0vvCJqmAuKItFATL8R6XRUyG7kWjmHiLL zsJ8RJpfnLUTewdJskq7K4WEHjWPj8ZvTquKxGWwIZnGV3dcwzJSyL6EtlIWEonLVnjW 7EjrdiQXPPuezqYt6H/bsZxcrynriXae6MjQjKgp5MedxPuq5e29V34rY958ukGYEuPM ul/ppXCpaWr3zMDOnHgek0JFDqCUnBQlo9DHO8NGDNCvKbZoI/pQF5OzjJizdT5nvJTh mg4orC2c4JgceTO1EPD0mC/t+lne8nUqULz3cro6mJsdHgCLorlCovLbqVPQ7eeQFBlf OyYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rqiIj+vwDErI7CcmCmde8HTfvSNSQoQPhIGV5qb0lFQ=; b=irG7/5byyzfN42QeCTiPYknvQ9jCiEKl5kLg+27jCduP7TQ7AndgBn1PWr8u4ieYL0 KOcQEr5lUPq+vaevrubXzUA3ZH5609Rx3OKChE2/zRP2s/HO2Iraam8Q/aGYgA2ag2Bu dQ/muD2lA882fzaszFRct95pIDel7c+Ppfyl02n2pFimhyaK6Z/tQS0v0z6WNFSW33px VLUWsDLz5lWMX880bHP7+XiUkdLjnBSVYvGSFUNVRmiphBNfXX3kCL5ixP0k9u9f539z ZDLG5okHKFXRj0Y2ByS3x/uc/e4l8aPCU8RvdEvzefvWZ77KkYd4BX29KdWFrQQX39ao OGWw== X-Gm-Message-State: AKS2vOwiGZByNUxzkA7HoeopIAWIQkkDlvFgKWAlJRkT0G1hfLxSToAl dK5RdLMJdfKvkDO8OtgXgJax+83P0w== X-Received: by 10.200.40.73 with SMTP id 9mr58690872qtr.37.1499285891688; Wed, 05 Jul 2017 13:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.21 with HTTP; Wed, 5 Jul 2017 13:17:41 -0700 (PDT) From: Ted Hardie Date: Wed, 5 Jul 2017 13:17:41 -0700 Message-ID: To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , Adam Roach Content-Type: multipart/alternative; boundary="001a11411a5cfdaf49055397b27e" Archived-At: Subject: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:18:14 -0000 --001a11411a5cfdaf49055397b27e Content-Type: text/plain; charset="UTF-8" Howdy, We have a new version of JSEP which incorporates changes in response to Adam's AD review. Please review those changes between now and July 21, 2017 (the end of IETF 99), in preparation for the IETF last call. A strong focus on those changes, rather than re-opening old discussions, is appreciated. regards, Ted, Cullen, Sean --001a11411a5cfdaf49055397b27e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

We have a new version o= f JSEP which incorporates changes in response to Adam's AD review.=C2= =A0 Please review those changes between now and July 21, 2017 (the end of I= ETF 99), in preparation for the IETF last call.=C2=A0 A strong focus on tho= se changes, rather than re-opening old discussions, is appreciated.

=
regards,

Ted, Cullen, Sean
--001a11411a5cfdaf49055397b27e-- From nobody Wed Jul 5 23:22:59 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C998127076 for ; Wed, 5 Jul 2017 23:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0S4fv3U_E6y for ; Wed, 5 Jul 2017 23:22:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10B51200CF for ; Wed, 5 Jul 2017 23:22:55 -0700 (PDT) X-AuditID: c1b4fb25-9d2719c000001eeb-06-595dd73d3fc5 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.77.07915.D37DD595; Thu, 6 Jul 2017 08:22:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 08:22:12 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , "Adam Roach" Thread-Topic: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 Thread-Index: AQHS9cvXgVxI/wH0GUOuncNfdsVt2qJGVJ8Q Date: Thu, 6 Jul 2017 06:22:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC52692@ESESSMB109.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CC52692ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7lq7t9dhIg4PHxS32/F3EbtExmc1i 7b92dosrqxqZLRrn2jmwekz5vZHVY+esu+weS5b8ZPKYtfMJi8fBg4wBrFFcNimpOZllqUX6 dglcGfP7LjAWzLCo6H+wlamB8YxZFyMnh4SAicTJrV0sXYxcHEICRxglHt97xgThLGKUWP7k C1CGg4NNwEKi+582SFxEYD2jxNuJqxlB4sIC7hJzH7uDDBIR8JDYv3UjO4RtJNFzdjoriM0i oCJxfEYjWJxXwFdi5d9GFhBbSCBAYt2/xawgYzgFAiXu/DcECTMKiEl8P7WGCcRmFhCXuPVk PhPEnQISS/acZ4awRSVePv7HCmErSTQuecIKUZ8v8WLfamaIVYISJ2c+YZnAKDwLyahZSMpm ISmbBXQFs4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWpyUm25krJdalJlcXJyf p5eXWrKJERhxB7f8Vt3BePmN4yFGAQ5GJR7eCUdiI4VYE8uKK3MPMUpwMCuJ8B46CRTiTUms rEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBMdNj6gp+fp248w/E L2ZqvX96Zop9c521Mk/J9quXLXQvvJ70e1/pzVeHdu9rFHr6ddtpr3Vyjc1+e5oW3G5jbeBd qrrw7vbJenGe3Hc1dS04p149nJfs81hAPnem2L3OhccneG5W2F93j3v51efxO5NWRr2xPTo1 f9E/j31pGhN93yydYXLy9WElluKMREMt5qLiRABY42QPtAIAAA== Archived-At: Subject: Re: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 06:22:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CC52692ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBub3Qgc2VlbiBhIGNvbmNsdXNpb24gdG8gdGhlIHdoYXQtSUNFLXNwZWMt dG8tcmVmZXJlbmNlIGRpc2N1c3Npb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206 IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVk IEhhcmRpZQ0KU2VudDogMDUgSnVseSAyMDE3IDIyOjE4DQpUbzogcnRjd2ViQGlldGYub3JnOyBT ZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+OyBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNj by5jb20+OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPg0KU3ViamVjdDogW3J0Y3dlYl0g V29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcC0yMQ0KDQpIb3dk eSwNCldlIGhhdmUgYSBuZXcgdmVyc2lvbiBvZiBKU0VQIHdoaWNoIGluY29ycG9yYXRlcyBjaGFu Z2VzIGluIHJlc3BvbnNlIHRvIEFkYW0ncyBBRCByZXZpZXcuICBQbGVhc2UgcmV2aWV3IHRob3Nl IGNoYW5nZXMgYmV0d2VlbiBub3cgYW5kIEp1bHkgMjEsIDIwMTcgKHRoZSBlbmQgb2YgSUVURiA5 OSksIGluIHByZXBhcmF0aW9uIGZvciB0aGUgSUVURiBsYXN0IGNhbGwuICBBIHN0cm9uZyBmb2N1 cyBvbiB0aG9zZSBjaGFuZ2VzLCByYXRoZXIgdGhhbiByZS1vcGVuaW5nIG9sZCBkaXNjdXNzaW9u cywgaXMgYXBwcmVjaWF0ZWQuDQpyZWdhcmRzLA0KVGVkLCBDdWxsZW4sIFNlYW4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CC52692ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5JIGhhdmUgbm90IHNlZW4gYSBjb25jbHVzaW9uIHRvIHRoZSB3aGF0LUlD RS1zcGVjLXRvLXJlZmVyZW5jZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2Vi IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRl ZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gMDUgSnVseSAyMDE3IDIyOjE4PGJyPg0KPGI+VG86 PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IFNlYW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNvbSZndDs7 IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1ZmZ5QGNpc2NvLmNvbSZndDs7IEFkYW0gUm9hY2ggJmx0 O2FkYW1Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIFdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtcnRjd2ViLWpzZXAtMjE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkhvd2R5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldlIGhhdmUgYSBuZXcg dmVyc2lvbiBvZiBKU0VQIHdoaWNoIGluY29ycG9yYXRlcyBjaGFuZ2VzIGluIHJlc3BvbnNlIHRv IEFkYW0ncyBBRCByZXZpZXcuJm5ic3A7IFBsZWFzZSByZXZpZXcgdGhvc2UgY2hhbmdlcyBiZXR3 ZWVuIG5vdyBhbmQgSnVseSAyMSwgMjAxNyAodGhlIGVuZCBvZiBJRVRGIDk5KSwgaW4gcHJlcGFy YXRpb24gZm9yIHRoZSBJRVRGIGxhc3QgY2FsbC4mbmJzcDsNCiBBIHN0cm9uZyBmb2N1cyBvbiB0 aG9zZSBjaGFuZ2VzLCByYXRoZXIgdGhhbiByZS1vcGVuaW5nIG9sZCBkaXNjdXNzaW9ucywgaXMg YXBwcmVjaWF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVkLCBDdWxsZW4sIFNlYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4CC52692ESESSMB109erics_-- From nobody Thu Jul 6 10:41:29 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A9131868 for ; Thu, 6 Jul 2017 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfmkOR2IQd3n for ; Thu, 6 Jul 2017 10:41:26 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5AD13184A for ; Thu, 6 Jul 2017 10:41:26 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d78so8501905qkb.1 for ; Thu, 06 Jul 2017 10:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xAQmjEKPr0/+Dn9CcfXyxgqygUkTPsPHClwZ+E1gZqE=; b=K3j1BAnSWZwt6PXZUxWSoW8COTFNbZbuWlRhW3DtT2TeW/XbeDgCqw6FB4d+sFu3RZ sxVtdr0Us4UPorICBoKvHtdpoL4BzIcFId4Bg9YDeFISAKWTmtgQ90L2hlrD0ZaXwxdF 0Rt3LDdXe/OX9ZA4fgn/g2cIJ7iYSfP+n+MGHgRjPDB9SfPdG6QR5kTkjJAPlRgkcleh SkDxTyRRIpxhEb1PYyd9TK5MHGoIOvMtkFvaVygwpRIxCj5Iruwo/0n01K40F0j2iO9A 5gRIbnC6/ELpAIyRb0z6qRehyGkrRRHV31ve+TKg0YHqitCVtdthrWmvNez/ntF1Muak 5h8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xAQmjEKPr0/+Dn9CcfXyxgqygUkTPsPHClwZ+E1gZqE=; b=Co320IAHpEZCI91L3Q0jsFhXVbC1WY3V6ssPg70vgDxN6Jc+LKUwdffE7aP9TDJiSL APQoIk26TUju4uFy1Z2RQQ+mLerr/ap4JNGYc65XcFxcnz5n/i1v/Y1dTq/8olZ+obE1 PI+Lypu4br8ZYDUvMa59EvJLHduyC8WH26JElgpkYs/RK2/Dke3xDrSecS1kTDtytFfp hX+fzr8Yx4ajgEGPeYWGZRLvWMCcQwIwd9lShIfA89ZHGnQJ9A6i4Jru4SoLWjUuvhOq 3Z6vWydFzN0Xd5l+vF/xuuvi9kUWDya66WMBOyL2at93IVBznLZkM5aTsvYU41MXr9Jj KHXg== X-Gm-Message-State: AKS2vOyNRSlR9IknvsZJ6C1bQ9o5Vj5nKlL0cdFDeGudO207cj4mSls4 c/91ieTVN73wJoGj38H3FQXTd+dPhA== X-Received: by 10.55.128.130 with SMTP id b124mr57533675qkd.109.1499362885100; Thu, 06 Jul 2017 10:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.21 with HTTP; Thu, 6 Jul 2017 10:40:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC52692@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC52692@ESESSMB109.ericsson.se> From: Ted Hardie Date: Thu, 6 Jul 2017 10:40:54 -0700 Message-ID: To: Christer Holmberg Cc: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , Adam Roach Content-Type: multipart/alternative; boundary="94eb2c05f82227ea0d0553a9a0f1" Archived-At: Subject: Re: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:41:28 -0000 --94eb2c05f82227ea0d0553a9a0f1 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 11:22 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I have not seen a conclusion to the what-ICE-spec-to-reference discussion. > > > After discussion with our area director, the chairs believe that we should go forward as it is currently specified and revisit with the RFC Editor when cluster 238 is ready for publication. I will update the shepherd write-up to note this. regards, Ted > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 05 July 2017 22:18 > *To:* rtcweb@ietf.org; Sean Turner ; Cullen Jennings < > fluffy@cisco.com>; Adam Roach > *Subject:* [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 > > > > Howdy, > > We have a new version of JSEP which incorporates changes in response to > Adam's AD review. Please review those changes between now and July 21, > 2017 (the end of IETF 99), in preparation for the IETF last call. A strong > focus on those changes, rather than re-opening old discussions, is > appreciated. > > regards, > > Ted, Cullen, Sean > --94eb2c05f82227ea0d0553a9a0f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --94eb2c05f82227ea0d0553a9a0f1-- From nobody Thu Jul 6 16:13:49 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA88E131868 for ; Thu, 6 Jul 2017 16:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sxu_sd1MnNi for ; Thu, 6 Jul 2017 16:13:46 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB1D131774 for ; Thu, 6 Jul 2017 16:13:45 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id k192so19358300ith.1 for ; Thu, 06 Jul 2017 16:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=nAQEC0FEWwjKKJIkeNfybHxXiRjvehlw97JF15uPaww=; b=Q9wZlXB9eMy72U4Y8bar+9rVR79FYQqqQZ0BCasAla4Z3a1Il+Y64r9MorUBcoXUej KG0n2oRuzS9J5a1fUO23Nc8FfuxW0BugVTiPeKb6oUBdMhpK3YD+UK5EUEK/TfiTJcs9 xqcvQ/Py/TJxVc4RQ2I4oxhLs+/Wb3E+Igx4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=nAQEC0FEWwjKKJIkeNfybHxXiRjvehlw97JF15uPaww=; b=pqzh5ODIiZuVQppqimfExErshMh4z68izJ3nOmZ5lkuaoJTqIda+p/KwbJhIJQWA9u DgEpsXRKpDh9E9ZTN44NRv0F4bqJ1qazc5d1vRUCWkLSETErirscsbUG0w8TVYMrHEBt hFGJirurrfhR/04Q8bsiLU7GaAeUaLzvEpw9jDaggz4PShSxiGqUv7NVz73ktWMA024X tUBbNcLLdqYbJ0kgninui0f8vm9E9nnEFVPbcw8Dym2gWRP1NyxIT/jRhk2LCHm4QpkP jptHr942Gebfs1KlsCCgqTOEs7YVDEbyZdyQTrW9era4y4I8y1fFDQik0uKznKDMB2dv /Uuw== X-Gm-Message-State: AIVw110u9lTGiJu2yPclKyUImVt5s61kZa6zN94leeidcXNk3vtcBF4Y hNLGycoHroROOpBUnEkHCA== X-Received: by 10.36.68.193 with SMTP id o184mr332469ita.59.1499382824817; Thu, 06 Jul 2017 16:13:44 -0700 (PDT) Received: from [5.5.33.54] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id e80sm870538ite.3.2017.07.06.16.13.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 16:13:43 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <18E34C73-4507-412C-820D-F6C1E128D80A@sn3rd.com> Date: Thu, 6 Jul 2017 19:13:38 -0400 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] RTCweb@IETF99 Session Canceled X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 23:13:48 -0000 Please note that after discussions with our AD the chairs have canceled = the IETF 99 RTCweb session: = https://datatracker.ietf.org/meeting/99/agenda.html spt= From nobody Sat Jul 8 10:37:42 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A712ECB3 for ; Sat, 8 Jul 2017 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW934ZjuuMPC for ; Sat, 8 Jul 2017 10:37:35 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CE612EB97 for ; Sat, 8 Jul 2017 10:37:35 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m84so11243904ita.0 for ; Sat, 08 Jul 2017 10:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pdTmjWuJWVY/3JgSE570jt42Nl2JFLLm+OESfdGuT5E=; b=h7nOSukAmPDKwoXsSVI7JfhdpLp2pW0uZ/2/yGUJicp9Bv3XX0H/I4J3f+CdYCyahO vPxAaakEEj/DtfyjIKujpTv0m3bOIRaOUFOUzOt+TMt8Hj0dtV+QnzS7T+maM4uASsVI A423fMxG8ty6Czfp+XrqkyABo3zzUOc8Gx3MXfWJHr/rtmg6QufKmR6BWN3HyQnYeJQL bhaxJ3dlSTzW3kXi2oEJiJDhjrkAIIDWVlR8H7rCnJWdCdLF+a1yllwQKb6SJEUMluy2 uVN3IlzNo46jtPczuHtwN0+TiDtZfBf6qAplZpGovWlRq180PHY+PH1QilfCT5OfGOsj jNew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pdTmjWuJWVY/3JgSE570jt42Nl2JFLLm+OESfdGuT5E=; b=OIMhxd9FA2MGj8cHBJHcbCoLCwSlQNPJI/NFYi4IqPACsIuhxj1EcR/6L47ITQouum AczgxmuUMZkOou+MpaU1p5W882Hdq9hJWLR8OlrofZkQefVYFqr566nXZnUQ7VKuHvW0 Kt/Dj2+H19QNIOlmZz6Qc2XiWtPCmzOZN2+CL9V4Ttt2zbAmrPdxlS1DTtVU2Ps4M8sv S+c5LYumap7bV+xhzy+eGz7odike/qfPWXzDynldPrBGcf7ylUCjzneq2nYGIKhw6/sM z65U963LYZSI36q7s+B6EAlR2Dr46j4t29TkVFkI6uy/XLURqcZWWJ9qFyV9mGPhyOgX qw8Q== X-Gm-Message-State: AIVw111Gf9fUcCaDs4pckd5cGr4fzUIH64CQxD6FrSGz5rbXSrt7EcM+ 76ez8KWddjW+BzPv1qZL4TsfrctgLcc0 X-Received: by 10.36.5.136 with SMTP id 130mr4524700itl.68.1499535454355; Sat, 08 Jul 2017 10:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.149 with HTTP; Sat, 8 Jul 2017 10:37:13 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Sat, 8 Jul 2017 10:37:13 -0700 Message-ID: To: Bernard Aboba Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113d52741665630553d1ce47" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-ip-handling (part 1) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 17:37:39 -0000 --001a113d52741665630553d1ce47 Content-Type: text/plain; charset="UTF-8" Bernard, any more thoughts on these points? On Tue, Jul 4, 2017 at 7:53 PM, Justin Uberti wrote: > Thanks for the review. Most of these comments have been resolved in the > latest version of the document, https://tools.ietf. > org/html/draft-ietf-rtcweb-ip-handling-04. > > On Tue, May 9, 2017 at 3:43 PM, Bernard Aboba > wrote: > >> >> >> General points: >> >> a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.). >> > > Done. > >> >> >> >> Details >> >> 1 . Introduction >> >> >> As a technology that supports peer-to-peer connections, WebRTC may >> send data over different network paths than the path used for HTTP >> traffic. This may allow a web application to learn additional >> information about the user, which may be problematic in certain >> cases. This document summarizes the concerns, and makes >> recommendations on how best to handle the tradeoff between privacy >> and media performance. >> >> >> [BA] There are a number of distinct privacy issues that WebRTC >> >> needs to address. I believe this document is focussed on IP >> >> address info that can be gleaned by Web applications (the >> >> second sentence). That is somewhat distinct from what information >> >> a web server might glean, or what a passive observer might be >> >> able to obtain looking at traffic generated by a WebRTC client. >> >> The first sentence therefore is a bit confusing to me. >> >> >> A suggestion: >> >> >> "As a technology that attempts to optimize peer-to-peer >> >> connections by testing connectivity between available >> >> addresses, WebRTC may allow a web application to learn >> >> additional information about the user compared to an >> >> application which only utilizes HTTP. This may be >> >> problematic in certain cases." >> >> > Done. > >> >> 2 . Problem Statement >> >> >> WebRTC enables real-time peer-to-peer communications by enumerating >> network interfaces and discovering the best route through the ICE >> [RFC5245 ]protocol. During the ICE process, the peers involved in a >> session gather and exchange all the IP addresses they can discover, >> so that the connectivity of each IP pair can be checked, and the best >> path chosen. The addresses that are gathered usually consist of an >> endpoint's private physical/virtual addresses, and its public >> Internet addresses. >> >> >> [BA] The terms "route" and "path" used here do not refer to IP >> >> routing and so is a bit confusing. How about this? >> >> >> "In order to enable peer-to-peer communications, WebRTC >> >> peers utilize ICE [RFC5245] which gathers and exchanges >> >> all the IP addresses it can discover, so that the >> >> connectivity of each IP pair can be checked, and the best >> pair can be chosen. The addresses that are gathered >> >> usually consist of an endpoint's private physical/virtual >> >> addresses, and its public Internet addresses." >> >> > Done. >> >> > >> 2. If the client tries to hide its physical location through a VPN, >> and the VPN and local OS support routing over multiple interfaces >> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >> address for the VPN as well as the ISP public address that the >> VPN runs over. >> >> >> [BA] Even if the local OS doesn't support split-tunnel, >> >> isn't it still possible for an ICE implementation to >> >> discover other addresses? >> >> >> >> > Yes, but these addresses are typically RFC1918 addresses, and thereby > covered by the prior bullet. > > >> 3 . Goals >> >> Being peer-to-peer, WebRTC represents a privacy-enabling technology, >> and therefore we want to avoid solutions that disable WebRTC or make >> it harder to use. This means that WebRTC should be configured by >> default to only reveal the minimum amount of information needed to >> establish a performant WebRTC session, while providing options to >> reveal additional information upon user consent, or further limit >> this information if the user has specifically requested this. >> Specifically, WebRTC should: >> >> >> o Provide a privacy-friendly default behavior which strikes the >> right balance between privacy and media performance for most users >> and use cases. >> >> >> o For users who care more about one versus the other, provide a >> means to customize the experience. >> >> >> [BA] This section might state whether it is a >> >> goal to enable WebRTC to be used with >> >> The Onion Routing network (Tor). There >> >> are a number of reasons why enabling Javascript >> >> for use with Tor may represent a problem so that >> >> use of WebRTC might not be advisable: >> >> https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor >> >> > I checked, and it looks like the default Tor bundle does allow use of JS, > which makes it somewhat problematic to argue against here, given that one > could support Tor with Mode 4. > > Tracking this issue in https://github.com/juberti/draughts/issues/60. > >> 4 . Detailed Design >> >> >> 1. By default, WebRTC should follow normal IP routing rules, to the >> extent that this is easy to determine (i.e., not considering >> proxies). This can be accomplished by binding local sockets to >> the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which >> allows the OS to route WebRTC traffic the same way as it would >> HTTP traffic, and allows only the 'typical' public addresses to >> be discovered. >> >> >> [BA] This paragraph discusses routing behavior and >> address binding together and leads me to wonder whether >> some assumptions aren't being made (e.g. weak versus >> strong host model). My suggestion is to simplify the >> the paragraph and leave details to later on. For example: >> >> "1. By default WebRTC should only allow applications >> to discover the same address information made available >> by an HTTP application: the 'typical' public address >> >> " >> >> > Agree that the info about wildcard binding could be moved later to the > mode definitions, although I don't follow exactly what you mean by 'weak vs > strong host model'. > > Tracking in https://github.com/juberti/draughts/issues/61. > > --001a113d52741665630553d1ce47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bernard, any more thoughts on these points?

On Tue, Jul 4, 2017 at 7:5= 3 PM, Justin Uberti <juberti@google.com> wrote:
Thanks for the review. Most of thes= e comments have been resolved in the latest version of the document,=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04" tar= get=3D"_blank">https://tools.ietf.org/html/draft-ietf-rtcweb-ip-h= andling-04.

On Tue, May 9, 2017 at 3:43 PM, Bernard Aboba <b= ernard.aboba@gmail.com> wrote:


General poi= nts:

a. Please expand acronyms on first use (e.g. = HTTP, VPN, ICE, etc.).=C2=A0

=
Done.



= Details

1.  Introduction

As a technology that supports peer-to-peer connections, WebRTC may send data over different network paths than the path used for HTTP traffic. This may allow a web application to learn additional information about the user, which may be problematic in certain cases. This document summarizes the concerns, and makes recommendations on how best to handle the tradeoff between privacy and media performance.

[BA] There are a n=
umber of distinct privacy issues that WebRTC
needs to address.=
 I believe this document is focussed on IP
address info that c=
an be gleaned by Web applications (the
second sentence).  That=
 is somewhat distinct from what information
a web server might=
 glean, or what a passive observer might be
able to obtain loo=
king at traffic generated by a WebRTC client.
The first senten=
ce therefore is a bit confusing to me.

A sug=
gestion:

"As a technology that attempts=
 to optimize peer-to-peer
connections by testing connectivity =
between available
addresses, WebRTC may allow a web applicatio=
n to learn
additional information about the user compared to a=
n
application which only utilizes HTTP.  This may be
problematic in certain cases."
=
Done.

2.  Problem Statement
<=
/pre>

   WebRTC enables real-time peer-to-peer commun=
ications by enumerating
   network interfaces and discovering the best route through the ICE
   [RF=
C5245]protocol.  During the ICE process, the peers involved in a
   session gather and exchange all the IP addresses they can discover,
   so that the connectivity of each IP pair can be checked, and the best
   path chosen.  The addresses that are gathered usually consist of an
   endpoint's private physical/virtual addresses, and its public
   Internet addresses.

[BA] The terms "route" and "path" u=
sed here do not refer to IP
routing and so is a bit confusing.  How about this?=
 
<=
pre class=3D"m_6243076438318752653gmail-m_-7014505138885832957gmail-newpage=
" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px">   "I=
n order to enable peer-to-peer communications, WebRTC
   peers utilize ICE [RFC=
5245] which gathers and exchanges
   all the IP addresses it can discover, so t=
hat the 
   connectivity of each IP pair can be checked, and the best
   pair can be chosen.  The addresses that are gathered
   usually consist of a=
n endpoint's private physical/virtual
   addresses, and its public Internet=
 addresses."

=
<= div>
Done.
On Wed, Jul 5, 2017 at 11:22 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I have not seen a conclusion to the w= hat-ICE-spec-to-reference discussion.

=C2=A0

<= /blockquote>

After discussion with our area director, th= e chairs believe that we should go forward as it is currently specified and= revisit with the RFC Editor when cluster 238 is ready for publication.=C2= =A0 I will update the shepherd write-up to note this.

reg= ards,

Ted
=C2=A0

Regards,

=C2=A0

Christer

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 05 July 2017 22:18
To: rtcweb@ietf= .org; Sean Turner <sean@sn3rd.com>; Cullen Jennings <fluffy@cisco.com>; Adam Roach <adam@nostrum.com>
Subject: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21<= u>

=C2=A0

Howdy,<= /p>

We have a new version= of JSEP which incorporates changes in response to Adam's AD review.=C2= =A0 Please review those changes between now and July 21, 2017 (the end of I= ETF 99), in preparation for the IETF last call.=C2=A0 A strong focus on those changes, rather than re-opening old discussions, i= s appreciated.

regards,

Ted, Cullen, Sean


=C2=A0= 
   2.  If the client tries to hide its physical location=
 through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

[BA] Even if the local OS doesn't support split-tunn=
el,
=
isn't it still possible for an ICE implementation to
discover other address=
es?

Yes, but these= addresses are typically RFC1918 addresses, and thereby covered by the prio= r bullet.
=C2=A0
=

3.  Goals


   Being peer-to-peer, WebRTC represents a privacy-enabling technology,
   and therefore we want to avoid solutions that disable WebRTC or make
   it harder to use.  This means that WebRTC should be configured by
   default to only reveal the minimum amount of information needed to
   establish a performant WebRTC session, while providing options to
   reveal additional information upon user consent, or further limit
   this information if the user has specifically requested this.
   Specifically, WebRTC should:

   o  Provide a privacy-friendly default behavior which=
 strikes the
      right balance between privacy and media performance for most users
      and use cases.


   =
o  For users who care more about one versus the other, provide a
      means to customize the experience.

[BA] This section might state whether=
 it is a 
goal to enable WebRTC to be used with 
The Onion Routing network (Tor). T=
here
are a number of reasons why enabling Javascript
for  use with Tor may represen=
t a problem so that
use of WebRTC might not be advisable:
https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor
<= /div>

I checked, and it looks like t= he default Tor bundle does allow use of JS, which makes it somewhat problem= atic to argue against here, given that one could support Tor with Mode 4.= =C2=A0

 
=

4.  Detailed Design
<=
pre class=3D"m_6243076438318752653gmail-m_-7014505138885832957gmail-newpage=
" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px">
=

   1.  By default=
, WebRTC should follow normal IP routing rules, to the
       extent that this is easy to determine (i.e., not considering
       proxies).  This can be accomplished by binding local sockets to
       the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
       allows the OS to route WebRTC traffic the same way as it would
       HTTP traffic, and allows only the 'typical' public addresses=
 to
       be discovered.


[BA] This paragraph discusses routing behavior an=
d
address binding together and leads me to wonder whether
some assumptions aren't being made (e.g. weak versus
stron= g host model). My suggestion is to simplify the
the paragraph an= d leave details to later on. For example:

"1.= By default WebRTC should only allow applications
to discover the= same address information made available
by an HTTP application: = the 'typical' public address=C2=A0
"

Agree that t= he info about wildcard binding could be moved later to the mode definitions= , although I don't follow exactly what you mean by 'weak vs strong = host model'.

Tracking in=C2=A0https://github.com/juberti/draughts= /issues/61.


--001a113d52741665630553d1ce47-- From nobody Sun Jul 16 02:40:33 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7101317BE for ; Sun, 16 Jul 2017 02:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFkgx4e8qDOx for ; Sun, 16 Jul 2017 02:40:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7781C127058 for ; Sun, 16 Jul 2017 02:40:30 -0700 (PDT) X-AuditID: c1b4fb30-703ff70000001664-3b-596b348c398f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.10.05732.C843B695; Sun, 16 Jul 2017 11:40:28 +0200 (CEST) Received: from [100.94.39.15] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 16 Jul 2017 11:40:28 +0200 To: , Justin Uberti From: Magnus Westerlund Message-ID: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com> Date: Sun, 16 Jul 2017 11:40:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050507010409030901090705" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7tG6PSXakwcs1+hZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyPnybx1Sw2KLi9apHjA2MM027GDk5JARMJG7O ecvYxcjFISRwhFHi//+prBDORkaJTT8fM4FUiQhYSvy/sowZxGYTsJC4+aORDcQWFtCWuNX4 ngXE5hWwl+jdMxnMZhFQlZjw6ReYLSoQI3Ft5h1WiBpBiZMzn7CALGAW6GaU+Dj3G9ggIaBB DU0drBAnKUlcn3edZQIj7ywkPbOQ9YAkmAVsJe7M3c0MYWtLLFv4GsoWkTh5+T6UbS0x49dB qHpFiSndD9khbFOJ10c/MkLYRhLv9jSyL2DkXMUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokR GOAHt/w22MH48rnjIUYBDkYlHl4f3exIIdbEsuLK3EOMKkBzHm1YfYFRiiUvPy9VSYT3kj5Q mjclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsbJ8SXmDwv6 L/pmVsz8teuKWvlF1hO1Ife1e43ZK42y/hbvm9W0r6PWbjpr3M62Buer3WuyExUuuf3dsned xI5DcutCGcWY+uKkNUU+Xl5Z723HJO64lUv8/5TY65/8bwip3/UP5Njo8ZrHfNGl8DNTHds5 LKrOnHtgb1X+tTFmRYuo6UWuJ0osxRmJhlrMRcWJAGhnvM94AgAA Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-fec-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Jul 2017 09:40:32 -0000 --------------ms050507010409030901090705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: sv Hi, I was reviewing -06 to ensure that all issues are resolved. I did notice = the following issues. 1. Section 4.2, makes a normative refernces to TS.26114, which is listed = as informative refences in the reference list. Please move it to the=20 normative part. 2. Section 8. I am missing the statement that primary encoding + FEC=20 needs to keep within the available bandwidth as determined by the=20 congestion control or other bitrate adaptation mechnisms. Thus, likely=20 resulting in that the primary encoding bitrate needs to be reduced to=20 fit the FEC. Otherwise the document looks good. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms050507010409030901090705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA3MTYwOTQwMjdaMC8GCSqGSIb3DQEJBDEiBCBsaX+daMu8iCxZe5N3 l1bF72sDA5CVbn2WverpX0FNszBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAEv798B9kYDIg6k2giBugmL+PN5mA43tBICtC3Matnm5pR52P wVQdi/pKS5PfmJmeuMbh4RqGc18tcAgV9AN9+/eojMFxNOo6NLOX708E4lZBVfcQSwnCd+53 P4qPWh8BTJYy6aqxh8KNQifN9/DaQBnvhDmNv8nm6j6exzgH23NKhvXiw9PxTkD6A5w8Qp/z R2WmueqoNRna1C/1WKaDuWzgwNEoAToL0vDFJRsDokTvcExOSLF2Q5a4m1+Ajz74PvT2dVly WilJVnAE+bNhKHbystBDX2BVHZel4E6XZWytmP5M+2KyuXiari0UXNdtrrtcJU8lb6Ws/8Rx dELRUwAAAAAAAA== --------------ms050507010409030901090705-- From nobody Sun Jul 16 03:44:55 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9698712EC19 for ; Sun, 16 Jul 2017 03:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPMbEoEz0UkV for ; Sun, 16 Jul 2017 03:44:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0439F126B6E for ; Sun, 16 Jul 2017 03:44:51 -0700 (PDT) X-AuditID: c1b4fb2d-803ff70000005faa-63-596b43a150d4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.B2.24490.1A34B695; Sun, 16 Jul 2017 12:44:50 +0200 (CEST) Received: from [100.94.39.15] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 16 Jul 2017 12:44:44 +0200 To: Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , Adam Roach References: From: Magnus Westerlund Message-ID: Date: Sun, 16 Jul 2017 12:44:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050305030600070305030504" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2K7tO4i5+xIg0W1Fnv+LmK36JjMZrH2 Xzu7xZVVjcwWjXPtHFg9pvzeyOqxc9Zddo8lS34yecza+YTF4+BBxgDWKC6blNSczLLUIn27 BK6ML4+WsBc8CKs42HaVqYHxgU8XIyeHhICJxN5515i7GLk4hASOMEpMnvKMCSQhJLCRUWLW N6EuRg4OYQF3ibf9bCA1IgJrGSWm7J7ODFETILHu32JWEJtNwELi5o9GNhCbV8BeYknfHHYQ m0VAVaLtegtYXFQgRuLazDusEDWCEidnPmEBmc8pEChx578hyHxmgW5GiVVLd7JAzNeWaGjq YIU4VEni+rzrLBMY+WchaZ+FrAckwSwQJnFu/WxmCFtE4uTl+1C2mcS8zQ+hbG2JZQtfA9kc QLaaxLJWJVRhENtaYsavg2wQtqLElO6H7BC2qcTrox8ZIWwjiXd7GtkXMPKsYhQtTi0uzk03 MtZLLcpMLi7Oz9PLSy3ZxAiMxYNbfuvuYFz92vEQowAHoxIP72yd7Egh1sSy4srcQ4wqQHMe bVh9gVGKJS8/L1VJhNfeEijNm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQghgfTEktTs1NSC 1CKYLBMHp1QDo0DnoZLeGsfMtg1/nDZxp7+1vpY+M9ziPKtp/JHvFbFV1552K+x5/LVPdf9M p61ursITrad7ucyP0ZxVeuHBhTWLTTnqpKaIVIrs4Dv9NI5t8Wz26gnGThJmQRmrq8PntS0y jAlr6FjhzuHe3tp0UMVqq09QasXbG4789ftPvzgltGWhYGymEktxRqKhFnNRcSIAtwgh9M0C AAA= Archived-At: Subject: Re: [rtcweb] Working group last call draft-ietf-rtcweb-jsep-21 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Jul 2017 10:44:53 -0000 --------------ms050305030600070305030504 Content-Type: multipart/alternative; boundary="------------037FC06117D404ADCA1BEC8D" Content-Language: sv This is a multi-part message in MIME format. --------------037FC06117D404ADCA1BEC8D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable WG, I have reviewed the many changes in JSEP and have the following comments.= 1. Section 3.6.2: Already during the authors drafting of the text, I=20 raised a question on the PR which reuslted in there being a "discussion" = Issue in the JSEP tracker: https://github.com/rtcweb-wg/jsep/issues/745 I request that this issue is resolved before we move to IETF last call. 2. Section 7.1, 7.2, and 7.3: As these examples contain RTX, shouldn't the RTP headerextension for=20 RepairedRtpStreamId also be included? Cheers Magnus Den 2017-07-05 kl. 22:17, skrev Ted Hardie: > Howdy, > > We have a new version of JSEP which incorporates changes in response=20 > to Adam's AD review. Please review those changes between now and July = > 21, 2017 (the end of IETF 99), in preparation for the IETF last call. = > A strong focus on those changes, rather than re-opening old=20 > discussions, is appreciated. > > regards, > > Ted, Cullen, Sean > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------037FC06117D404ADCA1BEC8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

WG,


I have reviewed the many changes in JSEP and have the following comments.


1. Section 3.6.2: Already during the authors drafting of the text, I raised a question on the PR which reuslted in there being a "discussion" Issue in the JSEP tracker: https://github.com/rtcweb-wg/jsep/issues/745

I request that this issue is resolved before we move to IETF last call.

2. Section 7.1, 7.2, and 7.3:

As these examples contain RTX, shouldn't the RTP headerextension for RepairedRtpStreamId also be included?

Cheers

Magnus


Den 2017-07-05 kl. 22:17, skrev Ted Hardie:
Howdy,

We have a new version of JSEP which incorporates changes in response to Adam's AD review.=C2=A0 Please review those chang= es between now and July 21, 2017 (the end of IETF 99), in preparation for the IETF last call.=C2=A0 A strong focus on t= hose changes, rather than re-opening old discussions, is appreciated.

regards,

Ted, Cullen, Sean


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


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------037FC06117D404ADCA1BEC8D--

--------------ms050305030600070305030504
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA3MTYxMDQ0MTVaMC8GCSqGSIb3DQEJBDEiBCCAa3P6M1ZTCiOztPci
HQXnjGs/hDLuqM9apw39LT+ISDBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAVprzk04RyyrYd5VTY8YRP64YabVjqsYaLiLrK8KOTiuN9u+h
PvI3zGGCcDU3TKbx/Z0z51hlRyjeskzcFlI0n43ywez2aQOsCYTzmv4YGqwe+5ytXR50gCIt
WIhlnUoc0/8mLewvxjzI/H14AMlUoHFG+u66Q3vH+8Xbz4gpFsJtDz1KsqofZOVRaBv26KQa
DmSBaA4zE+6QC5Kn946XQk5TTt3MH9S0BhrVRbWvJOcvswjao8GTRDpQiY9FtEtww9sj0K//
R7UobSN03cGmo1eWna91m/kftox+I48RBJur0hkSeCKRX1rHD/njOeq9rRiqMANXpNcFzJ4+
Bs4VvwAAAAAAAA==
--------------ms050305030600070305030504--


From nobody Wed Jul 19 23:26:16 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F7E124217 for ; Wed, 19 Jul 2017 23:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS-wr0ZvfjAf for ; Wed, 19 Jul 2017 23:26:12 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C046F127201 for ; Wed, 19 Jul 2017 23:26:12 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id g13so8133078ioj.5 for ; Wed, 19 Jul 2017 23:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kemROEn36HeJ7qTNcCjvZ7qvbERGVlQ7PV3T/Dr49rw=; b=ibrrVbdIdKjGBTjcCEkkIREQOuLvG7mMEd2BOCOozBvTWEr8PJAdgV78MJN0RH7RdL ZF5fNtTw88mb+gJufPCT31iJORnoHlEseJGbRqVAzyv+ezHsSMiYCyth7i8tzN4V4atR L2w43vdpwvPos0W75s2/s71Iu6Rg/iyx4fFk8aYb/CmMSkHNDgAM27hTM7unua3A5yH2 ZBKAhKT4H8qEcf4/PRU9OHo6NqwsOBSEo4ZVNzose112o3tL4hOO28gQ1zUcDyiUdQ9O lM0Tpql6oghPbCR68VjW1ssHz7zfP5CGSDPBOg7PIhz63LBQiOt0DSPpTCotQQT7k9Hx 7MpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kemROEn36HeJ7qTNcCjvZ7qvbERGVlQ7PV3T/Dr49rw=; b=hyc5exzv2Pla4dIKHnsB/qtAgbwPZ57AUfT/116R1vDM9G5IDCbaOqiahfWJ5W3HXQ HgjW31znpeRSPZxwxF61BMXDJvGUylYS/x9ryfQ+d0J+XTiU7Spl0RzZb2i0Ws20QFpB +HA8R/pTfNVi/v14jQv95Of/XS2aGwzaqjBPAZNbnDrEsb2N3798vIItfrGRZbVWiKsm HFMv8yBGgPvdQkK5fhCTK5Pf3vysNxXZ7zgCOj94XOOLMSukDAZ+FWXUdYnNpIZsF85n TNeTQ2pOFz5LESAiORl5eJVvXucVTthxan84VJp8sWN60XF5QZuiNQW6fCeyy1lsYahg QTow==
X-Gm-Message-State: AIVw113hSvzlQ28iZojM0kaNb+YQxW9IakF5lxRwv5OYx+gbANnwfMmb Do4vmGxxecC6KRG/rVQBfl/0R2QsWQd4
X-Received: by 10.107.59.84 with SMTP id i81mr2505184ioa.72.1500531971850; Wed, 19 Jul 2017 23:26:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.149 with HTTP; Wed, 19 Jul 2017 23:25:51 -0700 (PDT)
In-Reply-To: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com>
References: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com>
From: Justin Uberti 
Date: Wed, 19 Jul 2017 23:25:51 -0700
Message-ID: 
To: Magnus Westerlund 
Cc: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c06537e28fa680554b9d369"
Archived-At: 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Jul 2017 06:26:14 -0000

--94eb2c06537e28fa680554b9d369
Content-Type: text/plain; charset="UTF-8"

Thanks for your comments. Regarding #2, the document currently says the
following:

   Since use of FEC always causes redundant data to be transmitted, this
   will lead to less bandwidth available for the primary encoding when
   in a bandwidth-constrained environment.


Do you think this is insufficient?


On Sun, Jul 16, 2017 at 2:40 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi,
>
> I was reviewing -06 to ensure that all issues are resolved. I did notice
> the following issues.
>
>
> 1. Section 4.2, makes a normative refernces to TS.26114, which is listed
> as informative refences in the reference list. Please move it to the
> normative part.
>
> 2. Section 8. I am missing the statement that primary encoding + FEC needs
> to keep within the available bandwidth as determined by the congestion
> control or other bitrate adaptation mechnisms. Thus, likely resulting in
> that the primary encoding bitrate needs to be reduced to fit the FEC.
>
> Otherwise the document looks good.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>

--94eb2c06537e28fa680554b9d369
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for your comments. Regarding #2, the document curre=
ntly says the following:

   Since use of FEC always causes redundant data to be transmitted, this
   will lead to less bandwidth available for the primary encoding when
   in a bandwidth-constrained environment.

Do you think this is insufficient? 
<=
/div>

On Sun, Jul =
16, 2017 at 2:40 AM, Magnus Westerlund <magnus.westerlund@eri=
csson.com> wrote:
Hi,



I was reviewing -06 to ensure that all issues are resolved. I did notice th=
e following issues.





1. Section 4.2, makes a normative refernces to TS.26114, which is listed as=
 informative refences in the reference list. Please move it to the normativ=
e part.



2. Section 8. I am missing the statement that primary encoding + FEC needs =
to keep within the available bandwidth as determined by the congestion cont=
rol or other bitrate adaptation mechnisms. Thus, likely resulting in that t=
he primary encoding bitrate needs to be reduced to fit the FEC.



Otherwise the document looks good.



Cheers



Magnus Westerlund



-----------------------------------------------------------------=
-----

Media Technologies, Ericsson Research

-----------------------------------------------------------------=
-----

Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =
Phone=C2=A0 +46 10 7148287

Torshamnsgatan 23=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

-----------------------------------------------------------------=
-----









--94eb2c06537e28fa680554b9d369--


From nobody Wed Jul 19 23:27:46 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F4124217 for ; Wed, 19 Jul 2017 23:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgHsN3LbXaMa for ; Wed, 19 Jul 2017 23:27:37 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9064712783A for ; Wed, 19 Jul 2017 23:27:37 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id g13so8142006ioj.5 for ; Wed, 19 Jul 2017 23:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lAiYEBk/+Q/zPjZhDSkDpz3o7j4vGdUVIc17cZC0UkY=; b=kkErpB/1i8XvOjds6AZggKVNhR0/Sj5Z8XE1ZA0FSsHVwZjmg4sMjh+q8947SS6N43 fKIkQ4OG7mMy+1zhlewsEojMCrt7h+1zyCHQZLZlEub64ke27ddEu676mvcGROWBaqnq oX058xQDQEuLPuDCqy7d5RHE+HqoB9AABM9LfhNN0V+fd5UFDJuJlJcI2Z60KLNUTcyq awoOvF081g/NlAOEg5vxbLoVtrf2GC8AWDbMhUPqwH20ZsDj2gdaHcASjwhtlgjsbYXO mfOxoZloN/CHhKcEhtnuaAuzSQvkEODxgYBzL1yMJ4bnfDn8e42x2Sz2J3X82U82wa8d AAbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lAiYEBk/+Q/zPjZhDSkDpz3o7j4vGdUVIc17cZC0UkY=; b=cLPbz5A76E6GM4q0Zkk1oZ8J+wcBi0/aXk8sKj9PJ0IfUx9Lo8hPeQCNqeJ7NXqXgG cYlMLqlWH/qhB5eo5QRe5MJvGtyoA6hXT9lMEgb8rn2tkpPaaosid+fsJJ0YSolyqE+n JAAOzXn5WtPUuWTFBmP4K02D7URld2niGBXAe8AVCH7SeGC4j7ivqpQ0yvadfoPR1Qr/ B5lQfj+DecnyVqYdulEVffHQDSeaPRpz3ybQjFZpUEN/5qs0t511HZVgvhitVc57JCJp sTzDWj5PMlE8BFwYPLsRVKHr8KIIvhN93jEP05keDx/Bom6HSizt/d+tcArrE4ICfQN+ M/2g==
X-Gm-Message-State: AIVw111CKU6Pio25qS2INZZOYZi19TZ70gcjEQdR/DNi/E4TN41KhLiu 0gdBqg4/TlM+tHoK787M5T0FMjAy18YXCKKG0Q==
X-Received: by 10.107.133.155 with SMTP id p27mr2695773ioi.200.1500532056184;  Wed, 19 Jul 2017 23:27:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.149 with HTTP; Wed, 19 Jul 2017 23:27:15 -0700 (PDT)
From: Justin Uberti 
Date: Wed, 19 Jul 2017 23:27:15 -0700
Message-ID: 
To: "rtcweb@ietf.org" , Bernard Aboba 
Content-Type: multipart/alternative; boundary="001a113ea6da2f93630554b9d81f"
Archived-At: 
Subject: [rtcweb] Open issues for draft-ietf-rtcweb-fec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Jul 2017 06:27:40 -0000

--001a113ea6da2f93630554b9d81f
Content-Type: text/plain; charset="UTF-8"

Since there will be no WG meeting this week, here is the sole remaining
open issue for the document. Feedback on this issue is the only thing
standing between this document and WGLC.

1. https://github.com/juberti/draughts/issues/81

Currently, the document indicates that Opus' built-in FEC mechanism MUST be
implemented and SHOULD be used when needed.

However, Bernard mentioned that his experience with Opus did not show a
benefit:


[BA] While loss of a single packet is by far the most likely loss

mode, our tests do not indicate that there is much benefit from

Opus internal FEC.  For example, when we compared Opus internal

FEC against no FEC and concealment, we found little discernible

difference in MOS score. On the other hand, we did see a benefit

arising from RFC 2198 redundancy to protect against burst loss.

So based on our test results, we cannot recommend use of built-in

Opus FEC.


Does anyone else have an opinion on this matter?

Bernard, are there any specifics you can share?

--001a113ea6da2f93630554b9d81f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Since there will be no WG meeting this week, here is the s=
ole remaining open issue for the document. Feedback on this issue is the on=
ly thing standing between this document and WGLC.


Currently, the=
 document indicates that Opus' built-in FEC mechanism MUST be implement=
ed and SHOULD be used when needed.

However, Bernar=
d mentioned that his experience with Opus did not show a benefit:

[BA] While loss of a single packet is by far the most likely loss
mode, our tests do not indicate that there is much benefit from
<= pre class=3D"gmail-m_-8262871877585882714gmail-newpage" style=3D"white-spac= e:pre-wrap;font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0= ,0,0)">Opus internal FEC. For example, when we compared Opus internal
FEC against no FEC and concealment, we found little discernible
difference in MOS score. On the other hand, we did see a benefit=

arising from RFC 2198 redundancy to protect against burst los=
s.
So based on our test results, we cannot recommend use of bu=
ilt-in
Opus FEC. 

Does a=
nyone else have an opinion on this matter?

Bernard=
, are there any specifics you can share?



--001a113ea6da2f93630554b9d81f--


From nobody Wed Jul 19 23:45:28 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDE127866 for ; Wed, 19 Jul 2017 23:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y24ZJvZiERSa for ; Wed, 19 Jul 2017 23:45:25 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F014124217 for ; Wed, 19 Jul 2017 23:45:25 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id c74so8296856iod.4 for ; Wed, 19 Jul 2017 23:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6vkCTexCCVJlWUZpjzyicEueFYYCazgf/u7FsOp1RGw=; b=MlWOBOV7vermCAcObx1v0ZOx0cO6tbDxRSbv8I88KOUS9sZNCmhflYtE2WX/Z7MPba HGUaj8s+TZJShbYDb80zcD3tZHvWGZJkvr4EqjDSc/4h6J2KZNCb/fpFRPSZvYzS1FOq HvkXnhphP5Jkd+5ktMcche7PE5WdearZIQjLTsNoqm+Z7ew827pfu8e1OhZR2J7aY+MB kzN17MoAlRfRpb/nDzCK+b31rybB1XeLBPolJsbLdVPaOxrG0Atyq9jRupIIKZUlqZK5 HXqhgmSKpcWeGVs6U4Hte89fKphHV5lzuycAxFr1R0Y0/fSsRrxqltpqlA9DDFjmT9IN sbiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6vkCTexCCVJlWUZpjzyicEueFYYCazgf/u7FsOp1RGw=; b=sNFlA0lLS9N1rVPVG94mFtDaYVlNzjXyQd6895OAXILJM72eD96docoLre7IYTpWna q+SJwQ/UGNYICtBSjQHiBcsDVqD1AtBYh0NS+LUFqfODVOLtNNVH4h41aCwhxJeEZJnn 1Dugu4/0moQQB364RnCKjSejUgOaAi8yiukWtFIVQQR8IUdkKusCUqaPd4rGYTWg6vrL HxBo49nXZDK2DVXp46B+ChIfYd0nztmj9CPVu+mY5G3G+x2osi3WLyfeTGE28OljLKuz uGwpj+QuJoScVp4KECpOwMS3DYsiv4SRb+Kq2U/L84yU/el4mpwlavSLK60OvRhKSyoX 9zIg==
X-Gm-Message-State: AIVw110PZmd+huAzfuziUp6KVBR+YxDKEIFwcHpyHSnkwKmnk7F3jYAk 5vT0dr1DXuSv552jbWIC/36MxiPMYuDy8h5Vag==
X-Received: by 10.107.133.155 with SMTP id p27mr2731794ioi.200.1500533124088;  Wed, 19 Jul 2017 23:45:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.149 with HTTP; Wed, 19 Jul 2017 23:45:03 -0700 (PDT)
From: Justin Uberti 
Date: Wed, 19 Jul 2017 23:45:03 -0700
Message-ID: 
To: "rtcweb@ietf.org" , Bernard Aboba 
Content-Type: multipart/alternative; boundary="001a113ea6dad671f30554ba170c"
Archived-At: 
Subject: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Jul 2017 06:45:27 -0000

--001a113ea6dad671f30554ba170c
Content-Type: text/plain; charset="UTF-8"

Since there will be no WG meeting this week, here are the open issues for
the document. Feedback on these issues is the only thing standing between
this document and WGLC.

1. https://github.com/juberti/draughts/issues/59

*In the problem statement, should the paragraph on VPNs mention IP address
discovery? *

Currently, the problem statement says the following:

   1.  If the client is behind a Network Address Translator (NAT), the

       client's private IP addresses, typically [RFC1918] addresses, can

       be learned.

   2.  If the client tries to hide its physical location through a

       Virtual Private Network (VPN), and the VPN and local OS support

       routing over multiple interfaces (i.e., a "split-tunnel" VPN),

       WebRTC will discover the public address for the VPN as well as

       the ISP public address that the VPN runs over.

However, Bernard mentioned that even without split-tunnel support, the ICE
implementation allows discovery of the VPN private address. I think this is
covered by the first paragraph, but perhaps this should be spelled out
further. Thoughts?

2. https://github.com/juberti/draughts/issues/60.

*Should supporting WebRTC over Tor be an explicit goal of this document
(and mentioned in the goals section)?*

This scenario is possible via Mode 4, e.g. force-proxy mode, but it may be
out of scope for this document. Bernard mentioned that it may be out of
scope as Tor distros can disable Javascript, making WebRTC useless, but
upon investigation I found that the default Tor bundle does enable
Javascript, and so this is worth considering. Thoughts?

3. https://github.com/juberti/draughts/issues/61

*Should the document discuss implementation details as it relates to
suggested default behavior? *

The document currently says the following:

    1.  By default, WebRTC should follow normal IP routing rules, to the

       extent that this is easy to determine (i.e., not considering

       proxies).  This can be accomplished by binding local sockets to

       the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which

       allows the OS to route WebRTC traffic the same way as it would

       HTTP traffic, and allows only the 'typical' public addresses to

       be discovered.

However, Bernard thinks that this text may be making some assumptions,
specifically about whether a strong or weak host model is used. My thinking
was that spelling out the general implementation approach helps readers
grok exactly what this section is getting at, but open to other opinions
here.

--001a113ea6dad671f30554ba170c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Since there will be no WG meeting this week, here are the =
open issues for the document. Feedback on these issues is the only thing st=
anding between this document and WGLC.


In the problem statement, sh=
ould the paragraph on VPNs mention IP address discovery?=C2=A0

Currently, the problem statement says the following:
=

=C2=A0 =C2=
=A01.=C2=A0 If the client is behind a Network Address Translator (NAT), the=

=C2=A0=
 =C2=A0 =C2=A0 =C2=A0client's private IP addresses, typically [RFC1918]=
 addresses, can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be learned.
=C2=A0 =C2=A02.=C2=A0 If the clien=
t tries to hide its physical location through a
=C2=A0 =C2=A0 =C2=A0 =C2=A0Virtual=
 Private Network (VPN), and the VPN and local OS support
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0routing over multiple interfaces (i.e., a "split-tunnel" VPN),=

=C2=A0=
 =C2=A0 =C2=A0 =C2=A0WebRTC will discover the public address for the VPN as=
 well as
However, Bernard ment=
ioned that even without split-tunnel support, the ICE implementation allows=
 discovery of the VPN private address. I think this is covered by the first=
 paragraph, but perhaps this should be spelled out further. Thoughts?


2.=C2=A0https=
://github.com/juberti/draughts/issues/60.
Should supporting WebRTC over Tor be an explicit goal of this documen=
t (and mentioned in the goals section)?=C2=A0
=
This scenario is possible via Mode 4, e.g. force-proxy mode, but it may be =
out of scope for this document. Bernard mentioned that it may be out of sco=
pe as Tor distros can disable Javascript, making WebRTC useless, but upon i=
nvestigation I found that the default Tor bundle does enable Javascript, an=
d so this is worth considering. Thoughts?


3.=C2=A0htt=
ps://github.com/juberti/draughts/issues/61
Should the document discuss implementation details as it relates to =
suggested default behavior?=C2=A0
The document=
 currently says the following:


=C2=A0=C2=A0 =C2=A01.=C2=A0 By default, WebRTC should fo=
llow normal IP routing rules, to the


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 extent that this is easy to determine (i.e., not considering


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 proxies).=C2=A0 This can be accomplished by binding local sockets to


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 allows the OS to route WebRTC traffic the same way as it would


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 HTTP traffic, and allows only the 'typical' public addre=
sses to


=C2=A0=C2=A0 =C2=A0 =C2=
=A0 be discovered.
However, B=
ernard thinks that this text may be making some assumptions, specifically a=
bout whether a strong or weak host model is used. My thinking was that spel=
ling out the general implementation approach helps readers grok exactly wha=
t this section is getting at, but open to other opinions here.




--001a113ea6dad671f30554ba170c--


From nobody Fri Jul 21 00:51:39 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94912783A for ; Fri, 21 Jul 2017 00:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGSa-j3883yn for ; Fri, 21 Jul 2017 00:51:26 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E520E12714F for ; Fri, 21 Jul 2017 00:51:25 -0700 (PDT)
X-AuditID: c1b4fb2d-857ff70000005f66-99-5971b27c2817
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.1A.24422.C72B1795; Fri, 21 Jul 2017 09:51:24 +0200 (CEST)
Received: from [100.94.44.161] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 21 Jul 2017 09:51:23 +0200
To: Justin Uberti 
CC: "rtcweb@ietf.org" 
References: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com> 
From: Magnus Westerlund 
Message-ID: <554c4448-4731-a92c-67b4-dbf86a681319@ericsson.com>
Date: Fri, 21 Jul 2017 09:51:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020909020503010308080805"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7k27NpsJIg1mv+C22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlTNz1la3gY07F408TGBsYX8Z0MXJySAiYSOxp f8vWxcjFISRwhFFic/8iJghnE6PEjF+vWUCqhAX0JW7+amcHsUUE1CQeztrFCmIzC6hL3Fl8 jh2ioY1Rouf2XbAiNgELiZs/GtlAbF4Be4mbHycBTeXgYBFQlTi7WBwkLCoQI3Ft5h1WiBJB iZMzn4Dt4hQIlDjTN5sRZCazQDejxLIbWxlBEkIC2hINTR2sEGcrSVyfd51lAqPALCT9s5D1 zAI7MEzi3OKprBC2uETTl5VQtpnEvM0PmSFsbYllC18D2RxAtprEslYlVGEQ2xoYFgfZIGxF iSndD9khbFOJ10c/Qq0ykni3p5F9ASPPKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAeDu4 5bfuDsbVrx0PMQpwMCrx8AbNLowUYk0sK67MPcSoAjTn0YbVFxilWPLy81KVRHh3rQBK86Yk VlalFuXHF5XmpBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwFi/+1rd1/fbDOO4 jwv+eP6dgfHSRs5f8iaspz+citlwekOlwc6tDEe3rbRXT39ZOr85/9u3xbzGMVWxd7fbzWSU /brKqab9I++fvXE3Oc6uMptRz/U4TZg1cEZKw/vIC8l5ql8YVyq9qd4mpqIqpCbmVPD6VJ+2 uM7Z1ccfmeVF3FQ8NP1RyW8lluKMREMt5qLiRABl2QgUvwIAAA==
Archived-At: 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Jul 2017 07:51:29 -0000

--------------ms020909020503010308080805
Content-Type: multipart/alternative;
 boundary="------------4864348CBBC94C00050B8495"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------4864348CBBC94C00050B8495
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable



Den 2017-07-20 kl. 08:25, skrev Justin Uberti:
> Thanks for your comments. Regarding #2, the document currently says=20
> the following:
>
>     Since use of FEC always causes redundant data to be transmitted, th=
is
>     will lead to less bandwidth available for the primary encoding when=

>     in a bandwidth-constrained environment.
> Do you think this is insufficient?

Yes, I think it should be more explicit that primary + repair need to be =

within the bandwidth limits set by congestion control, etc.

/Magnus

>
> On Sun, Jul 16, 2017 at 2:40 AM, Magnus Westerlund=20
>  > wrote:
>
>     Hi,
>
>     I was reviewing -06 to ensure that all issues are resolved. I did
>     notice the following issues.
>
>
>     1. Section 4.2, makes a normative refernces to TS.26114, which is
>     listed as informative refences in the reference list. Please move
>     it to the normative part.
>
>     2. Section 8. I am missing the statement that primary encoding +
>     FEC needs to keep within the available bandwidth as determined by
>     the congestion control or other bitrate adaptation mechnisms.
>     Thus, likely resulting in that the primary encoding bitrate needs
>     to be reduced to fit the FEC.
>
>     Otherwise the document looks good.
>
>     Cheers
>
>     Magnus Westerlund
>
>     -------------------------------------------------------------------=
---
>     Media Technologies, Ericsson Research
>     -------------------------------------------------------------------=
---
>     Ericsson AB                 | Phone +46 10 7148287
>     
>     Torshamnsgatan 23           | Mobile +46 73 0949079
>     
>     SE-164 80 Stockholm, Sweden | mailto:
>     magnus.westerlund@ericsson.com 
>     -------------------------------------------------------------------=
---
>
>
>

--=20

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------4864348CBBC94C00050B8495
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
Den 2017-07-20 kl. 08:25, skrev Justin=

      Uberti:

    

    

      
      
Thanks for your comments. Regarding #2, the
        document currently says the following:
        


        

        

          
   Since use of FEC always =
causes redundant data to be transmitted, this
   will lead to less bandwidth available for the primary encoding when
   in a bandwidth-constrained environment.

          

          
Do you think this is insufficient? 

        

      

    

    

    Yes, I think it should be more explicit that primary + repair need
    to be within the bandwidth limits set by congestion control, etc. 
    

    /Magnus

    

    

      


        
On Sun, Jul 16, 2017 at 2:40 AM, Magnu=
s
          Westerlund <magnus.westerlun=
d@ericsson.com>
          wrote:

          
Hi,

            

            I was reviewing -06 to ensure that all issues are resolved.
            I did notice the following issues.

            

            

            1. Section 4.2, makes a normative refernces to TS.26114,
            which is listed as informative refences in the reference
            list. Please move it to the normative part.

            

            2. Section 8. I am missing the statement that primary
            encoding + FEC needs to keep within the available bandwidth
            as determined by the congestion control or other bitrate
            adaptation mechnisms. Thus, likely resulting in that the
            primary encoding bitrate needs to be reduced to fit the FEC.<=
br>
            

            Otherwise the document looks good.

            

            Cheers

            

            Magnus Westerlund

            

            --------------------------------------------------------=
--------------

            Media Technologies, Ericsson Research

            --------------------------------------------------------=
--------------

            Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0| Phone=C2=A0 +46 10 7148287

            Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| M=
obile +46 73 0949079

            SE-164 80 Stockholm, Sweden | mailto: magnus.westerlun=
d@ericsson.com

            --------------------------------------------------------=
--------------

            

            

          

        

        

      

    

    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------4864348CBBC94C00050B8495--

--------------ms020909020503010308080805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA3MjEwNzUxMjJaMC8GCSqGSIb3DQEJBDEiBCCvFNXwjw30B+ZIGAt2
9QFpuF13/lVM+apc58tzU7XKrjBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEALSqTLhkEJEKrOW2xQ1fvXvHL5Pmsb0yXwXHwgYGAUzdaW/tI
Swtqwwqtq+q4Y+L5eG0f/ofQkwWUC3rr3b4lByE9akQ/gBiTqH62Fj/xiAyENzcEOTxZnG/b
b8ULgC6ONOrAOYBpgtzSCKCyvR5ZotegKCKqr0y76j3b0ZRV5kbjV3NL0Ed10kiO8Y/bKuQh
ehGECZhb4NM2QxGEBbNhdem+EVOHuDtz2XkhoUZ3goS7wbzSjSZZe9ox6lEZF84zRKQUsQG7
xTpEaux3Z30QuLs+t1G9m7A/tcP62W/3Wm9KH0ZP+TvZQ6opxcregqYXFeR6ARHpCehQavZr
oXHiegAAAAAAAA==
--------------ms020909020503010308080805--


From nobody Thu Jul 27 10:09:02 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF7D131C8F for ; Thu, 27 Jul 2017 10:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxbJMVmXslsi for ; Thu, 27 Jul 2017 10:09:00 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83E413204A for ; Thu, 27 Jul 2017 10:08:58 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id k43so109045535uaf.3 for ; Thu, 27 Jul 2017 10:08:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=BRGJZFduhzsm7CtudaZlPYPT2GflHTGSfNXdF1aiHCY=; b=b1XzUcohbT3YrPGBdq/+5UzEv4rCM49DWbe7GI24Kyfowe6vjaOtwQy36WmfBJIFKV TQvV2Jy881z3QtEC0PYhn1fjHM4Ikf+5xvkoGH9bbsMAqP/1tlRJV7IxjiCf03lOlD9b bZ8kLee3y7zbmRJ3WOG1/z2v6RzBqLovvmNDqwPlLO29QQtVGn7TADbPjYjX1gHpp/AM Qi6aZUJejPlJz8TO7diD/8mT1D40/xAv1WUdxIG86C1uHHqE6e77DXFPIEhzsWC/lkWS 3Tz3zgPC/ab0BxGAyLpDzd8np1W+SvbNujaVtVpZv/YwlgdOhAbXxvIYfcEJoLxI4Aoo ydcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BRGJZFduhzsm7CtudaZlPYPT2GflHTGSfNXdF1aiHCY=; b=YaJR5Q6id4kPRnRp8KRMzfldkNIOkMGmzv9gFjuTMG5H+PHJV8QkQ4xciV41Bind0d o173mS9Ay4ywQ62vMBmx7w7KciG2IW/W2AjlKxR4XJkrZuMUrZIQ7v1tN3wgJNqkHfsy rRHigMVHFw8Vc8EBaBj3XOGS6S97xgG38HxVQE0K8Nm828/iq/hgool+bh4+3gIexoTd oKEFOzVoLET3KMkcUy6mJ8N4Ta9AkaVRXXOm0MnaARzCbif/pCVDH+CNWu2mlyMhCUES /tLipu1oRz5Zh/VxQYLUdBXi7aUv9kFlOCOeAu3hhbS97vYVIaMTEjQCKDCuz7Q3OGy3 W6BA==
X-Gm-Message-State: AIVw113bTQUSwPiU2MPOTNopdivA7uJdJIwfLw5Fq5g4cNYqw8kyTt7/ p9SmkFCLJNCgkkn7bLZem6ZWlTcMupQ9jtE=
X-Received: by 10.31.50.137 with SMTP id y131mr2887333vky.181.1501175337403; Thu, 27 Jul 2017 10:08:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Thu, 27 Jul 2017 10:08:37 -0700 (PDT)
From: Bernard Aboba 
Date: Thu, 27 Jul 2017 10:08:37 -0700
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11437fccbb4a2405554f9e76"
Archived-At: 
Subject: [rtcweb] JSEP Issue 760: what states/methods allow a "rollback"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 17:09:01 -0000

--001a11437fccbb4a2405554f9e76
Content-Type: text/plain; charset="UTF-8"

Filed as: https://github.com/rtcweb-wg/jsep/issues/760

In W3C WebRTC WG, Issue 1470 was filed relating to checking whether
rollback is allowed:
https://github.com/w3c/webrtc-pc/issues/1470

In discussing this issue, we noticed that precise guidance wasn't available
in JSEP, so this issue was filed.

--001a11437fccbb4a2405554f9e76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Filed as: https://github.com/rtcweb-wg/jsep/issues/760

In W3C WebRTC WG, Issue 1470 was filed relating to checking whether r=
ollback is allowed:
=

In discussing this issue, we noticed that precise guidance w=
asn't available in JSEP, so this issue was filed.


--001a11437fccbb4a2405554f9e76--


From nobody Fri Jul 28 18:03:00 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 091661322C8; Fri, 28 Jul 2017 18:02:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: draft-ietf-rtcweb-jsep@ietf.org, ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , rtcweb@ietf.org
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <150129017294.20667.17960314547810703.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jul 2017 18:02:52 -0700
Archived-At: 
Subject: [rtcweb] Last Call:  (JavaScript Session Establishment Protocol) to Proposed Standard
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 01:02:53 -0000

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document: - 'JavaScript
Session Establishment Protocol'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ballot/


No IPR declarations have been submitted directly on this I-D.