From nobody Wed Aug 2 09:11:23 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 347C91318A8 for ; Wed, 2 Aug 2017 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 (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 d4RHY6u2mGli for ; Wed, 2 Aug 2017 09:11:20 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 98DFA129B03 for ; Wed, 2 Aug 2017 09:11:20 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id p3so29610149qtg.2 for ; Wed, 02 Aug 2017 09:11:20 -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:date:references :to:in-reply-to:message-id; bh=tGZHuqnCfGo4ZZhzBMofJnXIRBEoxn2/DvU0fTDLKvQ=; b=IhkUZxMP64jJSNZo73BRY2/GxOGXj0ktIUzJDVDB1Mfa5ZLccF8jKIT99NrMKA92OT ZhxhDLfQp1ZfIAnGXjljECBtx9RUDgGKRgMzHsvl1A5/QTtABYAe4cPnBtGE6SVQw4zb hrQg25D+DPsBnZkboiIeVNWr3hj5qQVcZKUxU= 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:date:references:to:in-reply-to:message-id; bh=tGZHuqnCfGo4ZZhzBMofJnXIRBEoxn2/DvU0fTDLKvQ=; b=ho4tpE+UDrQ2Dh494dn3vXqF+duWNR+QjD+On9lNEryO7eZHZUQEFImiqRdKbLtVqU NncV0Eos/WvFMt4W0iGbTTXzdijED9SEjRXcC6IlKdd2ICMFVA6roYOUYu6+Eb87YZWh kwc1y9L8AUzRKF1d3XqHOH5DQh+p5v94UU6ttYewzmn6YOxif/jroPSOnuGa36SNggNO sU5mpjbyDQjzHtZ4C6xTuET6ApBNZpTUFeU/SKelFtPJW2JpGCavkTfYM4dIWDWZnR1+ xHJAOCQQhax82hoHBrScOoqmBSez9W1igxkXUx+BkYLtZXMW7G9yPaEfI17srpRa2oN9 xcgw== X-Gm-Message-State: AIVw111fDfnGRR9tkMsj+5pQKiyoJl4dzRuS7eQaeu1JuJgSGVllIERp FhcHYtKNkPAsseWJ5Lhz9w== X-Received: by 10.237.37.45 with SMTP id v42mr34521290qtc.333.1501690279498; Wed, 02 Aug 2017 09:11:19 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id i79sm23570913qke.3.2017.08.02.09.11.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 09:11:18 -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\)) Date: Wed, 2 Aug 2017 12:11:17 -0400 References: To: "rtcweb@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [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: Wed, 02 Aug 2017 16:11:22 -0000 Any takers? spt > On Jul 20, 2017, at 02:27, Justin Uberti wrote: >=20 > 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. >=20 > 1. https://github.com/juberti/draughts/issues/81 >=20 > Currently, the document indicates that Opus' built-in FEC mechanism = MUST be implemented and SHOULD be used when needed. >=20 > However, Bernard mentioned that his experience with Opus did not show = a benefit: >=20 > [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.=20 >=20 > Does anyone else have an opinion on this matter? >=20 > Bernard, are there any specifics you can share? >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Aug 2 09:15:40 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 2517813214C for ; Wed, 2 Aug 2017 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 (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 pMLoT3AkJRg7 for ; Wed, 2 Aug 2017 09:15:37 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 A934F132148 for ; Wed, 2 Aug 2017 09:15:37 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id t37so29715744qtg.5 for ; Wed, 02 Aug 2017 09:15:37 -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:date:references :to:in-reply-to:message-id; bh=tgQKIHHXU8EDU0jFsegIvwFpRCQQzazzE0wOn2gaDmQ=; b=EncVLCOmvIXmEoBGa5+ePmndwPUHH1M0rqedjxTgrdYzdUjJo5DZ5DbLQh8TDTKerr OgjpDqk4sNj0+tHaP4qjgEymziaEqtuSn8PaCZbL2Iie8CSCiN9Li+/egKBRdU6vNXZ7 oDTILJLlT1aOUyF7n7xeIvNxXM3cOfdrzSgCU= 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:date:references:to:in-reply-to:message-id; bh=tgQKIHHXU8EDU0jFsegIvwFpRCQQzazzE0wOn2gaDmQ=; b=QcZ0pVnLuWF7JPg/UO1cCXWnfDHba/A18M4aECjip8Q4LzkqKc5domVQ0w+MVue71q ievpphb2KNFaIc0KdAvzgqht4Cob1ZVSBo9v42d7pKoB83SrWXnzpTKzqugdSBmP+TYC c0IMuv59DVUUMKM55XcmOEO4rFVhJzTfx4VPaTlst8uQ3S/Qcd0MMlWjrRcSraTmMuPM lgeLy9hdmx4b7W4eU86viFOJ2QrmQgAx/LxysdkczobJ4pG4ZZ6p5DRBf9XZpsCBXhDD UV18hWchHBAamlu7zPPiWuE0eItC/oe++yJ6jPGKVwioFU4UmxBlGCglSz2D+SW/bFGQ J1Uw== X-Gm-Message-State: AIVw1112ez+viWYiA2OBIymwwfWctPnredCw0MAo/VHd198zrOLRx/c2 1H0iWcG0tpvyOaGR+w0K1Q== X-Received: by 10.237.59.211 with SMTP id s19mr9636727qte.254.1501690535970; Wed, 02 Aug 2017 09:15:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id e40sm25001632qta.14.2017.08.02.09.15.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 09:15:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 Aug 2017 12:15:34 -0400 References: To: "rtcweb@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [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: Wed, 02 Aug 2017 16:15:39 -0000 Here=E2=80=99s another one that might have gotten buried since IETF = week. spt > On Jul 20, 2017, at 02:45, Justin Uberti wrote: >=20 > 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. >=20 > 1. https://github.com/juberti/draughts/issues/59 >=20 > In the problem statement, should the paragraph on VPNs mention IP = address discovery?=20 >=20 > Currently, the problem statement says the following: > 1. If the client is behind a Network Address Translator (NAT), the >=20 > client's private IP addresses, typically [RFC1918] addresses, = can >=20 > be learned. >=20 > 2. If the client tries to hide its physical location through a >=20 > Virtual Private Network (VPN), and the VPN and local OS support >=20 > routing over multiple interfaces (i.e., a "split-tunnel" VPN), >=20 > WebRTC will discover the public address for the VPN as well as >=20 > the ISP public address that the VPN runs over. >=20 > 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? >=20 >=20 > 2. https://github.com/juberti/draughts/issues/60. >=20 > Should supporting WebRTC over Tor be an explicit goal of this document = (and mentioned in the goals section)?=20 >=20 > 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? >=20 >=20 > 3. https://github.com/juberti/draughts/issues/61 >=20 > Should the document discuss implementation details as it relates to = suggested default behavior?=20 >=20 > The document currently says the following: >=20 > 1. By default, WebRTC should follow normal IP routing rules, to = the >=20 > extent that this is easy to determine (i.e., not considering >=20 > proxies). This can be accomplished by binding local sockets to >=20 > the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which >=20 > allows the OS to route WebRTC traffic the same way as it would >=20 > HTTP traffic, and allows only the 'typical' public addresses to >=20 > be discovered. >=20 > 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. >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Aug 2 16:03:50 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 AFCEE129B35 for ; Wed, 2 Aug 2017 16:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 bdu9eKIfS5Re for ; Wed, 2 Aug 2017 16:03:47 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 346C3126B6E for ; Wed, 2 Aug 2017 16:03:47 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id u139so35556719qka.1 for ; Wed, 02 Aug 2017 16:03:47 -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=+v9w4wwzAwe2/iiudqV7wFlzIcHyWTmkGLz9fTju2LE=; b=XJ8+QrSTPyIr3PYl0niVZV3xuiXCVVpY9hRS1wxeKh/wj/7TYkGbUFLjG+Qdninl3v X9JhvSLyJtgA+BkFVlabQ9nIwFB414IQtuawLtrPbmgNMLKXhhIsNx5D31Kkkab288ux U5KK5x+iuzAbfxf9yLl7hUJ8YuqwOAGGGZBD8wfde/fVEX5sKWaTgbf9G/NoLDMVH75d s+5VpkMtpmzcCbsFYF8u+AfKZrSRLa2SM2cc3uFJ/3eZTZxaEQTL0gfJZ4CKF/AX9VAT 7yrhSVP03udzkD0UoeEvR0k81RPUUxpZHWZEVlRhAiaal76h8LtwyOpu9z5dE8s7/XBl XyRQ== 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=+v9w4wwzAwe2/iiudqV7wFlzIcHyWTmkGLz9fTju2LE=; b=eKeaGd2R9Vv1oLm/0nL7Fraq8ww+vbfDuhDJaYRusujpgB4tykumUQ9tbIEt7m7azt lTc0cWY62dJkpOhCHp87SZDpg6DZ26rqdwHupXnjfMJKkNk5+S7Ddm82MynRmBS5VBgo /mKJ48OFg9R0FJKvHbGsCyFmMYav6vPl/bg4QPApJS8RA2QEC6ALyEYbsU5JW/j/Nq/8 AUsX2MCsqyaG33kj7IXinpj/MuMjrf7mgPyPVB2eHT7kbEP4odZFtCPhiKkmx3oyH87N ldtawyzd3PSLB8Z5N1nVHBqxUcU0U4YIc1LP0pFnPcUSb2PLoGYhw9TRhUvO8jxQaC75 YIug== X-Gm-Message-State: AIVw112nBlltV8eH9JFB6r/LBfsD5hGqZkKDwmgaLMKTmukhDO5eiLLG rlEmvfXg9O09xMYkferB4KwDlw0g6kdZ X-Received: by 10.55.15.34 with SMTP id z34mr30919899qkg.19.1501715026113; Wed, 02 Aug 2017 16:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.59.248 with HTTP; Wed, 2 Aug 2017 16:03:15 -0700 (PDT) From: Ted Hardie Date: Wed, 2 Aug 2017 16:03:15 -0700 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary="001a113acef2af7c290555cd463b" Archived-At: Subject: [rtcweb] Working Group Last call on 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, 02 Aug 2017 23:03:49 -0000 --001a113acef2af7c290555cd463b Content-Type: text/plain; charset="UTF-8" This call begins a two-week working group last call on draft-ietf-rtcweb-fec. There is one outstanding issue: https://github.com/juberti/draughts/issues/81, in which Bernard questions the usefulness of the mandated OPUS FEC. Comments on that issue are solicited, as are any other issues which may be identified in review. regards, Ted, Sean, Cullen --001a113acef2af7c290555cd463b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This call begins a two-week working group last c= all on draft-ietf-rtcweb-fec.=C2=A0 There is one outstanding issue: https://github.com/juber= ti/draughts/issues/81, in which Bernard questions the usefulness of the= mandated OPUS FEC.=C2=A0 Comments on that issue are solicited, as are any = other issues which may be identified in review.

regards,
Ted, Sean, Cullen
--001a113acef2af7c290555cd463b-- From nobody Mon Aug 7 07:06:26 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 184431321E3 for ; Mon, 7 Aug 2017 07:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 YMDr0SvdUITy for ; Mon, 7 Aug 2017 07:06:23 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 172D81321E7 for ; Mon, 7 Aug 2017 07:06:22 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m85so7976685wma.1 for ; Mon, 07 Aug 2017 07:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Nx6obDopquZTGNPJXFpfZfZpR/ker3+7gPezhwBmuxk=; b=poOuGevCvZqzCRcnUwCuM+gEAxzg2Du2CipUV9vVKkHhY3SJq/mT1QiYgnm8PhRm1Z SAaYjf+4jezBNtEA22w5t/nlUg09N9xnahM0d9bev9oeV8AHfQACUtSCz4ezKJD9To1/ ghTZ5ojtR9Syr9cXn35ZNV0MnfVTPEepZCSYw8Q2d3ubSU8xhNhPzVmUZ0IxBqi2HXOu 1vVhiveW+WwO17co0dvBa6hegV54uMWZL7XCZIDWamX3/0jMPn62JylxSTvJXYF/Yp5W 1bGcb1WyhmV+lf9Tn5blr+p6aIMMAQS6daHpvEcQd2l19OWKwd14mtdGJjX5GUyTrt99 6TqQ== 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 :content-transfer-encoding; bh=Nx6obDopquZTGNPJXFpfZfZpR/ker3+7gPezhwBmuxk=; b=fPCzLiVmdgCvm5nJVdjWJ6Thw/M2JonkaNihL5VhRP0KizzTu04DW+pMi8DMjsoZhW UFE0mUyE5pAs2797krLkYnHnczEvpOoEKmv3RBiXYa68KTBLuQHT9MSyMuEx4j7V4dZ+ 6pQ2S0QIb5QTLGeY9WiZ855WdSmtdwBgnsFKGAFjE7yUGPkwY8kdwRIv9Can8aD4ApiC EDBIVUQmrQVI2UbNvr2C/P06YdIBSnfLLTCbLSO0sP4dtqb/eRU2jFIkNGlVJtCSrKE7 wk66daE2xE2XHcsSUFq5DbNmJH4EsjKpQ75ehR/PedqXcCHuW9ockNw+/ATt1dDp0dkG pdow== X-Gm-Message-State: AHYfb5jjMNTi0l+4UQB88w6FOX4r0oPvBuS2nTu5i3IfkzZ9GcgPwCHK apXG9f9Id/Yj+MRkkSMnQXPWFtBwnfIfGQsgsA== X-Received: by 10.80.180.15 with SMTP id b15mr1058159edh.226.1502114781164; Mon, 07 Aug 2017 07:06:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.129 with HTTP; Mon, 7 Aug 2017 07:06:00 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Aug 2017 16:06:00 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 14:06:25 -0000 Hi, Let's assume that Alice sends a offer to Bob with a single m=3Dvideo section that contains: a=3Dextmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time Bob replies with the same extmap. Later Bob generates a re-offer and it looks like this: a=3Dextmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=3Dextmap:2 urn:ietf:params:rtp-hdrext:toffset Is this legal? Couldn't find nothing about renegotiations in https://tools.ietf.org/html/rfc5285, however it looks to me that the world would be better if the already negotiated extension mapping is kept. Said that, Chrome does keep the previously negotiated ext mapping, but Firefox does not, behaving exactly as shown above. Bug report in Firefox tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1384064 JSFiddle reproducing it (open the devtool console): https://jsfiddle.net/ibcaliax/uan2fove/ --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 7 07:10:32 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 7319A1321D1 for ; Mon, 7 Aug 2017 07:10:30 -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 0iwwvB6ajrbf for ; Mon, 7 Aug 2017 07:10:27 -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 4B0E3132324 for ; Mon, 7 Aug 2017 07:10:27 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-b9-598874d12b30 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.97.05732.1D478895; Mon, 7 Aug 2017 16:10:25 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 7 Aug 2017 16:10:24 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA Date: Mon, 7 Aug 2017 14:10:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7qO7Fko5Igy/b5Cym77OxWPuvnd2B yeNcw3t2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZcxZdoS9YJZgxfelaxgbGB8IdDFyckgImEhM +HCVqYuRi0NI4AijxKxz35ghnEWMEvO/zgVyODjYBCwkuv9pgzSICCRLPOo4zgpiCwt4SdxZ DlICEveW+DNrPiOEbSRx7sk0VpBWFgEViT3vXUHCvAK+EpdvfmQCsYUEAiSar38CG8MpECix 895XFhCbUUBM4vupNWA1zALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsJYlFtz8zgaxiFtCU WL9LH6JVUWJK90N2iLWCEidnPmGZwCgyC8nUWQgds5B0zELSsYCRZRWjaHFqcVJuupGRXmpR ZnJxcX6eXl5qySZGYBwc3PLbYAfjy+eOhxgFOBiVeHg3x3VECrEmlhVX5h5ilOBgVhLhDeQC CvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp1cAYJ+r5QPJu ZcnvtJUn36/av4DzpKSvdNVVP6nvV28F+z7sFBaaoXvsrY00h/8DNkVhywv3LbYH56qd0rzz abPV9Y+Hd5/LOMAmev2X0PynEbP6/syMvr1jHZ+VcNzcy1JaL7b5rn0dl/TL5qN/erQia392 eUOpnsBZzckqOecX/XIO0A75yGypxFKckWioxVxUnAgAl/pgT38CAAA= Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 14:10:30 -0000 SGksDQoNCk15IGFzc3VtcHRpb24gaXMgdGhhdCBpdCBieSBkZWZhdWx0IGlzIGFsd2F5cyBhbGxv d2VkIHRvIHJlLW5lZ290aWF0ZSBTRFAgYXR0cmlidXRlIHZhbHVlcy4gQW5kLCBpZiBpdCdzIG5v dCwgaXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLg0KDQpZb3Ugc2FpZCB0aGF0IENo cm9tZSBrZWVwcyB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIHZhbHVlLiBEb2VzIENocm9tZSBz dGlsbCBhY2NlcHQgdGhlIG5ldyBvZmZlcj8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgScOxYWtpIEJheiBDYXN0aWxsbw0KU2VudDogMDcg QXVndXN0IDIwMTcgMTY6MDYNClRvOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFtydGN3ZWJd IFJlcGxhY2luZyBhPWV4dG1hcCBtYXBwaW5nIGluIHJlLW9mZmVyLCBpcyBpdCBsZWdhbD8NCg0K SGksDQoNCkxldCdzIGFzc3VtZSB0aGF0IEFsaWNlIHNlbmRzIGEgb2ZmZXIgdG8gQm9iIHdpdGgg YSBzaW5nbGUgbT12aWRlbyBzZWN0aW9uIHRoYXQgY29udGFpbnM6DQoNCiAgYT1leHRtYXA6MTEg aHR0cDovL3d3dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0cC1oZHJleHQvYWJzLXNlbmQtdGlt ZQ0KDQpCb2IgcmVwbGllcyB3aXRoIHRoZSBzYW1lIGV4dG1hcC4NCg0KTGF0ZXIgQm9iIGdlbmVy YXRlcyBhIHJlLW9mZmVyIGFuZCBpdCBsb29rcyBsaWtlIHRoaXM6DQoNCiAgYT1leHRtYXA6MSBo dHRwOi8vd3d3LndlYnJ0Yy5vcmcvZXhwZXJpbWVudHMvcnRwLWhkcmV4dC9hYnMtc2VuZC10aW1l DQogIGE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6dG9mZnNldA0KDQpJcyB0 aGlzIGxlZ2FsPyBDb3VsZG4ndCBmaW5kIG5vdGhpbmcgYWJvdXQgcmVuZWdvdGlhdGlvbnMgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyODUsIGhvd2V2ZXIgaXQgbG9va3MgdG8g bWUgdGhhdCB0aGUgd29ybGQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBhbHJlYWR5IG5lZ290aWF0 ZWQgZXh0ZW5zaW9uIG1hcHBpbmcgaXMga2VwdC4NCg0KU2FpZCB0aGF0LCBDaHJvbWUgZG9lcyBr ZWVwIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgZXh0IG1hcHBpbmcsIGJ1dCBGaXJlZm94IGRv ZXMgbm90LCBiZWhhdmluZyBleGFjdGx5IGFzIHNob3duIGFib3ZlLg0KDQoNCkJ1ZyByZXBvcnQg aW4gRmlyZWZveCB0cmFja2VyOg0KaHR0cHM6Ly9idWd6aWxsYS5tb3ppbGxhLm9yZy9zaG93X2J1 Zy5jZ2k/aWQ9MTM4NDA2NA0KDQpKU0ZpZGRsZSByZXByb2R1Y2luZyBpdCAob3BlbiB0aGUgZGV2 dG9vbCBjb25zb2xlKToNCmh0dHBzOi8vanNmaWRkbGUubmV0L2liY2FsaWF4L3VhbjJmb3ZlLw0K DQoNCi0tDQpJw7Fha2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxp c3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg== From nobody Mon Aug 7 07:18:41 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 50746132433 for ; Mon, 7 Aug 2017 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 gSh4gll-GD2y for ; Mon, 7 Aug 2017 07:18:38 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 54B4E13242E for ; Mon, 7 Aug 2017 07:18:38 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id k20so27013823wmg.0 for ; Mon, 07 Aug 2017 07:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PfpSA90UvHUB5+QggivwWSZp7mG0KMzeukKBwNX4jV4=; b=v2ig1QoxPOaN23it6r5oiFEt7ugwt/eAFpaTmUK+39tItvmh7zUPEInDXa4JlO1Qag i5FKMheoNfAz/P9bdjaTW/12s4cSf2kFXVOPp9RRl/9RZLpS8hm690dxuJYJUpuM9qIS 21lFnTmJPwsBDsCV3rkkfKy7cZK/yzPID/MgvVLLbig+9I0bZ3+/CQuLYEIYbBL/Aegk DxE9U5irFvOgdIo9ONjF5jft06+B3Z7YG30AGH6DRtivNd6rMtJ0JXuG2DeAOp+ioKBD xcz5s85eu2Q9Eune5v1234fS+GrP21ioISQVfHYhgp8PYzjnRA3lYb+QbK18aoMcV6qW TCiQ== 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:content-transfer-encoding; bh=PfpSA90UvHUB5+QggivwWSZp7mG0KMzeukKBwNX4jV4=; b=AcIabBmHAqj2ImkfzBUH+nhS/lcZuPp73wbyq99j9oliOHeh1N8JbRG08LJxnErc0Y tr7d5aCAKD9CVcCLsanvn4AN63bktg9mzW2bAatzFsQpN7IqfglPSHeiF1iA0bv7vmgf 1tklZfcoZVftrR+BMo/mA20udUrwhkFvGRDieJmRAc7bJQhgQ50ZJ532frI5sWliime3 +WzPt04q/609CE5RTVN9YkyHeKU30DBCWHSbU2SS890ty5p2x25VN1CTG0X0zeK+ZrQP WFndLIK+RhaaNcUaEZH/VCnMZzQlVJjfz6yAEDvyWpW5UumizWCxKFx/QcUt2DMfWgfW +TXw== X-Gm-Message-State: AHYfb5iGBqmfGmzLt7+b1aLcXh08ZkND5sOTbxb0AsHuRhTonUBs9ckl HIV0NRjLEZDclIXfLmoRJtX2b7qpy8tw X-Received: by 10.80.220.5 with SMTP id q5mr1113188edk.223.1502115516851; Mon, 07 Aug 2017 07:18:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.129 with HTTP; Mon, 7 Aug 2017 07:18:16 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Aug 2017 16:18:16 +0200 Message-ID: To: Christer Holmberg Cc: "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 14:18:40 -0000 On Mon, Aug 7, 2017 at 4:10 PM, Christer Holmberg wrote: > My assumption is that it by default is always allowed to re-negotiate SDP= attribute values. And, if it's not, it should be explicitly indicated. SDP O/A is really error prune. This must end. It cannot happen that, for every renegotiation (which may be it just wants to add/remove a track) everything regarding ICE, DTLS, codecs. extmap, etc etc must be re-inspected. > You said that Chrome keeps the previously negotiated value. Does Chrome s= till accept the new offer? AFAIR it does not complain, but it's hard to know whether Chrome keeps the previously negotiated ext mapping or respects the new one, since another "SDP O/A related bug" happens: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1247725 This is really crazy. I hope we can drop SDP from WebRTC soon. This is not = sane. --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 7 10:46: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 103F71326C4 for ; Mon, 7 Aug 2017 10:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=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 YcG-NK_ZTQ79 for ; Mon, 7 Aug 2017 10:46:11 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 88086131FE2 for ; Mon, 7 Aug 2017 10:46:11 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id v29so6816286qtv.3 for ; Mon, 07 Aug 2017 10:46:11 -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=c7fjrcokXj+l8ekNcYF+nYsmWyZasvxB0OqZ1RIm7ik=; b=HHYMdqoJMIb0BfDf31dfyXaZfbxzn73ZgIza93IKXiQTY5s2eHu9dG5EgreIzH0Gak eRuf7drdguTDYTQGy6+GTSoc0+eIfW7TKmTVne5eEh7TR8xrg9nT+Y7sfKV1Uu4i/e2N 6krYuOcOEkyihbcvUzl3zdEJeJwNzy6Gx315/+iUC7lZboR2jGwur/CdtB6WYB6wT63r fhPP5T6+0CoFSbWKj9dIjPYrLNskq2jZI3oi2B9MAzEMRCrsq5ylK4yBWrqS1YE06Hj1 ulGNrtjunBaiOtzfnSkIaDw8f0o3DUphDVVnZRx8LLNwjy+8x9JsvybdRUz4QO8Ji6tS ho3Q== 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=c7fjrcokXj+l8ekNcYF+nYsmWyZasvxB0OqZ1RIm7ik=; b=jgCPFiAqx8+fRb/vB5cc3TFUuYgBukLeKV4NrrLyPAgpj3wWRvzPO1FDjVRptQalvj IqIByR5gpEjuWDyIwS9jwRP3KY2gBKLafui2Ik9ZYxOwSV+LhXDX+o5jnmfyZggywbqM dQEZXOkU2/KPKcbd7R77BmEv+XfUtvQhjvqrbBT4G3fqCUPWzOHlJZbTriRI/8f3QwTH 9MlnHmWf2ynb5U3fXoyJGOMfBybZ3eMAHDLmC+YWiTllBtFnzR7PfWWX7zQNT6vzYFqI y90+lDy6JDm+H/fuK6F6jR3RGXVpYVLo+0yBIVgp/0krY2ajIOF5OZHNwji2JyV6ag2E IcCQ== X-Gm-Message-State: AHYfb5hn1pUnFCMs1cQyp1RMQQsrbtSXpI3Keihnz8LGBeDYhRsJuepi cqBmBwEdxU7zLfUhH81L1crDNXnrqTVGUP5nWg== X-Received: by 10.200.9.93 with SMTP id z29mr1886653qth.102.1502127970561; Mon, 07 Aug 2017 10:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.130.163 with HTTP; Mon, 7 Aug 2017 10:46:10 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Mon, 7 Aug 2017 10:46:10 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Christer Holmberg , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a11454b301832e405562d6c15" Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 17:46:14 -0000 --001a11454b301832e405562d6c15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't know if this is stated explicitly anywhere, but my assumption was that it works like payload types. You can introduce new IDs all you want, but you can't have one ID refer to multiple things during the same session. Otherwise, if you receive a packet with that extension ID, you wouldn't be able to tell which extension it is. Meaning, if Bob's initial answer was: a=3Dextmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time It would be illegal to have a re-offer of: a=3Dextmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=3Dextmap:11 urn:ietf:params:rtp-hdrext:toffset Because if Bob then receives a packet with extension ID 11, Bob doesn't know if it's a packet sent before Alice received the answer (in which case it's "abs-send-time"), or after (in which case it's "toffset"). On Mon, Aug 7, 2017 at 7:18 AM, I=C3=B1aki Baz Castillo wro= te: > On Mon, Aug 7, 2017 at 4:10 PM, Christer Holmberg > wrote: > > My assumption is that it by default is always allowed to re-negotiate > SDP attribute values. And, if it's not, it should be explicitly indicated= . > > SDP O/A is really error prune. This must end. It cannot happen that, > for every renegotiation (which may be it just wants to add/remove a > track) everything regarding ICE, DTLS, codecs. extmap, etc etc must be > re-inspected. > > > > You said that Chrome keeps the previously negotiated value. Does Chrome > still accept the new offer? > > AFAIR it does not complain, but it's hard to know whether Chrome keeps > the previously negotiated ext mapping or respects the new one, since > another "SDP O/A related bug" happens: > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1247725 > > > This is really crazy. I hope we can drop SDP from WebRTC soon. This is no= t > sane. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11454b301832e405562d6c15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know if this is stated explicitly anywhere, bu= t my assumption was that it works like payload types. You can introduce new= IDs all you want, but you can't have one ID refer to multiple things d= uring the same session. Otherwise, if you receive a packet with that extens= ion ID, you wouldn't be able to tell which extension it is.

Meaning, if Bob's initial answer was:


It w= ould be illegal to have a re-offer of:

a=3Dextmap:1=C2=A0http://www.webrtc.org/experiments/rtp-= hdrext/abs-send-time
a=3Dextmap:11 urn:ietf:params:rtp-hdrext:toffset
<= /div>

Because if Bob then receives a packet with extension= ID 11, Bob doesn't know if it's a packet sent before Alice receive= d the answer (in which case it's "abs-send-time"), or after (= in which case it's "toffset").

On Mon, Aug 7, 2017 at 7:18= AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On Mon, Aug 7, 2017 at 4:10 PM, Chri= ster Holmberg
<christer.holmberg@eri= csson.com> wrote:
> My assumption is that it by default is always allowed to re-negotiate = SDP attribute values. And, if it's not, it should be explicitly indicat= ed.

SDP O/A is really error prune. This must end. It cannot happen that,=
for every renegotiation (which may be it just wants to add/remove a
track) everything regarding ICE, DTLS, codecs. extmap, etc etc must be
re-inspected.


> You said that Chrome keeps the previously negotiated value. Does Chrom= e still accept the new offer?

AFAIR it does not complain, but it's hard to know whether Chrome= keeps
the previously negotiated ext mapping or respects the new one, since
another "SDP O/A related bug" happens:

https://bugzilla.mozilla.org/show_bug.cgi= ?id=3D1247725


This is really crazy. I hope we can drop SDP from WebRTC soon. This is not = sane.

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

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

--001a11454b301832e405562d6c15-- From nobody Mon Aug 7 10:56:24 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 6698713289B for ; Mon, 7 Aug 2017 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 UYZXVr1t2X5W for ; Mon, 7 Aug 2017 10:56:19 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 C12CE132867 for ; Mon, 7 Aug 2017 10:56:08 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t201so12899388wmt.0 for ; Mon, 07 Aug 2017 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=752KIY39rkdVfJM97Spm04Ccf9dNhIz9lezij6o8szI=; b=qPJP1TnM7Mn4S0p4ftyMvhE4kM6xkoOREmcRrZpCspf94lBTbfWfxr7HTVFvCJ9pJU uTlprZS54G6ND1Tw3M+1QFKjzZi5LvJahx5AY/M3lG9ZV3Czapk1bVwqqkDfHkCkWAS0 83xu2+BN0e7LzuC5me2fivTSJteL3wnXiYHfXAF1MDmG6tzB58IG9dRYiI2gPaZb20Mn 6setkRM7fEpeXjN2fE3XCEW/gy9VSzzol3q/opnMrRwrlvpbkjZwaqUSkaCMzpU2aIAt t3tLGgtLAtu84xtfeocjQ348vWQS2ee0phaBIQcn4vNSV45z8hoKoPrPrndNF/bMAHoT vncg== 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:content-transfer-encoding; bh=752KIY39rkdVfJM97Spm04Ccf9dNhIz9lezij6o8szI=; b=dwnTsXFHvt2cF/+EXgWPGk6eNBUDpWqTiVuIxN9XDqshzxNpbKmj/DqOpwBHsrpnQ5 Pwu42FXZ2LTXI4qa6D+0WatTI4XvwKSzmEKAEOUwNItAF4jNnNRQ553r7fHSk3QelzfB 1WfXAjW5JhcOFlXdt74tBq4N3DxPAzcrEC7LwBS9uSGSn01Gkdr57vRbtrmBjpWDGwl7 07iIDlzki59vICCV0yNSEAu3n/9pkOANnT+P9fEGsQMhidI2xmVx3CGqFE7FzJRJQkIj hLn1oFNJNLFw2hL5zvexAnp4ZI0H4PYVOA+dCxahGOl3MqXUj6q5PZvrzH8K/eURmzTb 6Kgg== X-Gm-Message-State: AHYfb5jWbynaTJUaP57gUdy5OYMSvdyzjtrEtEzCcX7r2fVt/6U/brH3 NXLXFChq0AqyZz3/YM9xn/ZIMYAPiYUI X-Received: by 10.80.179.12 with SMTP id q12mr1694972edd.151.1502128567343; Mon, 07 Aug 2017 10:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.129 with HTTP; Mon, 7 Aug 2017 10:55:46 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Aug 2017 19:55:46 +0200 Message-ID: To: Taylor Brandstetter Cc: Christer Holmberg , "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 17:56:22 -0000 On Mon, Aug 7, 2017 at 7:46 PM, Taylor Brandstetter w= rote: > I don't know if this is stated explicitly anywhere, but my assumption was > that it works like payload types. You can introduce new IDs all you want, > but you can't have one ID refer to multiple things during the same sessio= n. > Otherwise, if you receive a packet with that extension ID, you wouldn't b= e > able to tell which extension it is. > > Meaning, if Bob's initial answer was: > > a=3Dextmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time > > It would be illegal to have a re-offer of: > > a=3Dextmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time > a=3Dextmap:11 urn:ietf:params:rtp-hdrext:toffset > > Because if Bob then receives a packet with extension ID 11, Bob doesn't k= now > if it's a packet sent before Alice received the answer (in which case it'= s > "abs-send-time"), or after (in which case it's "toffset"). Thanks, your rationale clearly makes sense. However: 1) I don't think Firefox cares about overriding a previous extmap ID during a reoffer. 2) Should we really accept so complex and error prune things just because SDP allows everything? --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 7 11:01:50 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 919C3132382 for ; Mon, 7 Aug 2017 11:01:47 -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 0YbK1rLUs2tU for ; Mon, 7 Aug 2017 11:01:45 -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 9908B1325F3 for ; Mon, 7 Aug 2017 11:01:45 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-1e-5988ab079e88 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.F3.07915.70BA8895; Mon, 7 Aug 2017 20:01:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 7 Aug 2017 20:01:43 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Taylor Brandstetter" CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAADoWAIAAAq8AgAAizfA= Date: Mon, 7 Aug 2017 18:01:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdRZd9dUekwa8rlhaXVzxktZi+z8Zi 7b92dgdmj3MN79k9Fmwq9Viy5CdTAHMUl01Kak5mWWqRvl0CV8b5/VNYCp4JVdzblNnAuEKo i5GTQ0LAROLCrrNsXYxcHEICRxglHh44wwThLGKUOL/nJHsXIwcHm4CFRPc/bZAGEYFsiVnP DjKD2MwC6hJ3Fp9jB7GFBbwk7iyfywxR4y3xZ9Z8RgjbT6KzeScbiM0ioCJxoeMgK4jNK+Ar 0bq3A2rXSyaJ9pXLwJo5BQIlFk+/yAJiMwqISXw/tYYJYpm4xK0n85kgrhaQWLLnPDOELSrx 8vE/VghbSWLR7c9MIDczC2hKrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSdhWTqLISOWUg6ZiHp WMDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMGYObvmtuoPx8hvHQ4wCHIxKPLxFMzsi hVgTy4orcw8xSnAwK4nwXpkNFOJNSaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJanZq akFqEUyWiYNTqoGR/UvyU0aXzG5rY68rZnWTr7+7tCDErixCaLaLYXea6Lv9BxKUas4sjHmU cTk4ZeHPLo1e7bj1Hu/y/U6tesASu/ds2LY0mRKnhPUrGG6zHD3te/Hh9p0y6bM2WRkzZGRv +D/tX2V124zG7JJ6/ig9ye+/eydOjf/tUVI+n8HzZRhXwuY0cxYlluKMREMt5qLiRACkmR03 lQIAAA== Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 18:01:47 -0000 SGksDQoNClRheWxvcidzIGV4cGxhbmF0aW9uIG1ha2VzIHNlbnNlLiBCdXQsIGluIHRoaXMgY2Fz ZToNCg0KMSkgUmUtdXNpbmcgdGhlIHNhbWUgdmFsdWUgd2l0aCBhIG5ldyBtYXBwaW5nIHNob3Vs ZCBiZSBhbiBleHBsaWNpdCBNVVNUIE5PVA0KDQoyKSBUaGUgcmUtb2ZmZXIgc2hvdWxkIGJlIHJl amVjdGVkDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpT ZW50OiAwNyBBdWd1c3QgMjAxNyAxOTo1Ng0KVG86IFRheWxvciBCcmFuZHN0ZXR0ZXIgPGRlYWRi ZWVmQGdvb2dsZS5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJl cGxhY2luZyBhPWV4dG1hcCBtYXBwaW5nIGluIHJlLW9mZmVyLCBpcyBpdCBsZWdhbD8NCg0KT24g TW9uLCBBdWcgNywgMjAxNyBhdCA3OjQ2IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVl ZkBnb29nbGUuY29tPiB3cm90ZToNCj4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgc3RhdGVkIGV4 cGxpY2l0bHkgYW55d2hlcmUsIGJ1dCBteSBhc3N1bXB0aW9uIA0KPiB3YXMgdGhhdCBpdCB3b3Jr cyBsaWtlIHBheWxvYWQgdHlwZXMuIFlvdSBjYW4gaW50cm9kdWNlIG5ldyBJRHMgYWxsIA0KPiB5 b3Ugd2FudCwgYnV0IHlvdSBjYW4ndCBoYXZlIG9uZSBJRCByZWZlciB0byBtdWx0aXBsZSB0aGlu Z3MgZHVyaW5nIHRoZSBzYW1lIHNlc3Npb24uDQo+IE90aGVyd2lzZSwgaWYgeW91IHJlY2VpdmUg YSBwYWNrZXQgd2l0aCB0aGF0IGV4dGVuc2lvbiBJRCwgeW91IA0KPiB3b3VsZG4ndCBiZSBhYmxl IHRvIHRlbGwgd2hpY2ggZXh0ZW5zaW9uIGl0IGlzLg0KPg0KPiBNZWFuaW5nLCBpZiBCb2IncyBp bml0aWFsIGFuc3dlciB3YXM6DQo+DQo+IGE9ZXh0bWFwOjExIGh0dHA6Ly93d3cud2VicnRjLm9y Zy9leHBlcmltZW50cy9ydHAtaGRyZXh0L2Ficy1zZW5kLXRpbWUNCj4NCj4gSXQgd291bGQgYmUg aWxsZWdhbCB0byBoYXZlIGEgcmUtb2ZmZXIgb2Y6DQo+DQo+IGE9ZXh0bWFwOjEgaHR0cDovL3d3 dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0cC1oZHJleHQvYWJzLXNlbmQtdGltZQ0KPiBhPWV4 dG1hcDoxMSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDp0b2Zmc2V0DQo+DQo+IEJlY2F1c2Ug aWYgQm9iIHRoZW4gcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBleHRlbnNpb24gSUQgMTEsIEJvYiAN Cj4gZG9lc24ndCBrbm93IGlmIGl0J3MgYSBwYWNrZXQgc2VudCBiZWZvcmUgQWxpY2UgcmVjZWl2 ZWQgdGhlIGFuc3dlciANCj4gKGluIHdoaWNoIGNhc2UgaXQncyAiYWJzLXNlbmQtdGltZSIpLCBv ciBhZnRlciAoaW4gd2hpY2ggY2FzZSBpdCdzICJ0b2Zmc2V0IikuDQoNClRoYW5rcywgeW91ciBy YXRpb25hbGUgY2xlYXJseSBtYWtlcyBzZW5zZS4gSG93ZXZlcjoNCg0KMSkgSSBkb24ndCB0aGlu ayBGaXJlZm94IGNhcmVzIGFib3V0IG92ZXJyaWRpbmcgYSBwcmV2aW91cyBleHRtYXAgSUQgZHVy aW5nIGEgcmVvZmZlci4NCg0KMikgU2hvdWxkIHdlIHJlYWxseSBhY2NlcHQgc28gY29tcGxleCBh bmQgZXJyb3IgcHJ1bmUgdGhpbmdzIGp1c3QgYmVjYXVzZSBTRFAgYWxsb3dzIGV2ZXJ5dGhpbmc/ DQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0K From nobody Mon Aug 7 11:03: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 63E3E13261B for ; Mon, 7 Aug 2017 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 geh3fQ6GStiE for ; Mon, 7 Aug 2017 11:03:47 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 861FF1323A2 for ; Mon, 7 Aug 2017 11:03:45 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m85so13220194wma.0 for ; Mon, 07 Aug 2017 11:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=96W33RpLnE9N5ezlWE5Fo/eAPWjkR5s/HrXybRJ/eQs=; b=BgZevNJuDVpMZeJZsGFkXEYGUgZx26O4s3gYE3uWDD7sWKMihHOL4DkB9YWDoLO9L7 WlTWrM9fkoePG5pgmMMMyTsQb0n954D28AVS95fPaHz+z0xGXaeNFxbTGGs+48Mv71Rc EPlLD2kzwmiDQP5cEEMHjITdZIqjsYfgSEMDVPMpCi47GmKnP/TM4o+ResED7hV6nn0M zzoKM0jGRaiGus0Xc8kSHkl9pXU2Gstmhv+5+iTaQl8tpM7yV+KtO7yTZAevPHD/+v5I 5hpvsMgJm6OgpsOILV93KvlTuQa304pJZuUWaTTAPkcO/x4PeVN7fSMba/a+K0/zTXdG WoVw== 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:content-transfer-encoding; bh=96W33RpLnE9N5ezlWE5Fo/eAPWjkR5s/HrXybRJ/eQs=; b=eG4NT//zuCpdDzD/FWf1AeqGEeVMYXCixZPHzd+WlE1x/xVbjmrYZFzTUKrVdZKV8Z elHK63k7yjs70sqnHwnMkxHcworNxQssIm0kjd10lSnErlPBXtd4ffmv12mxOyaK6/hX muTBOQJzxbF4VnQsTaQigFWr7oWuWrsABlBwA0Tx//gl9kL6EKhUbtoEd8WWmby1unyy +Lmd36it7SNW8CNhkziipM0RsxNC/HbLGcK0ArUBmMgEXqlWB+EN0UmKVyknxYkOTTf6 RubzmPm438Nw/xWJ8on0wVzqU/XwVNuixq4gg3BKGOYlzgQk3mAZdHVXngYvqCSU2Rg3 FWoQ== X-Gm-Message-State: AHYfb5gQQ2bOadQ3hLgoskcdVycuFflyBFwCgXhKxBQ0wT6eDk4uLy5u rsv9dBZDRt5G74H3bIrLYWV2KC9bvq3imEc= X-Received: by 10.80.147.91 with SMTP id n27mr1738228eda.84.1502129024118; Mon, 07 Aug 2017 11:03:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.129 with HTTP; Mon, 7 Aug 2017 11:03:23 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Aug 2017 20:03:23 +0200 Message-ID: To: Christer Holmberg Cc: Taylor Brandstetter , "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 18:03:48 -0000 On Mon, Aug 7, 2017 at 8:01 PM, Christer Holmberg wrote: > Hi, > > Taylor's explanation makes sense. But, in this case: > > 1) Re-using the same value with a new mapping should be an explicit MUST = NOT > > 2) The re-offer should be rejected Hi Christer, I'm lost. If Taylor's explanation is ok, why 1) and 2)? --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 7 11:05: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 97D0A1324C8 for ; Mon, 7 Aug 2017 11:05:36 -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 sXdfJatWFPzl for ; Mon, 7 Aug 2017 11:05:35 -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 5C8FE132677 for ; Mon, 7 Aug 2017 11:05:35 -0700 (PDT) X-AuditID: c1b4fb30-703ff70000001664-16-5988abedc049 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.76.05732.DEBA8895; Mon, 7 Aug 2017 20:05:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Mon, 7 Aug 2017 20:04:32 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAAGAw8A== Date: Mon, 7 Aug 2017 18:04:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB20FB@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2J7oO7b1R2RBm8atS2m77OxWPuvnd2B yeNcw3t2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZdy+u5uxYAtHRfP1m6wNjDM4uhg5OSQETCTm zjvMBmILCRxhlNj+VKqLkQvIXsQosXvmDtYuRg4ONgELie5/2iA1IgI2Ev8uXGAHsZkF1CXu LD4HZgsLeEncWT6XGaLGW+LPrPmMELaTxL3dT8BqWARUJDqbb4HFeQV8Je6du8UGses2o8TB 42vBEpwCgRJ7r00Ba2AUEJP4fmoNE8QycYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpLEotuf mUBuZhbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFS brqRkV5qUWZycXF+nl5easkmRmCEHNzy22AH48vnjocYBTgYlXh4k2d2RAqxJpYVV+YeYpTg YFYS4V29CijEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QD o6WG51l2Vb2gnsmp0/dN5uue+cD8ZFGJ2Ll/rPOr535dfn2PXtMjl8zcyRu8mQ63cRh+D5KK 5bDcZ7n60D9ejqDt4QE7rNN1XJa4uxmaadZMECrV3rJSMl417E65kpbJx+9ySz/93rb8srfP waULIzsXnPbnWX/j2DoX09O6f7xvGB64t1bXS4mlOCPRUIu5qDgRAAdTd3GMAgAA Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 18:05:36 -0000 SGksDQoNCj4+IE15IGFzc3VtcHRpb24gaXMgdGhhdCBpdCBieSBkZWZhdWx0IGlzIGFsd2F5cyBh bGxvd2VkIHRvIHJlLW5lZ290aWF0ZSBTRFAgYXR0cmlidXRlIHZhbHVlcy4gQW5kLCBpZiBpdCdz IG5vdCwgaXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLg0KPg0KPiBTRFAgTy9BIGlz IHJlYWxseSBlcnJvciBwcnVuZS4gVGhpcyBtdXN0IGVuZC4gSXQgY2Fubm90IGhhcHBlbiB0aGF0 LCBmb3IgZXZlcnkgcmVuZWdvdGlhdGlvbiAod2hpY2ggbWF5IGJlIGl0IGp1c3Qgd2FudHMgdG8g YWRkL3JlbW92ZSBhDQo+IHRyYWNrKSBldmVyeXRoaW5nIHJlZ2FyZGluZyBJQ0UsIERUTFMsIGNv ZGVjcy4gZXh0bWFwLCBldGMgZXRjIG11c3QgYmUgcmUtaW5zcGVjdGVkLg0KDQpBbGwgbS0gbGlu ZXMgb2J2aW91c2x5IG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gZWFjaCByZS1vZmZlciAodW5sZXNz IHdlIHByb2dyZXNzIGRyYWZ0LXBvZi1wYW4pLCBidXQgb25lIGNhbiBhbHdheXMgZGVmaW5lIHRo YXQgaWYgYW4gYXR0cmlidXRlIGlzIG5vdCBpbmNsdWRlZCBpbiBhIHJlLW9mZmVyIHRoZSBwcmV2 aW91cyB2YWx1ZSBhcHBseS4NCg0KSW4gdGhpcyBjYXNlLCBob3dldmVyLCBJIGRvbid0IHRoaW5r IGV2ZXJ5dGhpbmctbXVzdC1iZS1yZS1pbnNwZWN0ZWQgaXMgdGhlIGlzc3VlLiBUaGUgaXNzdWUg aXMgd2hldGhlciBpdCdzIGFsbG93ZWQgdG8gY2hhbmdlIHRoZSBhdHRyaWJ1dGUgdmFsdWUgbWFw cGluZyB0byBiZWdpbiB3aXRoLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Mon Aug 7 11:07:01 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 5D322132932 for ; Mon, 7 Aug 2017 11:07:00 -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 EyMKX_379Ctq for ; Mon, 7 Aug 2017 11:06:59 -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 EDCE0132930 for ; Mon, 7 Aug 2017 11:06:58 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-28-5988ac41a370 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 26.A6.05732.14CA8895; Mon, 7 Aug 2017 20:06:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Mon, 7 Aug 2017 20:06:56 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= CC: Taylor Brandstetter , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAADoWAIAAAq8AgAAizfD//99UgIAAIgjg Date: Mon, 7 Aug 2017 18:06:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB2129@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdVddxTUekwaRZAhaXVzxktZi+z8Zi 7b92dgdmj3MN79k9Fmwq9Viy5CdTAHMUl01Kak5mWWqRvl0CV8aEvn8sBR3sFZ8O7mBpYPzA 1sXIySEhYCJxZ/kSxi5GLg4hgSOMEosnT2WDcBYxSrzdMoOpi5GDg03AQqL7nzZIg4iAjcS/ CxfYQWxmgRCJn9e+sIDYwgJeQIPmMkPUeEv8mTWfEcKOkvh75ApYPYuAisTzxutgi3kFfCXW rmxnhdj1hVni/p2ZYIM4BQIlrk99BWYzCohJfD+1hglimbjErSfzmSCuFpBYsuc8M4QtKvHy 8T9WCFtJYtHtz2A3MwtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjA yLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBqDm75bbCD8eVzx0OMAhyMSjy8yTM7IoVY E8uKK3MPMUpwMCuJ8K5eBRTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampB ahFMlomDU6qBcf7yx5JOj63qmp86zG7r2iEq6WggLP93StLN6HkhzmIOaSe4D21LDNPq+pCo ZV3xw2Rnm4LcsyWn9QSn74hW/fNGg+Xzy4DlM6IetDCkXLCrTXtTUNbe9GdJafjeBXGzCs6Z /kkoe7fpYe5+rgUu/JxPP1//f3vOF7F8vSt8VYdMeZwmGBsxKbEUZyQaajEXFScCAP2I+2CW AgAA Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 18:07:00 -0000 SGksDQoNCj4+IFRheWxvcidzIGV4cGxhbmF0aW9uIG1ha2VzIHNlbnNlLiBCdXQsIGluIHRoaXMg Y2FzZToNCj4+DQo+PiAxKSBSZS11c2luZyB0aGUgc2FtZSB2YWx1ZSB3aXRoIGEgbmV3IG1hcHBp bmcgc2hvdWxkIGJlIGFuIGV4cGxpY2l0IA0KPj4gTVVTVCBOT1QNCj4+DQo+PiAyKSBUaGUgcmUt b2ZmZXIgc2hvdWxkIGJlIHJlamVjdGVkDQo+DQo+IEhpIENocmlzdGVyLCBJJ20gbG9zdC4gSWYg VGF5bG9yJ3MgZXhwbGFuYXRpb24gaXMgb2ssIHdoeSAxKSBhbmQgMik/DQoNCk1heWJlIEkgd2Fz IHVuY2xlYXIgOikNCg0KVGF5bG9yIGRlc2NyaWJlZCB3aHkgcmUtdXNpbmcgYSB2YWx1ZSBmb3Ig YSBuZXcgbWFwcGluZyBkb2Vzbid0IHdvcmsuIEkgdGhpbmsgdGhhdCBzaG91bGQgYmUgZXhwbGlj aXRseSBkZXNjcmliZWQsIGFuZCB0aGUgdGV4dCBzaG91bGQgc2F5IE1VU1QgTk9UIHJlLXVzZSB2 YWx1ZSBmb3IgbmV3IG1hcHBpbmcgKGhlbmNlIDEpLg0KDQpTZWNvbmQsIElGIGFuIG9mZmVyZXIg c3RpbGwgdHJpZXMgdG8gcmUtdXNlIGEgdmFsdWUgZm9yIGEgbmV3IG1hcHBpbmcsIHRoZSB0ZXh0 IHNob3VsZCBzYXkgdGhhdCB0aGUgcmVjZWl2ZXIgTVVTVCBkaXNjYXJkIHRoZSBvZmZlciAoaGVu Y2UgMikuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Mon Aug 7 11:21:43 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 6267A132331 for ; Mon, 7 Aug 2017 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=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 Tpn22Dr0HCNq for ; Mon, 7 Aug 2017 11:21:40 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 B57871326DF for ; Mon, 7 Aug 2017 11:21:40 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id a18so7587751qta.0 for ; Mon, 07 Aug 2017 11:21: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=MXezUAWtNkwjGJwFYkjvmtjzVG5De6cFmjg2rPyQp0k=; b=h4AlJwHOLpHN9rCxFEYDdOPBNSTh26MGwRv2fF36r5mFq3zuIII1I1BgCpkmYw6cWZ U6H8Gi1H97qKDJgwvM5tBp6V86Rh+g+f86Mo/zFYkIE+RAmJBpUdJfeToAqEhT+JQDGy rwT0FoAF3ygAzXjJultuJjVigY/foLPLwJ+nmZhg+GtOwkyA3y/iBVlQURYNsf856GxW 6P3NIWuq4GWVK8G7lDohQr/WGw+9uxBhkr7YRaO2SoevHi2aXDImfgJE22avab1WivF2 gBqa7B/b9inu1TGJbcV4FrfiPI88AmR4n8vGMO4kNtFnW52ciD3aDtBnEkwdg+8syeNL ItVg== 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=MXezUAWtNkwjGJwFYkjvmtjzVG5De6cFmjg2rPyQp0k=; b=moMS3pYhu8pAsaSwvda73veWdKSMPRZRjX9Z5hdya5PbHmCDXzo/JZ3AaN3Ey+kZOZ w3SRtIjS5IfZBUiCp6Sl8D8MgM99lfCUUX9kUZtF7R75hTJwR9RaFrr4XNgaXTSRhQJc IgOF4HXm5Yy/QMmGuaMeq8GhKAEdtjJTCJAzQ9uAAx8dQfsLZ4Lc5yWQHS+y0z1y7Nrv FHb5If+NhFgLvGvZ2qbQy2KJKLiNHULFkF0HHRbu9ZJVyE1SZhPPA7ChdYqKkoo3GpSD pzsRGi9k00PKQe/DzSOTxmS+dvisRpWSNH2A+vo9LYu01qwBg9iEyiIiBl+uf+3dkoOt r10w== X-Gm-Message-State: AHYfb5jQqz4FXnS+GGvHJFdoN6vNtryv52tBzi+3aCgGhCVjz6gdAFqC nf88uYRMWo+Gg7so/i4Sv9wJ6kbtMIky X-Received: by 10.200.52.100 with SMTP id v33mr2143107qtb.67.1502130099810; Mon, 07 Aug 2017 11:21:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.130.163 with HTTP; Mon, 7 Aug 2017 11:21:39 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB2129@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2129@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Mon, 7 Aug 2017 11:21:39 -0700 Message-ID: To: Christer Holmberg Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a1143b9280203c305562debe9" Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 18:21:42 -0000 --001a1143b9280203c305562debe9 Content-Type: text/plain; charset="UTF-8" Christer and I are in agreement. He's just saying "there should be a MUST NOT in the spec." And there is: Identifiers values in the valid range MUST NOT be altered (remapped). > > On Mon, Aug 7, 2017 at 11:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> Taylor's explanation makes sense. But, in this case: > >> > >> 1) Re-using the same value with a new mapping should be an explicit > >> MUST NOT > >> > >> 2) The re-offer should be rejected > > > > Hi Christer, I'm lost. If Taylor's explanation is ok, why 1) and 2)? > > Maybe I was unclear :) > > Taylor described why re-using a value for a new mapping doesn't work. I > think that should be explicitly described, and the text should say MUST NOT > re-use value for new mapping (hence 1). > > Second, IF an offerer still tries to re-use a value for a new mapping, the > text should say that the receiver MUST discard the offer (hence 2). > > Regards, > > Christer > --001a1143b9280203c305562debe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer and I are in agreement. He's just saying &quo= t;there should be a MUST NOT in the spec."

And ther= e is:

Identifiers values in the valid range MU=
ST NOT be altered (remapped).

--001a1143b9280203c305562debe9-- From nobody Mon Aug 7 12:12:37 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 3BF73132937 for ; Mon, 7 Aug 2017 12:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 4vI87h42DVCi for ; Mon, 7 Aug 2017 12:12:34 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 7CAAD132933 for ; Mon, 7 Aug 2017 12:12:34 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so14181109wma.1 for ; Mon, 07 Aug 2017 12:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DOw2n7San62RZjuzcUYWnG3MQpC7w4++GAdQtDDD2TU=; b=IzAZnrBdxfevBZxpUqPXIz0xuI8FOX7IAJtq8yfY8BiGOL7xO29VuCv+jaIyYHSpva pIGvQdZhQ4/jmwmZBsGRXC1PcC0rI9BYz8Cx8X1Pe8Wk9d9Tzm71ZwHHyrWQM4UFNJQf SeZb20ICCsHSDnawXbHeCTkWNkd2Nv24NP9yvMVwEBmTDORSCoykVPIAKTwXrXdNBCQG dJLfLXotJD+XqBIEc09z+9AFvFfSjRphwe1+Eh5ZfN7TdgOScH3hpBW/vJeJm3LmN+CH XlNeDQ5YaapIeBP18MGJ6lg5Zfi553b+PMEybN1RIQielFkyPQq21J0uNCsmDOtR+SET 0qfA== 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:content-transfer-encoding; bh=DOw2n7San62RZjuzcUYWnG3MQpC7w4++GAdQtDDD2TU=; b=FLi+oPasDuTC0jqMYoqBmXgPzgJ+RwiGbs3bMBz+GuI1lET3YPfP60Y40eEWlTpIai XqpPPNnhqUJlJVHSrolvpq3mfe4X5jponpMwNTPAKpzHdWDW6nRuBD588PqByC3g2Wo8 I5h76IiJCY5aR9BX9C3sr0q027TTsz70/eSLChdn6Ec5WeJVOvk93rSgPSoP1CwGuq9N lLFJAHCJzsp6sKclHJBwQRCs8dOaUQ4eX3qs/WzD4MBPLTTLzDKSic77N06wvnqNGrWp mpJcktiEwFzvNhqBBFjS/c3m4VsnWhspdhuAdMAbFbVboy/J6FkUO9p8B9iOABB+SPPu usaQ== X-Gm-Message-State: AHYfb5jrF3YfvH0LYPaIuRuKh82TJ5TMyd0VvNBHrTuOfou8SmduQ0Q7 23R0+GEQqTx8Exm7jerk+5TiuKX6T8jw X-Received: by 10.80.182.103 with SMTP id c36mr1917714ede.55.1502133153041; Mon, 07 Aug 2017 12:12:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.129 with HTTP; Mon, 7 Aug 2017 12:12:12 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2129@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Aug 2017 21:12:12 +0200 Message-ID: To: Taylor Brandstetter Cc: Christer Holmberg , "rtcweb@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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: Mon, 07 Aug 2017 19:12:36 -0000 Good catch. On Mon, Aug 7, 2017 at 8:21 PM, Taylor Brandstetter w= rote: > Christer and I are in agreement. He's just saying "there should be a MUST > NOT in the spec." > > And there is: > >> Identifiers values in the valid range MUST NOT be altered (remapped). > > > > On Mon, Aug 7, 2017 at 11:06 AM, Christer Holmberg > wrote: >> >> Hi, >> >> >> Taylor's explanation makes sense. But, in this case: >> >> >> >> 1) Re-using the same value with a new mapping should be an explicit >> >> MUST NOT >> >> >> >> 2) The re-offer should be rejected >> > >> > Hi Christer, I'm lost. If Taylor's explanation is ok, why 1) and 2)? >> >> Maybe I was unclear :) >> >> Taylor described why re-using a value for a new mapping doesn't work. I >> think that should be explicitly described, and the text should say MUST = NOT >> re-use value for new mapping (hence 1). >> >> Second, IF an offerer still tries to re-use a value for a new mapping, t= he >> text should say that the receiver MUST discard the offer (hence 2). >> >> Regards, >> >> Christer > > --=20 I=C3=B1aki Baz Castillo From nobody Tue Aug 8 12:31:23 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 D8F09132445; Tue, 8 Aug 2017 12:31:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150222067484.12279.1715829344429803452@ietfa.amsl.com> Date: Tue, 08 Aug 2017 12:31:14 -0700 Archived-At: Subject: [rtcweb] Genart last call review of draft-ietf-rtcweb-jsep-21 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: Tue, 08 Aug 2017 19:31:15 -0000 Reviewer: Robert Sparks Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rtcweb-jsep-21 Reviewer: Robert Sparks Review Date: 2017-08-08 IETF LC End Date: 2017-08-11 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready for publication as a Proposed Standard RFC, but with issues that need to be addressed before publishing Major issues: The last paragraph of 5.1 needs more context. Why woudn't you expect the re-offer to fail, given that you already know the peer is using the older profile strings? It's not clear from the email list and proceedings how the document ended up with this particular text. Minor issues: Second paragraph of 3.2, last sentence: at "these parameters or reject them" - "these" and "them" have ambiguous antecedents. It's not clear if you are trying to point to the parameters that don't follow the earlier stated rule, or all parameters. The sentence is complex. Splitting it up and finding a way to avoid the need for the semicolon will likely make it easier to say what you mean. Last paragraph on page 5 - first sentence: at "One way to mitigate this" - "this" has an unclear antecedent. Did you mean "One way to reduce the complexity of the application's responsibilities"? Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please state precisely which fields you mean. Odd edge: The description createAnswer (in 4.1.7) leaves open the possibility that the application could call createAnswer twice (back-to-back with no intervening calls to other APIs) with different values in the options parameter. Is this ok? If not, should there be language that says not to do that somewhere? Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in RFC5764. Assuming that this is only a reference error, then the last sentence seems like a stray. It doesn't seem to be in the right context ("this advertisement" doesn't cast back to the discussion of the two profiles above it, which are both UDP only). Please clarify the sentence, giving it the right context, or remove it. The fourth sentence of the second bullet of section 5.2.1 is confusing. (It starts "It is RECOMMENDED that the ".) RFC3265 requires the initial sess-id high-order bit to be zero. As written, this can be read to say that setting that bit to zero is only RECOMMENDED, and that it's possible to have sess-ids that are something other than 64 bits. You mean to say "Do what 3265 says to do and make the lower 63 bits random". Here's one possible replacement for the sentence: "RFC 3265 requires that the high-order bit of the initial be zero. It is RECOMMENDED that the remaining 63 bits be initially set to a cryptographically random value." The last paragraph of 5.3.1 prohibits the same attributes from generated answers that are prohibited in generated offers. Consider adding text for what to do if an offer shows up from a peer with some of those prohibited attributes. The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription." The first paragraph of section 5.7.1 is simply restating requirements from RFC4566. Restating normative requirements like that has led to interop problems through unintended introduced ambiguity and spec maintenance problems. Please consider rewriting the paragraph to say "RFC4566 says" and avoid the 2119 keywords. On page 69, at "If the application attempt to transmit DTMF when using a media format that does not have a corresponding telephone-event format, this MUST result in an error". This sentence is out-of-place. The section is about applying a remote description. If the document needs to retain the sentence, it belongs off in some "processing media" section. In particular, the current placement of text is confusing about what and when an error could be returned, and it could be misread to say that an error should be returned to the setRemoteDescription call. Nits: Section 1.2 second paragraph - "This was rejected based on a feeling". Can you write something that speaks to consensus here? "Based on a feeling" isn't quite right. Maybe "using the argument"? PeerConnection is used first at the next to last paragraph of section 3. Please add a reference at that point. "LS" (lipsync) is first used at 4.1.2, with no context for what it is. Please add a reference. The concept of a "pending local description" is used in sections 3.5.1, 4.1.6, and 4.1.7 but isn't really explained until much later in the document. Please provide forward references, or move a description of what a pending description is earlier in the document. In 4.1.7 (create Answer) why would calling setLocalDescription cause the answer to be a _pending_ local description. I think it's the full on local description at that point, not a pending one? At 4.1.17's first paragraph: Why is "if parsed successfully" necessary to call out? I suggest removing the phrase. 4.2.3 talks about setting direction properties, but the values that can be set aren't called out (and even then only by inference from a list in an example) in section 4.2.5. Should there be explicit pointers to the api doc here? (And in section 4.2.6?) There are two paragraphs on page 50 that start "The next step is to". They are both referring to the same step. I suggest combining the paragraphs. The 4th bullet on page 64 is ambiguous at "this m= section". It looks like this bullet should just be merged with the previous bullet. The second paragraph of 6.8 starts "Next, ". I think it should start "First, ". It's not clear what the "Or," in the first bullet on page 65 is referring to. Are you trying to say "If the m= section is not new, and the ICE ufrag and password values have changed" or something else? In the last paragraph of section 8 at "programmer MUST recognize". That is not an appropriate use of 2119. I suggest "needs to be aware" instead of "MUST recognize". Micro Nits: Suggested change to the first sentence of 1.1 OLD: The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible. New: WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible. The first full bullet on page 18 has a sentence that starts "Note that when considering". Please change that to simply "When considering". As written, there is an implication that this is a consequence of something specified somewhere else. The verb "surfaced" appears three times in the document without support or definition. Can you replace them with simpler language? At the second to last sub-bullet at the end of page 66, please remove "note that". The sentence is stronger without it. I noted these sections as particularly hard to read when going through the document linearly. I don't have concrete suggestions for improvement, but perhaps other eyes (if they agree the sections could use improvement) can come up with something: - First sentence of the first paragraph on page 19. - 2nd sentence of the 4th paragraph on page 19. From nobody Tue Aug 8 22:28: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 CE2BE131DB6 for ; Tue, 8 Aug 2017 22:28:00 -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 v7WvMWTIXk_S for ; Tue, 8 Aug 2017 22:27:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE394131DA2 for ; Tue, 8 Aug 2017 22:27:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSZ95389; Wed, 09 Aug 2017 05:27:56 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 06:27:54 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Wed, 9 Aug 2017 13:27:42 +0800 From: Roni Even To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Taylor Brandstetter CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4Zj8vALVZ8/QUigCkZaEYc2vqJ4aKkAgAACMwCAADoWAIAAAq8AgAABqACAAtfNUA== Date: Wed, 9 Aug 2017 05:27:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7F1F02@DGGEMM506-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.598A9D5C.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: df59ab82d8b2f00f103ccea64c6b2d4e Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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, 09 Aug 2017 05:28:01 -0000 SGksDQpJbmxpbmUNClJvbmkgRXZlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2hyaXN0ZXINCj4gSG9sbWJlcmcNCj4gU2VudDog15nXldedwqDXkSAwNyDXkNeV15LXldeh 15ggMjAxNyAyMTowMg0KPiBUbzogScOxYWtpIEJheiBDYXN0aWxsbzsgVGF5bG9yIEJyYW5kc3Rl dHRlcg0KPiBDYzogcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXBs YWNpbmcgYT1leHRtYXAgbWFwcGluZyBpbiByZS1vZmZlciwgaXMgaXQgbGVnYWw/DQo+IA0KPiBI aSwNCj4gDQo+IFRheWxvcidzIGV4cGxhbmF0aW9uIG1ha2VzIHNlbnNlLiBCdXQsIGluIHRoaXMg Y2FzZToNCj4gDQo+IDEpIFJlLXVzaW5nIHRoZSBzYW1lIHZhbHVlIHdpdGggYSBuZXcgbWFwcGlu ZyBzaG91bGQgYmUgYW4gZXhwbGljaXQgTVVTVA0KPiBOT1QNCltSb25pIEV2ZW5dIFRoaXMgaXMg c3BlY2lmaWVkIGluIFJGQzUyODUgc2VjdGlvbiA2IA0KDQpJZGVudGlmaWVycyB2YWx1ZXMgaW4g dGhlIHZhbGlkIHJhbmdlIE1VU1QgTk9UICBiZSBhbHRlcmVkIChyZW1hcHBlZCkuDQoNCj4gDQo+ IDIpIFRoZSByZS1vZmZlciBzaG91bGQgYmUgcmVqZWN0ZWQNCj4gDQo+IFJlZ2FyZHMsDQo+IA0K PiBDaHJpc3Rlcg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogScOx YWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+IFNlbnQ6IDA3IEF1Z3Vz dCAyMDE3IDE5OjU2DQo+IFRvOiBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUu Y29tPg0KPiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT47IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVwbGFjaW5n IGE9ZXh0bWFwIG1hcHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2FsPw0KPiANCj4gT24gTW9u LCBBdWcgNywgMjAxNyBhdCA3OjQ2IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyDQo+IDxkZWFkYmVl ZkBnb29nbGUuY29tPiB3cm90ZToNCj4gPiBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBzdGF0ZWQg ZXhwbGljaXRseSBhbnl3aGVyZSwgYnV0IG15IGFzc3VtcHRpb24NCj4gPiB3YXMgdGhhdCBpdCB3 b3JrcyBsaWtlIHBheWxvYWQgdHlwZXMuIFlvdSBjYW4gaW50cm9kdWNlIG5ldyBJRHMgYWxsDQo+ ID4geW91IHdhbnQsIGJ1dCB5b3UgY2FuJ3QgaGF2ZSBvbmUgSUQgcmVmZXIgdG8gbXVsdGlwbGUg dGhpbmdzIGR1cmluZyB0aGUNCj4gc2FtZSBzZXNzaW9uLg0KPiA+IE90aGVyd2lzZSwgaWYgeW91 IHJlY2VpdmUgYSBwYWNrZXQgd2l0aCB0aGF0IGV4dGVuc2lvbiBJRCwgeW91DQo+ID4gd291bGRu J3QgYmUgYWJsZSB0byB0ZWxsIHdoaWNoIGV4dGVuc2lvbiBpdCBpcy4NCj4gPg0KPiA+IE1lYW5p bmcsIGlmIEJvYidzIGluaXRpYWwgYW5zd2VyIHdhczoNCj4gPg0KPiA+IGE9ZXh0bWFwOjExIGh0 dHA6Ly93d3cud2VicnRjLm9yZy9leHBlcmltZW50cy9ydHAtaGRyZXh0L2Ficy1zZW5kLQ0KPiB0 aW1lDQo+ID4NCj4gPiBJdCB3b3VsZCBiZSBpbGxlZ2FsIHRvIGhhdmUgYSByZS1vZmZlciBvZjoN Cj4gPg0KPiA+IGE9ZXh0bWFwOjEgaHR0cDovL3d3dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0 cC1oZHJleHQvYWJzLXNlbmQtDQo+IHRpbWUNCj4gPiBhPWV4dG1hcDoxMSB1cm46aWV0ZjpwYXJh bXM6cnRwLWhkcmV4dDp0b2Zmc2V0DQo+ID4NCj4gPiBCZWNhdXNlIGlmIEJvYiB0aGVuIHJlY2Vp dmVzIGEgcGFja2V0IHdpdGggZXh0ZW5zaW9uIElEIDExLCBCb2INCj4gPiBkb2Vzbid0IGtub3cg aWYgaXQncyBhIHBhY2tldCBzZW50IGJlZm9yZSBBbGljZSByZWNlaXZlZCB0aGUgYW5zd2VyDQo+ ID4gKGluIHdoaWNoIGNhc2UgaXQncyAiYWJzLXNlbmQtdGltZSIpLCBvciBhZnRlciAoaW4gd2hp Y2ggY2FzZSBpdCdzICJ0b2Zmc2V0IikuDQo+IA0KPiBUaGFua3MsIHlvdXIgcmF0aW9uYWxlIGNs ZWFybHkgbWFrZXMgc2Vuc2UuIEhvd2V2ZXI6DQo+IA0KPiAxKSBJIGRvbid0IHRoaW5rIEZpcmVm b3ggY2FyZXMgYWJvdXQgb3ZlcnJpZGluZyBhIHByZXZpb3VzIGV4dG1hcCBJRCBkdXJpbmcgYQ0K PiByZW9mZmVyLg0KPiANCj4gMikgU2hvdWxkIHdlIHJlYWxseSBhY2NlcHQgc28gY29tcGxleCBh bmQgZXJyb3IgcHJ1bmUgdGhpbmdzIGp1c3QgYmVjYXVzZQ0KPiBTRFAgYWxsb3dzIGV2ZXJ5dGhp bmc/DQo+IA0KPiANCj4gLS0NCj4gScOxYWtpIEJheiBDYXN0aWxsbw0KPiA8aWJjQGFsaWF4Lm5l dD4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g cnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Wed Aug 9 05:26:48 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 5EB05132394 for ; Wed, 9 Aug 2017 05:26:46 -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 0hm9EqvQb8vi for ; Wed, 9 Aug 2017 05:26:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 D6BF51321E3 for ; Wed, 9 Aug 2017 05:26:43 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-df-598aff811b6b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.B8.06959.18FFA895; Wed, 9 Aug 2017 14:26:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Wed, 9 Aug 2017 14:26:41 +0200 From: Christer Holmberg To: Roni Even , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Taylor Brandstetter CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAADoWAIAAAq8AgAAizfCAAjDagIAAlitg Date: Wed, 9 Aug 2017 12:26:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB5B07@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> <6E58094ECC8D8344914996DAD28F1CCD7F1F02@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7F1F02@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdWLfpf1ekwd8HHBaXVzxktZi+z8bi 07HzLBZr/7WzO7B4nGt4z+6xYFOpR8uRt6weS5b8ZApgieKySUnNySxLLdK3S+DKuLngHHvB K4mKlrYjzA2MMyS6GDk5JARMJA5dfsnexcjFISRwhFFi2qcVLCAJIYFFjBKzfjB2MXJwsAlY SHT/0wapERHoZpTYNO8FWA2zgLrEncXn2EFsYQEviTvL5zKD2CIC3hJ/Zs1nhLCjJPbd6GUD sVkEVCS+H9oEFucV8JX49PURC8Ti78wSm7bOZAJJcAqESByZvpMVxGYUEJP4fmoNE8QycYlb T+YzQVwtILFkz3lmCFtU4uXjf6wQtpLE2sPbWUCOZhbQlFi/Sx+iVVFiSvdDdoi9ghInZz5h mcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAkHdzy22oH 48HnjocYBTgYlXh46190RQqxJpYVV+YeYpTgYFYS4c3+BxTiTUmsrEotyo8vKs1JLT7EKM3B oiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBkX1JzmShhu63GnUhVWfk/J4V/1i6sGieb43Q ww8XzwVfWSrHuGfCq8upqzZd9gtgdAhRVPv+4HOlxb/sg2tVeyMCaow+XVa3m7BdqaTG+O01 h99LytlNzeR+vue+ydT4YdMC5tIdb1rf9CWaiy/2edOiyC81qWaXyzTmgtZY/w+NzyUvvd8b rMRSnJFoqMVcVJwIANJMCCugAgAA Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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, 09 Aug 2017 12:26:46 -0000 SGksDQoNCj4+IFRheWxvcidzIGV4cGxhbmF0aW9uIG1ha2VzIHNlbnNlLiBCdXQsIGluIHRoaXMg Y2FzZToNCj4+IA0KPj4gMSkgUmUtdXNpbmcgdGhlIHNhbWUgdmFsdWUgd2l0aCBhIG5ldyBtYXBw aW5nIHNob3VsZCBiZSBhbiBleHBsaWNpdCANCj4+IE1VU1QgTk9UDQo+W1JvbmkgRXZlbl0gVGhp cyBpcyBzcGVjaWZpZWQgaW4gUkZDNTI4NSBzZWN0aW9uIDYgDQo+DQo+SWRlbnRpZmllcnMgdmFs dWVzIGluIHRoZSB2YWxpZCByYW5nZSBNVVNUIE5PVCAgYmUgYWx0ZXJlZCAocmVtYXBwZWQpLg0K DQpDb3JyZWN0LiBUYXlsb3IgaW5kaWNhdGVkIHRoaXMgZWFybGllci4NCg0KV2hhdCBpZiBhIHBy ZXZpb3VzbHkgbmVnb3RpYXRlZCBtYXBwaW5nIGlzIG5vdCBpbmNsdWRlZCBhdCBhbGwgaW4gYSBz dWJzZXF1ZW50IG9mZmVyPyBJcyBpdCBjb25zaWRlcmVkIGFuIGVycm9yPyBJZiBub3QsIGRvZXMg dGhlIHByZXZpb3VzIG1hcHBpbmcgYXBwbHk/IE9yLCBpcyB0aGUgcHJldmlvdXMgbWFwcGluZyBy ZW1vdmVkPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KPiBGcm9tOiBJw7Fha2kgQmF6 IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj4gU2VudDogMDcgQXVndXN0IDIwMTcg MTk6NTYNCj4gVG86IFRheWxvciBCcmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb20+DQo+ IENjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsg DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVwbGFjaW5nIGE9 ZXh0bWFwIG1hcHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2FsPw0KPiANCj4gT24gTW9uLCBB dWcgNywgMjAxNyBhdCA3OjQ2IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIA0KPiA8ZGVhZGJlZWZA Z29vZ2xlLmNvbT4gd3JvdGU6DQo+ID4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgc3RhdGVkIGV4 cGxpY2l0bHkgYW55d2hlcmUsIGJ1dCBteSANCj4gPiBhc3N1bXB0aW9uIHdhcyB0aGF0IGl0IHdv cmtzIGxpa2UgcGF5bG9hZCB0eXBlcy4gWW91IGNhbiBpbnRyb2R1Y2UgDQo+ID4gbmV3IElEcyBh bGwgeW91IHdhbnQsIGJ1dCB5b3UgY2FuJ3QgaGF2ZSBvbmUgSUQgcmVmZXIgdG8gbXVsdGlwbGUg DQo+ID4gdGhpbmdzIGR1cmluZyB0aGUNCj4gc2FtZSBzZXNzaW9uLg0KPiA+IE90aGVyd2lzZSwg aWYgeW91IHJlY2VpdmUgYSBwYWNrZXQgd2l0aCB0aGF0IGV4dGVuc2lvbiBJRCwgeW91IA0KPiA+ IHdvdWxkbid0IGJlIGFibGUgdG8gdGVsbCB3aGljaCBleHRlbnNpb24gaXQgaXMuDQo+ID4NCj4g PiBNZWFuaW5nLCBpZiBCb2IncyBpbml0aWFsIGFuc3dlciB3YXM6DQo+ID4NCj4gPiBhPWV4dG1h cDoxMSBodHRwOi8vd3d3LndlYnJ0Yy5vcmcvZXhwZXJpbWVudHMvcnRwLWhkcmV4dC9hYnMtc2Vu ZC0NCj4gdGltZQ0KPiA+DQo+ID4gSXQgd291bGQgYmUgaWxsZWdhbCB0byBoYXZlIGEgcmUtb2Zm ZXIgb2Y6DQo+ID4NCj4gPiBhPWV4dG1hcDoxIGh0dHA6Ly93d3cud2VicnRjLm9yZy9leHBlcmlt ZW50cy9ydHAtaGRyZXh0L2Ficy1zZW5kLQ0KPiB0aW1lDQo+ID4gYT1leHRtYXA6MTEgdXJuOmll dGY6cGFyYW1zOnJ0cC1oZHJleHQ6dG9mZnNldA0KPiA+DQo+ID4gQmVjYXVzZSBpZiBCb2IgdGhl biByZWNlaXZlcyBhIHBhY2tldCB3aXRoIGV4dGVuc2lvbiBJRCAxMSwgQm9iIA0KPiA+IGRvZXNu J3Qga25vdyBpZiBpdCdzIGEgcGFja2V0IHNlbnQgYmVmb3JlIEFsaWNlIHJlY2VpdmVkIHRoZSBh bnN3ZXIgDQo+ID4gKGluIHdoaWNoIGNhc2UgaXQncyAiYWJzLXNlbmQtdGltZSIpLCBvciBhZnRl ciAoaW4gd2hpY2ggY2FzZSBpdCdzICJ0b2Zmc2V0IikuDQo+IA0KPiBUaGFua3MsIHlvdXIgcmF0 aW9uYWxlIGNsZWFybHkgbWFrZXMgc2Vuc2UuIEhvd2V2ZXI6DQo+IA0KPiAxKSBJIGRvbid0IHRo aW5rIEZpcmVmb3ggY2FyZXMgYWJvdXQgb3ZlcnJpZGluZyBhIHByZXZpb3VzIGV4dG1hcCBJRCAN Cj4gZHVyaW5nIGEgcmVvZmZlci4NCj4gDQo+IDIpIFNob3VsZCB3ZSByZWFsbHkgYWNjZXB0IHNv IGNvbXBsZXggYW5kIGVycm9yIHBydW5lIHRoaW5ncyBqdXN0IA0KPiBiZWNhdXNlIFNEUCBhbGxv d3MgZXZlcnl0aGluZz8NCj4gDQo+IA0KPiAtLQ0KPiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+IDxp YmNAYWxpYXgubmV0Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From nobody Wed Aug 9 06:44: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 5F0111320B5; Wed, 9 Aug 2017 06:43:58 -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 8aLpRjti1599; Wed, 9 Aug 2017 06:43:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F60131EB2; Wed, 9 Aug 2017 06:43:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTA90744; Wed, 09 Aug 2017 13:43:53 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 14:43:51 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 9 Aug 2017 21:43:29 +0800 From: Roni Even To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Taylor Brandstetter CC: "rtcweb@ietf.org" , "avt@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAADoWAIAAAq8AgAAizfCAAjDagIAAlitggAAUltA= Date: Wed, 9 Aug 2017 13:43:29 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7F2006@DGGEMM506-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> <6E58094ECC8D8344914996DAD28F1CCD7F1F02@DGGEMM506-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B4CCB5B07@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB5B07@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.598B1199.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: df59ab82d8b2f00f103ccea64c6b2d4e Archived-At: Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? 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, 09 Aug 2017 13:43:58 -0000 SGkgQ2hyaXN0ZXIsDQpJbmxpbmUsIGNjIGF2dGNvcmUgc2luY2UgaXQgaXMgYXZ0Y29yZSBkb2N1 bWVudCAuDQpMb29rIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2 dGNvcmUtcmZjNTI4NS1iaXMtMTQjc2VjdGlvbi03IA0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiDXmdeV153CoNeTIDA5INeQ15XXkteV16HX mCAyMDE3IDE1OjI3DQo+IFRvOiBSb25pIEV2ZW47IEnDsWFraSBCYXogQ2FzdGlsbG87IFRheWxv ciBCcmFuZHN0ZXR0ZXINCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3J0 Y3dlYl0gUmVwbGFjaW5nIGE9ZXh0bWFwIG1hcHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2Fs Pw0KPiANCj4gSGksDQo+IA0KPiA+PiBUYXlsb3IncyBleHBsYW5hdGlvbiBtYWtlcyBzZW5zZS4g QnV0LCBpbiB0aGlzIGNhc2U6DQo+ID4+DQo+ID4+IDEpIFJlLXVzaW5nIHRoZSBzYW1lIHZhbHVl IHdpdGggYSBuZXcgbWFwcGluZyBzaG91bGQgYmUgYW4gZXhwbGljaXQNCj4gPj4gTVVTVCBOT1QN Cj4gPltSb25pIEV2ZW5dIFRoaXMgaXMgc3BlY2lmaWVkIGluIFJGQzUyODUgc2VjdGlvbiA2DQo+ ID4NCj4gPklkZW50aWZpZXJzIHZhbHVlcyBpbiB0aGUgdmFsaWQgcmFuZ2UgTVVTVCBOT1QgIGJl IGFsdGVyZWQgKHJlbWFwcGVkKS4NCj4gDQo+IENvcnJlY3QuIFRheWxvciBpbmRpY2F0ZWQgdGhp cyBlYXJsaWVyLg0KPiANCj4gV2hhdCBpZiBhIHByZXZpb3VzbHkgbmVnb3RpYXRlZCBtYXBwaW5n IGlzIG5vdCBpbmNsdWRlZCBhdCBhbGwgaW4gYSBzdWJzZXF1ZW50DQo+IG9mZmVyPw0KDQpbUm9u aSBFdmVuXSBJdCBpcyByZW1vdmVkIG5vdCBzdXBwb3J0ZWQgIkEgc2Vzc2lvbiB1cGRhdGUgTUFZ IGFkZCBvciAgcmVtb3ZlIGV4dGVuc2lvbihzKS4iDQoNCiBJcyBpdCBjb25zaWRlcmVkIGFuIGVy cm9yPw0KDQpbUm9uaSBFdmVuXSBubw0KDQogSWYgbm90LCBkb2VzIHRoZSBwcmV2aW91cyBtYXBw aW5nIGFwcGx5PyANCltSb25pIEV2ZW5dIGlmIHlvdSB3YW50IHRvIHVzZSBpdCB5b3UgY2FuIGNv bnNpZGVyIG1ha2luZyBpdCBpbmFjdGl2ZQ0KDQpPciwNCj4gaXMgdGhlIHByZXZpb3VzIG1hcHBp bmcgcmVtb3ZlZD8NCltSb25pIEV2ZW5dIHJlbW92ZWQgYnV0IHlvdSBjYW5ub3QgdXNlIHRoZSBz YW1lIElEIGZvciBhbm90aGVyIGV4dGVuc2lvbg0KDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hy aXN0ZXINCj4gDQo+IA0KPiANCj4gPiBGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86 aWJjQGFsaWF4Lm5ldF0NCj4gPiBTZW50OiAwNyBBdWd1c3QgMjAxNyAxOTo1Ng0KPiA+IFRvOiBU YXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPg0KPiA+IENjOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsNCj4gPiBydGN3ZWJA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVwbGFjaW5nIGE9ZXh0bWFwIG1h cHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2FsPw0KPiA+DQo+ID4gT24gTW9uLCBBdWcgNywg MjAxNyBhdCA3OjQ2IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyDQo+ID4gPGRlYWRiZWVmQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiA+ID4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgc3RhdGVkIGV4cGxp Y2l0bHkgYW55d2hlcmUsIGJ1dCBteQ0KPiA+ID4gYXNzdW1wdGlvbiB3YXMgdGhhdCBpdCB3b3Jr cyBsaWtlIHBheWxvYWQgdHlwZXMuIFlvdSBjYW4gaW50cm9kdWNlDQo+ID4gPiBuZXcgSURzIGFs bCB5b3Ugd2FudCwgYnV0IHlvdSBjYW4ndCBoYXZlIG9uZSBJRCByZWZlciB0byBtdWx0aXBsZQ0K PiA+ID4gdGhpbmdzIGR1cmluZyB0aGUNCj4gPiBzYW1lIHNlc3Npb24uDQo+ID4gPiBPdGhlcndp c2UsIGlmIHlvdSByZWNlaXZlIGEgcGFja2V0IHdpdGggdGhhdCBleHRlbnNpb24gSUQsIHlvdQ0K PiA+ID4gd291bGRuJ3QgYmUgYWJsZSB0byB0ZWxsIHdoaWNoIGV4dGVuc2lvbiBpdCBpcy4NCj4g PiA+DQo+ID4gPiBNZWFuaW5nLCBpZiBCb2IncyBpbml0aWFsIGFuc3dlciB3YXM6DQo+ID4gPg0K PiA+ID4gYT1leHRtYXA6MTEgaHR0cDovL3d3dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0cC1o ZHJleHQvYWJzLQ0KPiBzZW5kLQ0KPiA+IHRpbWUNCj4gPiA+DQo+ID4gPiBJdCB3b3VsZCBiZSBp bGxlZ2FsIHRvIGhhdmUgYSByZS1vZmZlciBvZjoNCj4gPiA+DQo+ID4gPiBhPWV4dG1hcDoxIGh0 dHA6Ly93d3cud2VicnRjLm9yZy9leHBlcmltZW50cy9ydHAtaGRyZXh0L2Ficy1zZW5kLQ0KPiA+ IHRpbWUNCj4gPiA+IGE9ZXh0bWFwOjExIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnRvZmZz ZXQNCj4gPiA+DQo+ID4gPiBCZWNhdXNlIGlmIEJvYiB0aGVuIHJlY2VpdmVzIGEgcGFja2V0IHdp dGggZXh0ZW5zaW9uIElEIDExLCBCb2INCj4gPiA+IGRvZXNuJ3Qga25vdyBpZiBpdCdzIGEgcGFj a2V0IHNlbnQgYmVmb3JlIEFsaWNlIHJlY2VpdmVkIHRoZSBhbnN3ZXINCj4gPiA+IChpbiB3aGlj aCBjYXNlIGl0J3MgImFicy1zZW5kLXRpbWUiKSwgb3IgYWZ0ZXIgKGluIHdoaWNoIGNhc2UgaXQn cyAidG9mZnNldCIpLg0KPiA+DQo+ID4gVGhhbmtzLCB5b3VyIHJhdGlvbmFsZSBjbGVhcmx5IG1h a2VzIHNlbnNlLiBIb3dldmVyOg0KPiA+DQo+ID4gMSkgSSBkb24ndCB0aGluayBGaXJlZm94IGNh cmVzIGFib3V0IG92ZXJyaWRpbmcgYSBwcmV2aW91cyBleHRtYXAgSUQNCj4gPiBkdXJpbmcgYSBy ZW9mZmVyLg0KPiA+DQo+ID4gMikgU2hvdWxkIHdlIHJlYWxseSBhY2NlcHQgc28gY29tcGxleCBh bmQgZXJyb3IgcHJ1bmUgdGhpbmdzIGp1c3QNCj4gPiBiZWNhdXNlIFNEUCBhbGxvd3MgZXZlcnl0 aGluZz8NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+ID4gPGli Y0BhbGlheC5uZXQ+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4gcnRjd2ViQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Thu Aug 10 07:42:16 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 30C191321EB; Thu, 10 Aug 2017 07:42:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-rtcweb-overview@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150237612919.12039.11708014636993516636.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 07:42:09 -0700 Archived-At: Subject: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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: Thu, 10 Aug 2017 14:42:09 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-rtcweb-overview-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- UPDATE: Removing my discuss. Will let Adam manage this from here. This document seems rather long on philosophy (justifying MTI, the freed to innovate material in S 4.) I would remove all this. S 2.4. Why do you have two terminology sections? I would merge them. S 3. The diagrams here seem to assume a federation model that I generally don't see used with WebRTC. So, for instance, the on-the-wire protocols arrow on page 9. Who does that? This also applies to "a commonly imagined model" I would say HTTP(S) in this diagram. You should probably list DTLS, SCTP, and SDP in this section. It's not like we haven't decided we need them. "The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: ... Connection management: ... SIP and Jingle/XMPP belong in this category." As far as I know, nothing in this layer is specified in WebRTC or implemented in the browser, so this doesn't seem to make sense. From nobody Fri Aug 11 09:43:32 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 9049B1321DF for ; Fri, 11 Aug 2017 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ZjdFWhwgcGWU for ; Fri, 11 Aug 2017 09:43:28 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C28941321C9 for ; Fri, 11 Aug 2017 09:43:27 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id p68so25603392ywg.0 for ; Fri, 11 Aug 2017 09:43:27 -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=8WLX4YZNNPtcZSrhP5u35O586h2Ht94zkLQ+B5C22B0=; b=E2WsGUWPF1vqga6UKLJJFXd4T+xIXSZ39/pRz9ylq5Ro681Y4tLIFR3ApMWANoijtH arkhqdQPrJtiETEyNnSe9Q+lljU3xdEP4us0uEcjw+QlDN6CCTsqQY7cQ2JUzYipbA6Q NBDc7nNx1bxzYGvMU9v5hBM4l3pxS5Sj3606y1oONJZLc1+aef3bUPQRq0i6prmAMzsm IM6mUFD0SrJI58/UynYmPzf5SB5O4kn9wo79DUvyYJHYUJcCUtJ2R+M0ZSSyoaskjyGx Nn8ZRq60LB5B/FB4OPhkpu6wyEPRUZoEEZm37mwEbZoDjaYLGe31Pcn3XRlAVFcVhwM+ 7tqA== 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=8WLX4YZNNPtcZSrhP5u35O586h2Ht94zkLQ+B5C22B0=; b=U43nVHeTQCch/oihtNV/UpKpVcwY+dRgTI+Bwk/42lOE7SmxJz/RXB5+PawdQvKI/m 4rvGM/ggvtBqUACjSClA+9iulZ/zCRkTOUEWPbZhDO2g2jQ5GXWhK8Tk8mJ/P+akZjSD BO/fj7STveLlFZhEXv8dxLaNg6juOX5EViFKJSvXGv3iog3Uj/sZDcGJCFLM8TXelHkt kHwbnmuAIHamH/Jb6vR6OSsyjlaDcLqEyfTttPTjn8aJBY4jUah/3LbBkq2GUJPueVq4 FaacIHqOl7vEwOCHSZnvzAgKJQQEUu/d48sOSr9V9HImgcO8M56JZa5dKpRm5Sy5DTm9 Sw3w== X-Gm-Message-State: AHYfb5iJ2+txO+LHzafYcmFTjozTUkjigtYJHXXOR6wbrzUeZ587bjND F+ohybhGFTDa/ZOxpCSM3SnZLncxr1cqxvZ/KA== X-Received: by 10.13.251.3 with SMTP id l3mr13610409ywf.71.1502469806719; Fri, 11 Aug 2017 09:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 09:42:46 -0700 (PDT) From: Eric Rescorla Date: Fri, 11 Aug 2017 09:42:46 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07f0361dc20405567d03ef" Archived-At: Subject: [rtcweb] Revising rollback semantics 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, 11 Aug 2017 16:43:32 -0000 --94eb2c07f0361dc20405567d03ef Content-Type: text/plain; charset="UTF-8" I wanted to make the group aware of the following change that we've made to the semantics of rollback [0]. The basic idea is that rollback always returns you to the stable state regardless of what state you are in and it doesn't matter which of set{Local,Remote}Description you call. This makes life a bit easier for implementations, which may want to handle either remote or local rollbacks in a uniform fashion. Please speak now if you object. -Ekr [0] https://github.com/rtcweb-wg/jsep/commit/6f5dc414265cab8b76b25e5cd381a53bcb9cd5c5 --94eb2c07f0361dc20405567d03ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wanted to make the group aware of the following change t= hat we've made to
the semantics of rollback [0].

The basic idea is that rollback always returns you to the stable sta= te regardless
of what state you are in and it doesn't matter = which of set{Local,Remote}Description you call. This makes life a bit easie= r for implementations, which may want to handle either remote or local roll= backs in a uniform fashion. Please speak now if you object.
 --94eb2c07f0361dc20405567d03ef-- From nobody Wed Aug 16 18:21:57 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 05C1313239D; Wed, 16 Aug 2017 18:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Martinez To: Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150293290297.12432.15822575176336895893@ietfa.amsl.com> Date: Wed, 16 Aug 2017 18:21:43 -0700 Archived-At: Subject: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-jsep-21 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: Thu, 17 Aug 2017 01:21:43 -0000 Reviewer: Carlos Martinez Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Noting that I'm certainly not an expert on the subject matter, I've found this document to be READY. I found it well-written, it contains plenty of detailed examples (which I believe are really important for API and programming-heavy documents), and includes plenty of references as well. Please do not forget to remove "Appendix B. Change log". A minor observation, not even a nit, is that the text in the Security Considerations "While formally the JSEP interface is an API, it is better to think of it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint. " could be more clear. thanks! /Carlos From nobody Thu Aug 17 11:13:32 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 2EADC1324C6 for ; Thu, 17 Aug 2017 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hsJFNuiWBihn for ; Thu, 17 Aug 2017 11:13:24 -0700 (PDT) Received: from smtp73.ord1d.emailsrvr.com (smtp73.ord1d.emailsrvr.com [184.106.54.73]) (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 DA81C12426E for ; Thu, 17 Aug 2017 11:13:23 -0700 (PDT) Received: from smtp2.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 2CB7340060; Thu, 17 Aug 2017 14:13:23 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp2.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 52D8340079; Thu, 17 Aug 2017 14:13:22 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.20.10.2] ([UNAVAILABLE]. [209.52.88.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Thu, 17 Aug 2017 14:13:23 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_23BD1A4B-47A4-4F53-B179-843B5C9BAAE3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <150293290297.12432.15822575176336895893@ietfa.amsl.com> Date: Thu, 17 Aug 2017 11:13:20 -0700 Cc: ops-dir@ietf.org, draft-ietf-rtcweb-jsep.all@ietf.org, RTCWeb IETF , ietf@ietf.org Message-Id: <65A7933F-39BC-4E21-B5D2-9F9BB61B7ED7@iii.ca> References: <150293290297.12432.15822575176336895893@ietfa.amsl.com> To: Carlos Martinez X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Opsdir last call review of 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, 17 Aug 2017 18:13:26 -0000 --Apple-Mail=_23BD1A4B-47A4-4F53-B179-843B5C9BAAE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 16, 2017, at 6:21 PM, Carlos Martinez = wrote: >=20 > Reviewer: Carlos Martinez > Review result: Ready >=20 > I have reviewed this document as part of the Operational directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written with the intent of improving the operational = aspects of > the IETF drafts. Comments that are not addressed in last call may be = included > in AD reviews during the IESG review. Document editors and WG chairs = should > treat these comments just like any other last call comments. >=20 > Noting that I'm certainly not an expert on the subject matter, I've = found this > document to be READY. I found it well-written, it contains plenty of = detailed > examples (which I believe are really important for API and = programming-heavy > documents), and includes plenty of references as well. >=20 > Please do not forget to remove "Appendix B. Change log". >=20 > A minor observation, not even a nit, is that the text in the Security > Considerations "While formally the JSEP interface is an API, it is = better to > think of it is an Internet protocol, with the JS being untrustworthy = from the > perspective of the endpoint. " could be more clear. >=20 > thanks! >=20 > /Carlos >=20 Thanks Carlos, I'll have a look at the things you mention ( = https://github.com/rtcweb-wg/jsep/issues/791 = and = https://github.com/rtcweb-wg/jsep/issues/792 = for tracking ) --Apple-Mail=_23BD1A4B-47A4-4F53-B179-843B5C9BAAE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 16, 2017, at 6:21 PM, Carlos Martinez <carlosm3011@gmail.com> wrote:

Reviewer: Carlos Martinez
Review result: = Ready

I have reviewed this document as part = of the Operational directorate's ongoing
effort to review = all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the = operational aspects of
the IETF drafts. Comments that are = not addressed in last call may be included
in AD reviews = during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call = comments.

Noting that I'm certainly not an = expert on the subject matter, I've found this
document to = be READY. I found it well-written, it contains plenty of detailed
examples (which I believe are really important for API and = programming-heavy
documents), and includes plenty of = references as well.

Please do not forget to = remove "Appendix B.  Change log".

A = minor observation, not even a nit, is that the text in the Security
Considerations "While formally the JSEP interface is an API, = it is better to
think of it is an Internet protocol, with = the JS being untrustworthy from the
perspective of the = endpoint. " could be more clear.

thanks!

/Carlos



Thanks Carlos, I'll have = a look at the things you mention ( https://github.com/rtcweb-wg/jsep/issues/791 and = https://github.com/rtcweb-wg/jsep/issues/792 for = tracking )

= --Apple-Mail=_23BD1A4B-47A4-4F53-B179-843B5C9BAAE3-- From bcampen@mozilla.com Wed Aug 23 12:33:45 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 39354132C7A for ; Wed, 23 Aug 2017 12:33:45 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 WUiOP4MQ-j3N for ; Wed, 23 Aug 2017 12:33:42 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 49D72132C61 for ; Wed, 23 Aug 2017 12:33:42 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f11so11195174oic.0 for ; Wed, 23 Aug 2017 12:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=osNgYKr3k9hilRVRY8T1MEWdEglvXwfbT4MQppkCRmU=; b=TMSPoFMOFXXq7NrnGZA1S6t8i6AjxP5rDRQUuT96uakAqcqqh9UWhwj8vUQaEh/ymD GdqyNKfIi6ADXJ3KJ6UHI+BH8Dp+l7BE/Dc6dX4ld2pL1yfBMWe/y29UwsDKHifkbOrl XKRWBvm31mVW0AVwaeiLAlvNTGyfMCyj/YLW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=osNgYKr3k9hilRVRY8T1MEWdEglvXwfbT4MQppkCRmU=; b=BAoVa5fNfo0YKQrNU46Jlp30qw5XkZs7kaA0yyA4DD3CvFd8Pw3gUT5lwFrt9tOZgn wR6ya6VwHHC+57TXUqzj+hXz9Cc1d6ckkh48FVolVVj3/NXzIiFGACS72XemWL6KvBgi mPS2C7BOhOF7TiA/JddGRmSmQfa5UEFadDXa3Y20GJTA017tgI9Mkln75xPynq4jJ7TH xCLTlmyIGuCpRiOzt6QUI3pa98oNQWuxYk2HLihp/yyD6YDIRlX8PpCdHmONRjHaB8nA Xzly+FjgVAvOLgGNmnqB+72tkpFGxLU1UDsrQMQn8Y7VCnBlsTV/4SJfWz6uZGxMZKxC EwkQ== X-Gm-Message-State: AHYfb5jpoFDJR/ln+rol8CX1gs83P3cgN3uuhQOMV//VgZsktJZK7hf3 03Xj+AElA+pUtR0es+8Oqw== X-Received: by 10.202.79.6 with SMTP id d6mr2245303oib.6.1503516821186; Wed, 23 Aug 2017 12:33:41 -0700 (PDT) Received: from bcampen-19607.local ([2600:1700:24d0:8760:2de5:b158:ed63:a450]) by smtp.googlemail.com with ESMTPSA id t200sm2399749oih.54.2017.08.23.12.33.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 12:33:40 -0700 (PDT) To: rtcweb@ietf.org From: Byron Campen Message-ID: <2dc1c6d8-daa1-5b4d-d5b4-c7b3ad434182@mozilla.com> Date: Wed, 23 Aug 2017 14:33:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 23 Aug 2017 19:34:40 -0000 A corner-case came up over at https://bugzilla.mozilla.org/show_bug.cgi?id=1384265. This corner-case, in brief, happens when a webrtc service is deployed entirely on a VPN, but does not call gUM, forcing mode 2 to be used. In this case, only the default route is gathered, which prevents connections to endpoints on the VPN (TURN server, or SFU, or other browsers), even though the browser has already exposed its VPN address by connecting to the origin. It seems reasonable to gather/trickle the interface that was used to connect to the origin, since that IP address has already been disclosed. We might also elect to continue exposing the default route, since if the webrtc service on the VPN is doing something nefarious, it is going to be able to learn the default route by colluding with a server out on the Internet. Thoughts? Best regards, Byron Campen From james@jamesandjo.com Wed Aug 23 14:06:19 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 CD2FD1329E6 for ; Wed, 23 Aug 2017 14:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-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 M3kKzoDY2jWt for ; Wed, 23 Aug 2017 14:06:18 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 C27711326F7 for ; Wed, 23 Aug 2017 14:06:12 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id l19so7404650wmi.1 for ; Wed, 23 Aug 2017 14:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=subject:from:message-id:date:to:content-transfer-encoding :mime-version; bh=8ymbrUiEGrEKX4KTNIYQ7XwSWKFB6IKa2m/416DwcMY=; b=n1N028mkjgviVXek5DlvQcdL2VItGPlBJ2vMp/XquiuXT2mjytSxo/SR44r5CC92B9 nLg1r3pIB/9bbkEY9dXAU/5lByWVzV2LLKnLCObFWlTPcnFeiVJLjlVod9Lna5cOP/oV hitzEahJLbC44EJmHrnwjmeJJ8dBwz6W3xfn2YffQZoLJf9tiNl49pBXjhSwfjXfuO8A zyVDbEmZWqstVr6uwscnmXPTJKuydYT+JieX3Eh/0G5lJoQcaUSQKj/vqWcINWPG3Do8 ssVcjRnBTDkXJCssT1u6IEeLipJZd5urA0oydOsBUS0CeAM75S6V5QyDo9OpKAIB4NCS P/6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:message-id:date:to :content-transfer-encoding:mime-version; bh=8ymbrUiEGrEKX4KTNIYQ7XwSWKFB6IKa2m/416DwcMY=; b=W0JKP65+oVMoIZAsOTIOdHLN/sn3+RbGoCKcBFyY3Mr6CVPTLCco0Lkthz5Wy9Uz46 cmwCpnZ3GsGoznLYYHUOnNpuglPSaD8fcx3FlnTHq3xFblthNlpY2dvILNnk3toUtOpx tqoczaoXeoGQ5wjscK6a44V8jZOYspT0TyorX4nZL4PP1De3lbfOL5VOxl5cuVGGRM0U ZLO5ALWG8zQ83yLmwXVSJBizd9OrWo7Ky1zQ3Hl4AmKdnY24bjrNEGMeBh6mLqV5gH5p aIA9dca/JyLTV83s2+9h8mqhXUo23eHbyEZdv2DLx+Aq4N6MvHOiL0H63h2N8TdM73/6 FZ4A== X-Gm-Message-State: AHYfb5hyCjyMCKGbfwXb5jnDrQSm1zMBbEyzPoNHk973jtLITTDLCGNw S8fyPGlcfcbSYsYGKWQ6TQ== X-Received: by 10.28.98.66 with SMTP id w63mr2463535wmb.34.1503522370986; Wed, 23 Aug 2017 14:06:10 -0700 (PDT) Received: from [192.168.0.13] (cpc3-wilm2-2-0-cust931.1-4.cable.virginm.net. [81.96.107.164]) by smtp.gmail.com with ESMTPSA id 9sm3728443wmo.35.2017.08.23.14.06.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 14:06:10 -0700 (PDT) From: James Pearce Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (14G60) Message-Id: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> Date: Wed, 23 Aug 2017 22:06:08 +0100 To: rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 23 Aug 2017 21:07:53 -0000 Please forgive me if I abused the process in any way - this is my first cont= ribution to a mailing list such as this. I am the submitter of the original Mozilla bug identifying this corner case m= entioned by Byron. (I hesitate to call it as such because the impact has bee= n significant to our particular WebRTC use case). I'd like to attempt to mak= e my case... I think there are both usability and privacy issues that need to be consider= ed here.=20 In my particular case, the remote peer is on a VPN. The VPN is not installed= as the default route (common for corporate and organisational VPNs). Only t= he remote peer is supplying media. This might seem an unusual setup, but I t= hink this kind of use will grow as the benefits of very-low latency media st= reaming become more important. With no media to contribute, the local peer n= ever calls gUM. As both peers are on a VPN, and gUM is never called, the con= nection fails outright, since the connection falls back to mode 2, but the V= PN is not the default route - there is no opportunity to ever obtain user pe= rmission. Perhaps more importantly there is a privacy concern as well. As I understand= it, the purpose of mode 2 is to prevent drive-by enumerations of addresses o= f alternative routes that should remain private. The assumption seems to be t= hat the address of the default route is safe to reveal. However, where the o= rigin came via a non-default route, it seems like an unsafe assumption. As a= contrived example, if I'm a corporate whistleblower, I don't want the exter= nal address of my default route revealed to my employer when I'm using my co= rporate VPN. However as the spec is currently worded, it allows just that. The obvious solution seems to be to change the behaviour of mode 2. Rather t= han using the default route in all cases, we should use the route that was u= sed to fetch the origin. This seems to resolve both the usability and privac= y concerns without reducing existing security. Thanks for listening, James= From nobody Wed Aug 23 15:36:14 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 ADBB41329F9 for ; Wed, 23 Aug 2017 15:36:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tb7VJ1VEq0Pg for ; Wed, 23 Aug 2017 15:36:08 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 C1050132A4E for ; Wed, 23 Aug 2017 15:36:05 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a70so2725898wmd.1 for ; Wed, 23 Aug 2017 15:36: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=GuJZxsaScYY2ecFYC+D2gDXEn5AoV79VNNG8KoBra9g=; b=RkkLXnvaF3Hmn3TGe455n11QFoZx3zEa+ZIg1rgCWKUVKmQAFiZWRifmL1M2PjsNQy tlvpXJP+ZP5HkDiqM053k8mnmXWabt/2iwxYxxQ4p/KMpdROG9u/Yw/zYe3GheM/nxPM B8IZw4/oA88F6A1Vn74E46xHFa4SMMZKBdRn5fYWTqIU4Grq4qGXCIU/WJMTmvyvL7Vv m+Qp5f3023RG3JwZLAOfRPj1gb535v1FmnZipQHG2Vm5wX01uPCtZT7H6X+/ueLLJ/1R PY6gPcYSIYYe5foaTMK78cx1c9kDy/juNUK7NQL/TJdg5ILn5psWNbKjBGK1JCEEffKw vFdA== 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=GuJZxsaScYY2ecFYC+D2gDXEn5AoV79VNNG8KoBra9g=; b=KWHNJWQ3o6Ly50Z6oRuviiq9TK83L/vwT6MRIbVbOMs4i5a+ETHGvcwzcDu0eUYgwL y9FpFRDUOI3T2x4y7u4JfZkO+LgEpevkWTG+a+fHy9BVK72hFwcOJCXuXqKussP7g2pr /ReAO8xHcTfiePkxkGV5/ekvnQafEnwPH0KJouK5kVLzho0sYR+qIALWtbx1NL/PMVxi nFNbSk4i1irNBaKc2j0iBTOQVQM1wIbsv79tGdREsZJe7gGV9l0+YGp8jqrQWATzpK/t CugYcnyTFTK0CjTqIUhcrqgqDzgr2VPdqJAXBXY3QBuQ6Un1jidfih407FK7HSgN8I+w La3g== X-Gm-Message-State: AHYfb5g36WADgf8wRGJ8ko20COb3Co2yAe3Pq+LKtm7f/rStAwt0zhlY xgsDkbZxZ+CW0KDGAXWYKmNTFI3s+r6g X-Google-Smtp-Source: ADKCNb6T/rMWIIjnILxBcUB8bvtDd3SuJ5t7pA6oinal73pTJes0Feo0p1dFJtGUs4niqsDlyoNRNFDcBDz3TJt3md4= X-Received: by 10.28.16.133 with SMTP id 127mr2271980wmq.75.1503527764180; Wed, 23 Aug 2017 15:36:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.130.229 with HTTP; Wed, 23 Aug 2017 15:36:03 -0700 (PDT) In-Reply-To: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> From: Taylor Brandstetter Date: Wed, 23 Aug 2017 15:36:03 -0700 Message-ID: To: James Pearce , Justin Uberti Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1146d9504b99270557735601" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 23 Aug 2017 22:36:13 -0000 --001a1146d9504b99270557735601 Content-Type: text/plain; charset="UTF-8" I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition. Justin, do you recall if this has been brought up before? Do you have any opinions? On Wed, Aug 23, 2017 at 2:06 PM, James Pearce wrote: > Please forgive me if I abused the process in any way - this is my first > contribution to a mailing list such as this. > > I am the submitter of the original Mozilla bug identifying this corner > case mentioned by Byron. (I hesitate to call it as such because the impact > has been significant to our particular WebRTC use case). I'd like to > attempt to make my case... > > I think there are both usability and privacy issues that need to be > considered here. > > In my particular case, the remote peer is on a VPN. The VPN is not > installed as the default route (common for corporate and organisational > VPNs). Only the remote peer is supplying media. This might seem an unusual > setup, but I think this kind of use will grow as the benefits of very-low > latency media streaming become more important. With no media to contribute, > the local peer never calls gUM. As both peers are on a VPN, and gUM is > never called, the connection fails outright, since the connection falls > back to mode 2, but the VPN is not the default route - there is no > opportunity to ever obtain user permission. > > Perhaps more importantly there is a privacy concern as well. As I > understand it, the purpose of mode 2 is to prevent drive-by enumerations of > addresses of alternative routes that should remain private. The assumption > seems to be that the address of the default route is safe to reveal. > However, where the origin came via a non-default route, it seems like an > unsafe assumption. As a contrived example, if I'm a corporate > whistleblower, I don't want the external address of my default route > revealed to my employer when I'm using my corporate VPN. However as the > spec is currently worded, it allows just that. > > The obvious solution seems to be to change the behaviour of mode 2. Rather > than using the default route in all cases, we should use the route that was > used to fetch the origin. This seems to resolve both the usability and > privacy concerns without reducing existing security. > > Thanks for listening, > > James > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1146d9504b99270557735601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. This would be co= nsistent with the spirit of the guidelines: "don't reveal any more= IP addresses than have already been revealed." This may have even bee= n the intent from the start; there's just not a clear definition for &q= uot;default route". "Default route used to fetch the origin"= seems like a reasonable definition.

Justin, do you= recall if this has been brought up before? Do you have any opinions?

On W= ed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com>= wrote:
Please forgive me if I abu= sed the process in any way - this is my first contribution to a mailing lis= t such as this.

I am the submitter of the original Mozilla bug identifying this corner case= mentioned by Byron. (I hesitate to call it as such because the impact has = been significant to our particular WebRTC use case). I'd like to attemp= t to make my case...

I think there are both usability and privacy issues that need to be conside= red here.

In my particular case, the remote peer is on a VPN. The VPN is not installe= d as the default route (common for corporate and organisational VPNs). Only= the remote peer is supplying media. This might seem an unusual setup, but = I think this kind of use will grow as the benefits of very-low latency medi= a streaming become more important. With no media to contribute, the local p= eer never calls gUM. As both peers are on a VPN, and gUM is never called, t= he connection fails outright, since the connection falls back to mode 2, bu= t the VPN is not the default route - there is no opportunity to ever obtain= user permission.

Perhaps more importantly there is a privacy concern as well. As I understan= d it, the purpose of mode 2 is to prevent drive-by enumerations of addresse= s of alternative routes that should remain private. The assumption seems to= be that the address of the default route is safe to reveal. However, where= the origin came via a non-default route, it seems like an unsafe assumptio= n. As a contrived example, if I'm a corporate whistleblower, I don'= t want the external address of my default route revealed to my employer whe= n I'm using my corporate VPN. However as the spec is currently worded, = it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather = than using the default route in all cases, we should use the route that was= used to fetch the origin. This seems to resolve both the usability and pri= vacy concerns without reducing existing security.

Thanks for listening,

James
______________________________= _________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a1146d9504b99270557735601-- From nobody Wed Aug 23 17:08: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 16B44132A91 for ; Wed, 23 Aug 2017 17:08:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 VE089ZcoFdnu for ; Wed, 23 Aug 2017 17:08:23 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 A29661320BB for ; Wed, 23 Aug 2017 17:08:23 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id j144so16490355oib.1 for ; Wed, 23 Aug 2017 17:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=W3mKfl4ROUtLnh6AWpzpEnVsEZZ6IszTthoxSqYOE9s=; b=OHYrjCfOmbYiyAB+QRT+RYL1Re/5wybKMnrTe+wkJLwvnI3oOpCHoFgh3gd6xuoyoA vDD4ahesRgh6ZNVTP8pH/lu8RtXSDLionkkVXCTSQgd8inVnuH21j+UzjNL5g6Lnt+8i yxflCabvhVrpNS3mwXpsqtLlevZ5b2Jo5Thi8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=W3mKfl4ROUtLnh6AWpzpEnVsEZZ6IszTthoxSqYOE9s=; b=tUej7dEBO2hk0hh+Il7MDRx4Z8p4uO6tvGX76W3crf0r0anseb/hieCDPw0HoPgtkF Cp9powzmzFwLOpW5G8BzMYtOdjNhibRvbNeuH1DpDDvrM4KNf1MtNsGWznyddaIwDgtP VbGbVJnKf3K98TU44XQG7i6kcHyCdz41CWzdEf+/8XMlV8US6Xz6Y4ej/f86lgdq34wl 68t7MftbFze0LYyrXm7Hrjk/vbOYpTchkwzf8zUTWrOgZuMSd4P2HBnwcJLsKh7orsfh v8WyX0aU1CrWPqyQUSi8XxYsdKjo9WIizsqoPmK0AnW/80yf8cpEiIUnkPGb52oUgO3E q01g== X-Gm-Message-State: AHYfb5ioG25IE9bku1RRXuDy1vP7vS2vCvSc3P6RApbGQC81TuESdVUa l/EcKggvlsyKX9nKzdIjhQ== X-Received: by 10.202.10.215 with SMTP id k84mr6094752oiy.67.1503533302491; Wed, 23 Aug 2017 17:08:22 -0700 (PDT) Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id t200sm2946902oih.54.2017.08.23.17.08.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 17:08:21 -0700 (PDT) To: Taylor Brandstetter , James Pearce , Justin Uberti Cc: RTCWeb IETF References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> From: Byron Campen Message-ID: <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> Date: Wed, 23 Aug 2017 19:08:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------14A7DB38E29823ECF3E4851D" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 00:08:28 -0000 This is a multi-part message in MIME format. --------------14A7DB38E29823ECF3E4851D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2. Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode? Best regards, Byron Campen On 8/23/17 5:36 PM, Taylor Brandstetter wrote: > I agree. This would be consistent with the spirit of the guidelines: > "don't reveal any more IP addresses than have already been revealed." > This may have even been the intent from the start; there's just not a > clear definition for "default route". "Default route used to fetch the > origin" seems like a reasonable definition. > > Justin, do you recall if this has been brought up before? Do you have > any opinions? > > On Wed, Aug 23, 2017 at 2:06 PM, James Pearce > wrote: > > Please forgive me if I abused the process in any way - this is my > first contribution to a mailing list such as this. > > I am the submitter of the original Mozilla bug identifying this > corner case mentioned by Byron. (I hesitate to call it as such > because the impact has been significant to our particular WebRTC > use case). I'd like to attempt to make my case... > > I think there are both usability and privacy issues that need to > be considered here. > > In my particular case, the remote peer is on a VPN. The VPN is not > installed as the default route (common for corporate and > organisational VPNs). Only the remote peer is supplying media. > This might seem an unusual setup, but I think this kind of use > will grow as the benefits of very-low latency media streaming > become more important. With no media to contribute, the local peer > never calls gUM. As both peers are on a VPN, and gUM is never > called, the connection fails outright, since the connection falls > back to mode 2, but the VPN is not the default route - there is no > opportunity to ever obtain user permission. > > Perhaps more importantly there is a privacy concern as well. As I > understand it, the purpose of mode 2 is to prevent drive-by > enumerations of addresses of alternative routes that should remain > private. The assumption seems to be that the address of the > default route is safe to reveal. However, where the origin came > via a non-default route, it seems like an unsafe assumption. As a > contrived example, if I'm a corporate whistleblower, I don't want > the external address of my default route revealed to my employer > when I'm using my corporate VPN. However as the spec is currently > worded, it allows just that. > > The obvious solution seems to be to change the behaviour of mode > 2. Rather than using the default route in all cases, we should use > the route that was used to fetch the origin. This seems to resolve > both the usability and privacy concerns without reducing existing > security. > > Thanks for listening, > > James > _______________________________________________ > 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 --------------14A7DB38E29823ECF3E4851D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

    Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen

On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
_______________________________________________
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


--------------14A7DB38E29823ECF3E4851D-- From nobody Wed Aug 23 18:54:22 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 D9752132A92 for ; Wed, 23 Aug 2017 18:54:19 -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, 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 uX5OEdaNRxBz for ; Wed, 23 Aug 2017 18:54:17 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 AF02B132AA9 for ; Wed, 23 Aug 2017 18:54:17 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id c73so2490350itb.1 for ; Wed, 23 Aug 2017 18:54:17 -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=BJY+jkNZ+yFHyWTUFQ+OzJFGXUIZ74zgrhnlhVsxCUY=; b=Bg2ueAsTy4aKPqIB0nKXfNdnuxtU8KOri8b7HkgJekmc4r8vCJ6hPDwEf4Bx8dfJjS KzcRT90EFdKwBj+yUopXG43ogmVnZKMABtjKL5tLtkbXpXWrzEC1aqGFrmNHmDR9/uwe 7+CmQ5dYSYyhwEz2grnkMTbtdYEZNZtETg7tCX2UvAcGbAHC/mz0ajoduVNwNBVlkzOL FwdY95/pMOato3cDteVAq0ZULzN4POesdg5Z6ZW05fn772sdGQruRdQj/jtMur4p2JSH 19yTLTLfpP30yK0/RcYfblMWgZoNjSVbRjNt/BEbAxILwjtgAmYknx/T9YCe287BmZrn L1yg== 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=BJY+jkNZ+yFHyWTUFQ+OzJFGXUIZ74zgrhnlhVsxCUY=; b=iP7kOFXLhD6eNjCiCWxsvnWkjvQn5RDD0V7Btejbq3MqKnabFp11EAc004z4ZXmUod oRpkfZqeMnb2cW97obL9WuILBVXiNrP28YeqrsXGyuLMOTIS3tZArdPdOdUxb8QcWXl/ JxksiSr+oNT6tT/Gi+2OhiOdHnkrEGP5m5XkEo5tqyAyGKikZojvOG++N12aRwqKyK3n /nc8y6/CwFPrsH+db9Hzm7twBuf4gHHryFuDB9Uhz5qfNuT9feE45nc92IAEpWtelH0F FDBqBrYtt2lF792+VPkc0UpfwW4y7ZJfUvL3ac8OcsCUR5sx5eFBTrnootCADBu1eVjF /0FA== X-Gm-Message-State: AHYfb5j5W8Zse86XMZENF9CSKxYx9QnWvS4kgG4nBI6RWMM+VDlhr8Iy Vr6iKygsn5FQ4VW7iGSnZzsl3SMtXircCle85w== X-Google-Smtp-Source: ADKCNb7CnLzkXr/LBdNXZql9Gu8+ERLTewx0ToFsPlqtaROxa5uzwVh39i/b3SQeAqSeoQ0lElD4iOf5/ColNeHoARA= X-Received: by 10.36.203.132 with SMTP id u126mr5082496itg.133.1503539656776; Wed, 23 Aug 2017 18:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Wed, 23 Aug 2017 18:53:56 -0700 (PDT) In-Reply-To: <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> From: Justin Uberti Date: Wed, 23 Aug 2017 18:53:56 -0700 Message-ID: To: Byron Campen Cc: Taylor Brandstetter , James Pearce , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c0b09c4268fbd0557761be0" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 01:54:20 -0000 --94eb2c0b09c4268fbd0557761be0 Content-Type: text/plain; charset="UTF-8" This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface? While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also, I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above). On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen wrote: > I suppose that if the non-default route is being used, and there's a > NAT in the way, you would be revealing information that the webserver > didn't already have. But that has always been the case with mode 2. > > Another worthwhile question to ask: what if you're connecting to the > origin via a proxy? Should that effect mode 2? Or maybe even be a different > mode? > > Best regards, > Byron Campen > > > On 8/23/17 5:36 PM, Taylor Brandstetter wrote: > > I agree. This would be consistent with the spirit of the guidelines: > "don't reveal any more IP addresses than have already been revealed." This > may have even been the intent from the start; there's just not a clear > definition for "default route". "Default route used to fetch the origin" > seems like a reasonable definition. > > Justin, do you recall if this has been brought up before? Do you have any > opinions? > > On Wed, Aug 23, 2017 at 2:06 PM, James Pearce > wrote: > >> Please forgive me if I abused the process in any way - this is my first >> contribution to a mailing list such as this. >> >> I am the submitter of the original Mozilla bug identifying this corner >> case mentioned by Byron. (I hesitate to call it as such because the impact >> has been significant to our particular WebRTC use case). I'd like to >> attempt to make my case... >> >> I think there are both usability and privacy issues that need to be >> considered here. >> >> In my particular case, the remote peer is on a VPN. The VPN is not >> installed as the default route (common for corporate and organisational >> VPNs). Only the remote peer is supplying media. This might seem an unusual >> setup, but I think this kind of use will grow as the benefits of very-low >> latency media streaming become more important. With no media to contribute, >> the local peer never calls gUM. As both peers are on a VPN, and gUM is >> never called, the connection fails outright, since the connection falls >> back to mode 2, but the VPN is not the default route - there is no >> opportunity to ever obtain user permission. >> >> Perhaps more importantly there is a privacy concern as well. As I >> understand it, the purpose of mode 2 is to prevent drive-by enumerations of >> addresses of alternative routes that should remain private. The assumption >> seems to be that the address of the default route is safe to reveal. >> However, where the origin came via a non-default route, it seems like an >> unsafe assumption. As a contrived example, if I'm a corporate >> whistleblower, I don't want the external address of my default route >> revealed to my employer when I'm using my corporate VPN. However as the >> spec is currently worded, it allows just that. >> >> The obvious solution seems to be to change the behaviour of mode 2. >> Rather than using the default route in all cases, we should use the route >> that was used to fetch the origin. This seems to resolve both the usability >> and privacy concerns without reducing existing security. >> >> Thanks for listening, >> >> James >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > --94eb2c0b09c4268fbd0557761be0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the first ti= me I've heard this case discussed. I assume the basic issue is that you= want to use the same interface to connect to the remote endpoint as was us= ed to load the page, even when the default route would have caused you to u= se a different interface?

While the suggested= solution seems reasonable, this may not always be possible (e.g., if you d= on't have access to the origin IP). Also,=C2=A0I think any public addresses associated with the default ro= ute will already be discoverable via other mechanisms, e.g. XHR (as Byron m= entioned above).


On= Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampen@mozilla.com&g= t; wrote:
=20 =20 =20
=C2=A0=C2=A0=C2=A0= I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

=C2=A0=C2=A0=C2=A0 Another worthwhile question to ask: what if you= 9;re connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't = reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just no= t a clear definition for "default route". "Default r= oute used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
_____________________= __________________________
rtcweb mailing list
rtcweb= @ietf.org
https://www.ietf.org/mailman/listin= fo/rtcweb



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



--94eb2c0b09c4268fbd0557761be0-- From nobody Thu Aug 24 00:30:08 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 0E92D132339 for ; Thu, 24 Aug 2017 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-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 qf0R9kh3WxIp for ; Thu, 24 Aug 2017 00:30:01 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 694D1132332 for ; Thu, 24 Aug 2017 00:30:01 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id k46so7208703wre.2 for ; Thu, 24 Aug 2017 00:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=9FI3iuR7mWr2DCkxDavgytpZcgqVjfBiPvW0eT4yiL0=; b=K4dspaAEph5UZcKkadiQZhdA5TKtkcOE3Z0O9VGrbNwzAK/lzTheFshyWEStKHVGN9 eaBVx8YFk6QQyDtePGsKiqgtvTRWkFvXwJU1sKU7T8jUncQ0Bbly+uhY/JH6IWZllJZO mf6oqXyzhr5tTkmBE2a1XKahqUQCD9F6VaRxOQzLFOVxS8okhGYa+BqxUmV6p5bo/s4y gIONbNLuulXviKTtLmLszpbPWy0U2TcnyHaxwv8P/x28DgPF9trZRS+Pcy1W27FBSB+V tfC2pTL3E41H+/RwuUgY6Rbw0C5KOfalEoxycFLTtGafszB9Xoo7hrl95JJGHiG26QuM mjXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=9FI3iuR7mWr2DCkxDavgytpZcgqVjfBiPvW0eT4yiL0=; b=muDJuqaKlbFO3AUjwHitloLirA94b9p6MsqQTz9G50u77AoPVUORZNmGrhNrtzPfSw kuhQ+HCjT6YuXyMP1Ud0xyiiitjsnzv1X5ZZX/ictcyvV13ZSxLBlw0jczRlfaoNQ8WE LCIn/4Hs0l/y1P9mbj5fUIn65z5C5W5rJ/gavdaPISSrqsRa4ifqwDXYbcOqiE5KRF5/ AjqwLxgCRyPc+VOUFqGo0GKezpi0H9HvGLlM6zjtO3fgTEkFZQEuJLKotcnNcmoBWD++ ZbbM4AExUSWJ4DeRwmc6YyOz20TH1ZA4ldVVentqGPFNNT2yXb6n0bFG8SDXtGGsVplZ tRzg== X-Gm-Message-State: AHYfb5iSgVXYG3RY7e+c9NqQ8/m14oWTRJySH0Ue9OkzPLoQMsI1a8oZ G41oiPE15v0UCRAi X-Received: by 10.223.154.206 with SMTP id a72mr3129410wrc.160.1503559799873; Thu, 24 Aug 2017 00:29:59 -0700 (PDT) Received: from [192.168.0.13] (cpc3-wilm2-2-0-cust931.1-4.cable.virginm.net. [81.96.107.164]) by smtp.gmail.com with ESMTPSA id 80sm3490830wml.23.2017.08.24.00.29.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 00:29:58 -0700 (PDT) References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3EB758AA-31C2-4FC3-8BC9-2B9AD12E7A59 Message-Id: Cc: Byron Campen , Taylor Brandstetter , RTCWeb IETF X-Mailer: iPad Mail (14G60) From: James Pearce Date: Thu, 24 Aug 2017 08:29:57 +0100 To: Justin Uberti Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 07:30:06 -0000 --Apple-Mail-3EB758AA-31C2-4FC3-8BC9-2B9AD12E7A59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes, I guess it's true that you could use XHR to discover the default route'= s public addresses. I suppose the only difference is that it requires a bit m= ore effort - a site that is CORS enabled that actually gathers those address= es. In those cases, a concerned individual might have taken other precaution= s. Even if the privacy concern isn't actually a significant issue (personally I= think it is), there are still usability issues I think need addressing. In what cases would the origin IP not be available? In those cases would it b= e safe to fall back to the default route? James > On 24 Aug 2017, at 02:53, Justin Uberti wrote: >=20 > This is the first time I've heard this case discussed. I assume the basic i= ssue is that you want to use the same interface to connect to the remote end= point as was used to load the page, even when the default route would have c= aused you to use a different interface? >=20 > While the suggested solution seems reasonable, this may not always be poss= ible (e.g., if you don't have access to the origin IP). Also, I think any pu= blic addresses associated with the default route will already be discoverabl= e via other mechanisms, e.g. XHR (as Byron mentioned above). >=20 >=20 >> On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen wrote= : >> I suppose that if the non-default route is being used, and there's a N= AT in the way, you would be revealing information that the webserver didn't a= lready have. But that has always been the case with mode 2. >>=20 >> Another worthwhile question to ask: what if you're connecting to the o= rigin via a proxy? Should that effect mode 2? Or maybe even be a different m= ode? >>=20 >> Best regards, >> Byron Campen >>=20 >>=20 >>> On 8/23/17 5:36 PM, Taylor Brandstetter wrote: >>> I agree. This would be consistent with the spirit of the guidelines: "do= n't reveal any more IP addresses than have already been revealed." This may h= ave even been the intent from the start; there's just not a clear definition= for "default route". "Default route used to fetch the origin" seems like a r= easonable definition. >>>=20 >>> Justin, do you recall if this has been brought up before? Do you have an= y opinions? >>>=20 >>>> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce wr= ote: >>>> Please forgive me if I abused the process in any way - this is my first= contribution to a mailing list such as this. >>>>=20 >>>> I am the submitter of the original Mozilla bug identifying this corner c= ase mentioned by Byron. (I hesitate to call it as such because the impact ha= s been significant to our particular WebRTC use case). I'd like to attempt t= o make my case... >>>>=20 >>>> I think there are both usability and privacy issues that need to be con= sidered here. >>>>=20 >>>> In my particular case, the remote peer is on a VPN. The VPN is not inst= alled as the default route (common for corporate and organisational VPNs). O= nly the remote peer is supplying media. This might seem an unusual setup, bu= t I think this kind of use will grow as the benefits of very-low latency med= ia streaming become more important. With no media to contribute, the local p= eer never calls gUM. As both peers are on a VPN, and gUM is never called, th= e connection fails outright, since the connection falls back to mode 2, but t= he VPN is not the default route - there is no opportunity to ever obtain use= r permission. >>>>=20 >>>> Perhaps more importantly there is a privacy concern as well. As I under= stand it, the purpose of mode 2 is to prevent drive-by enumerations of addre= sses of alternative routes that should remain private. The assumption seems t= o be that the address of the default route is safe to reveal. However, where= the origin came via a non-default route, it seems like an unsafe assumption= . As a contrived example, if I'm a corporate whistleblower, I don't want the= external address of my default route revealed to my employer when I'm using= my corporate VPN. However as the spec is currently worded, it allows just t= hat. >>>>=20 >>>> The obvious solution seems to be to change the behaviour of mode 2. Rat= her than using the default route in all cases, we should use the route that w= as used to fetch the origin. This seems to resolve both the usability and pr= ivacy concerns without reducing existing security. >>>>=20 >>>> Thanks for listening, >>>>=20 >>>> James >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 --Apple-Mail-3EB758AA-31C2-4FC3-8BC9-2B9AD12E7A59 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, I guess it's true that= you could use XHR to discover the default route's public addresses. I suppo= se the only difference is that it requires a bit more effort - a site that i= s CORS enabled that actually gathers those addresses. In those cases, a conc= erned individual might have taken other precautions.

Even if the privacy concern isn't actually a significant issue (personally= I think it is), there are still usability issues I think need addressing.

In what cases would the origin IP not be available? I= n those cases would it be safe to fall back to the default route?
=
James

On 24 Aug 2017, at 02:53, Justin Uberti &= lt;juberti@google.com> wrote:
This is the first time I've heard this case discussed.= I assume the basic issue is that you want to use the same interface to conn= ect to the remote endpoint as was used to load the page, even when the defau= lt route would have caused you to use a different interface?

While the suggested solution seems reasonable, this may not al= ways be possible (e.g., if you don't have access to the origin IP). Also,&nb= sp;I think any public addresses asso= ciated with the default route will already be discoverable via other mechani= sms, e.g. XHR (as Byron mentioned above).


On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampe= n@mozilla.com> wrote:
=20 =20 =20
    I= suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

    Another worthwhile question to ask: what if you're c= onnecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
______________________= _________________________
rtcweb mailing list
rtcweb@= ietf.org
https://www.ietf.org/mailman/listinfo= /rtcweb



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



= --Apple-Mail-3EB758AA-31C2-4FC3-8BC9-2B9AD12E7A59-- From nobody Thu Aug 24 07:12:58 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 2A4EE13296D for ; Thu, 24 Aug 2017 07:12:57 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 1fBIxalqInP0 for ; Thu, 24 Aug 2017 07:12:53 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 3E0AC132940 for ; Thu, 24 Aug 2017 07:12:53 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 187so6430081oig.1 for ; Thu, 24 Aug 2017 07:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=EazxP4OF1pP+yiRxQVJE5iFyhKuSrg8IOQ0ACl1Bgak=; b=Zp3XW0H0R6ft26AhUHUpfOZsEeharF6AC45jAC0Onq8+upSISX4YTpPEOSK5ekVED4 /X94kKJQdFbPbj+SAAP95UsifPa/j8+RHxh115SywBswhjXMBWazsYavS+oJsA1Drg4b uOU3IO7adNsvIpMV5qeDfmnIXCZ0aIRvVhbbc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EazxP4OF1pP+yiRxQVJE5iFyhKuSrg8IOQ0ACl1Bgak=; b=ZyzwBs+HdvE3IfcsAb3zxwHQoBMhxkKq2tlc/3r3L6Kh9VviBQUz0+UHx81NG2JxzD iq//ie8DiEPGvSBjM0MCanna8SYjZwLEa5YgKeEGYM1sAir6ZHnXp4qJzei3JfXaOBWI 4PCm0kxK5uXk67T7Sd+AU4WBFzVuBFmpCAbUKvPdnNzeC5UJKih0H4GlrZnnQZJu2+r+ hNL6XHg72taBdWuI3QhvgKVAprpwMKQJ+wAJ/s0dS1ZRaaaPq1Pk6rQMCP5ixY7vXk54 eLBmvkfAv5NabGtXYp+NyxbbkrKeeKKzImfO0cdFV/7GfAONMjDpHUSXUN/dTFq4W09/ C76w== X-Gm-Message-State: AHYfb5hhbY73Y4+PiHIDOSLMRATuHvs9BC9YzKqlESpDblDx0P1sipwd IO/K5FQF0WbOtJQK10OLYA== X-Received: by 10.202.212.86 with SMTP id l83mr8373235oig.133.1503583970360; Thu, 24 Aug 2017 07:12:50 -0700 (PDT) Received: from bcampen-19607.local ([2600:1700:24d0:8760:f8a1:f24b:e7d7:c473]) by smtp.googlemail.com with ESMTPSA id a9sm1240892oih.3.2017.08.24.07.12.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 07:12:49 -0700 (PDT) To: James Pearce , Justin Uberti Cc: Taylor Brandstetter , RTCWeb IETF References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> From: Byron Campen Message-ID: <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> Date: Thu, 24 Aug 2017 09:12:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------603200F4189DDE425483130D" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 14:12:57 -0000 This is a multi-part message in MIME format. --------------603200F4189DDE425483130D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/24/17 2:29 AM, James Pearce wrote: > Yes, I guess it's true that you could use XHR to discover the default > route's public addresses. I suppose the only difference is that it > requires a bit more effort - a site that is CORS enabled that actually > gathers those addresses. In those cases, a concerned individual might > have taken other precautions. So, I guess we could consider a scenario where the machine does not have internet access at all, and there's something nefarious going on in the private network? Seems kinda out of scope for fingerprinting attacks, honestly. > > Even if the privacy concern isn't actually a significant issue > (personally I think it is), there are still usability issues I think > need addressing. > > In what cases would the origin IP not be available? In those cases > would it be safe to fall back to the default route? If you're using an http proxy, this would be the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a file instead of a web server. Best regards, Byron Campen > On 24 Aug 2017, at 02:53, Justin Uberti > wrote: > >> This is the first time I've heard this case discussed. I assume the >> basic issue is that you want to use the same interface to connect to >> the remote endpoint as was used to load the page, even when the >> default route would have caused you to use a different interface? >> >> While the suggested solution seems reasonable, this may not always be >> possible (e.g., if you don't have access to the origin IP). Also, I >> think any public addresses associated with the default route will >> already be discoverable via other mechanisms, e.g. XHR (as Byron >> mentioned above). >> >> >> On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen > > wrote: >> >> I suppose that if the non-default route is being used, and >> there's a NAT in the way, you would be revealing information that >> the webserver didn't already have. But that has always been the >> case with mode 2. >> >> Another worthwhile question to ask: what if you're connecting >> to the origin via a proxy? Should that effect mode 2? Or maybe >> even be a different mode? >> >> Best regards, >> Byron Campen >> >> >> On 8/23/17 5:36 PM, Taylor Brandstetter wrote: >>> I agree. This would be consistent with the spirit of the >>> guidelines: "don't reveal any more IP addresses than have >>> already been revealed." This may have even been the intent from >>> the start; there's just not a clear definition for "default >>> route". "Default route used to fetch the origin" seems like a >>> reasonable definition. >>> >>> Justin, do you recall if this has been brought up before? Do you >>> have any opinions? >>> >>> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce >>> > wrote: >>> >>> Please forgive me if I abused the process in any way - this >>> is my first contribution to a mailing list such as this. >>> >>> I am the submitter of the original Mozilla bug identifying >>> this corner case mentioned by Byron. (I hesitate to call it >>> as such because the impact has been significant to our >>> particular WebRTC use case). I'd like to attempt to make my >>> case... >>> >>> I think there are both usability and privacy issues that >>> need to be considered here. >>> >>> In my particular case, the remote peer is on a VPN. The VPN >>> is not installed as the default route (common for corporate >>> and organisational VPNs). Only the remote peer is supplying >>> media. This might seem an unusual setup, but I think this >>> kind of use will grow as the benefits of very-low latency >>> media streaming become more important. With no media to >>> contribute, the local peer never calls gUM. As both peers >>> are on a VPN, and gUM is never called, the connection fails >>> outright, since the connection falls back to mode 2, but the >>> VPN is not the default route - there is no opportunity to >>> ever obtain user permission. >>> >>> Perhaps more importantly there is a privacy concern as well. >>> As I understand it, the purpose of mode 2 is to prevent >>> drive-by enumerations of addresses of alternative routes >>> that should remain private. The assumption seems to be that >>> the address of the default route is safe to reveal. However, >>> where the origin came via a non-default route, it seems like >>> an unsafe assumption. As a contrived example, if I'm a >>> corporate whistleblower, I don't want the external address >>> of my default route revealed to my employer when I'm using >>> my corporate VPN. However as the spec is currently worded, >>> it allows just that. >>> >>> The obvious solution seems to be to change the behaviour of >>> mode 2. Rather than using the default route in all cases, we >>> should use the route that was used to fetch the origin. This >>> seems to resolve both the usability and privacy concerns >>> without reducing existing security. >>> >>> Thanks for listening, >>> >>> James >>> _______________________________________________ >>> 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 >>> >> >> >> --------------603200F4189DDE425483130D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 8/24/17 2:29 AM, James Pearce wrote:
Yes, I guess it's true that you could use XHR to discover the default route's public addresses. I suppose the only difference is that it requires a bit more effort - a site that is CORS enabled that actually gathers those addresses. In those cases, a concerned individual might have taken other precautions.
   So, I guess we could consider a scenario where the machine does not have internet access at all, and there's something nefarious going on in the private network? Seems kinda out of scope for fingerprinting attacks, honestly.


Even if the privacy concern isn't actually a significant issue (personally I think it is), there are still usability issues I think need addressing.

In what cases would the origin IP not be available? In those cases would it be safe to fall back to the default route?
   If you're using an http proxy, this would be the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a file instead of a web server.

Best regards,
Byron Campen

On 24 Aug 2017, at 02:53, Justin Uberti <juberti@google.com> wrote:

This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface?

While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also, I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).


On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampen@mozilla.com> wrote:
    I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

    Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
_______________________________________________
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




--------------603200F4189DDE425483130D-- From nobody Thu Aug 24 09:33: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 2E0E01321F1 for ; Thu, 24 Aug 2017 09:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-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 izLbXjQCHd6F for ; Thu, 24 Aug 2017 09:33:23 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 30EEA1321E6 for ; Thu, 24 Aug 2017 09:33:23 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id u15so4116194wrg.5 for ; Thu, 24 Aug 2017 09:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=0ukM21jtJUZvht6C3/9yXkz7eAjWY/WDiTGQmQlznjM=; b=rDCtO5mFM+a09Km2mLRHYXnvndUU0pcZV019msCPwMTMI/lxQbhwa1oR4joC/sui6r qU3z5QUcUi1ImIIBxeZsdOgvyaRKyZGQH1kJhlAHsOlJQ4jlnyvULd+mX9FpDdjNZMCH rf/EcbF9ZUhv34hIlK7hZmuSZ7QHizLJZZFYEQMmSXyrXYNrRuZpufpppbsrotOaUUNf 2ri0YlDjZdZ6cWzNUBDcZRopQ/3+gb4p8iQ0IV+z9biIflm+xqa+R1ADryapZVVOT9Tr WiuVpaWGmZaSHwF3N+soV4LtoXKhYztgGdj52SDSEo/6ZPJnlrq5bOECM2YB2DDhUjX3 kbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=0ukM21jtJUZvht6C3/9yXkz7eAjWY/WDiTGQmQlznjM=; b=rNhzjsjpBazZtQs2DHeZNbMML+L3+Nuq08VXW0GVdm/QH5dxXDe70Ec5WORfIbzNHn BponAI8q81kJodJLgI6S7o29zIULdO12ecfehJXiW+oVNSbog4enjM1suvR8Lstjgh95 lWKS7LyvPOFl8mFu3UtIFzxYTKoL8clrwYLy0mNL0suKP3ot4uybmjscVbUypkitzWiU 9bv6Tttf1ezxJc502Ex+nP1wc7reJdXuiHDosFSdw+yZYCWH1EKt1AHWQwTznEbK+QG6 FEdzijb8Yjx9NRcnP08t84orRH1huKkMpZ4q1WSZ2QW9ZKVghLEiUZ5JfkvtwyhZ1TQC ki1A== X-Gm-Message-State: AHYfb5jNHrlg4A4Ph0jkgz83p4DJHQR3L/JMADAXVkQE+06BvpEfoFem Q3ij0d0uRZjXFk6m X-Received: by 10.223.195.120 with SMTP id e53mr4469564wrg.115.1503592401458; Thu, 24 Aug 2017 09:33:21 -0700 (PDT) Received: from [192.168.0.13] (cpc3-wilm2-2-0-cust931.1-4.cable.virginm.net. [81.96.107.164]) by smtp.gmail.com with ESMTPSA id y127sm4753993wmd.3.2017.08.24.09.33.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 09:33:20 -0700 (PDT) References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> In-Reply-To: <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-A3F6E9EC-5A38-42E2-83F2-808D94C261B2 Content-Transfer-Encoding: 7bit Message-Id: Cc: Justin Uberti , Taylor Brandstetter , RTCWeb IETF X-Mailer: iPad Mail (14G60) From: James Pearce Date: Thu, 24 Aug 2017 17:33:19 +0100 To: Byron Campen Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 16:33:26 -0000 --Apple-Mail-A3F6E9EC-5A38-42E2-83F2-808D94C261B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 24 Aug 2017, at 15:12, Byron Campen wrote: >=20 >=20 >=20 >> On 8/24/17 2:29 AM, James Pearce wrote: >> Yes, I guess it's true that you could use XHR to discover the default rou= te's public addresses. I suppose the only difference is that it requires a b= it more effort - a site that is CORS enabled that actually gathers those add= resses. In those cases, a concerned individual might have taken other precau= tions. > So, I guess we could consider a scenario where the machine does not hav= e internet access at all, and there's something nefarious going on in the pr= ivate network? Seems kinda out of scope for fingerprinting attacks, honestly= . Yes, I think I agree. >=20 >>=20 >> Even if the privacy concern isn't actually a significant issue (personall= y I think it is), there are still usability issues I think need addressing. >>=20 >> In what cases would the origin IP not be available? In those cases would i= t be safe to fall back to the default route? > If you're using an http proxy, this would be the case. I think it would= be reasonable to fall back to the default route here. Another case might be= when you're using a file instead of a web server. Where an HTTP proxy is used to obtain the original page, wouldn't we use the= proxy's address for the purpose of obtaining the usable route? >=20 > Best regards, > Byron Campen Cheers, James >=20 >> On 24 Aug 2017, at 02:53, Justin Uberti wrote: >>=20 >>> This is the first time I've heard this case discussed. I assume the basi= c issue is that you want to use the same interface to connect to the remote e= ndpoint as was used to load the page, even when the default route would have= caused you to use a different interface? >>>=20 >>> While the suggested solution seems reasonable, this may not always be po= ssible (e.g., if you don't have access to the origin IP). Also, I think any p= ublic addresses associated with the default route will already be discoverab= le via other mechanisms, e.g. XHR (as Byron mentioned above). >>>=20 >>>=20 >>>> On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen wro= te: >>>> I suppose that if the non-default route is being used, and there's a= NAT in the way, you would be revealing information that the webserver didn'= t already have. But that has always been the case with mode 2. >>>>=20 >>>> Another worthwhile question to ask: what if you're connecting to th= e origin via a proxy? Should that effect mode 2? Or maybe even be a differen= t mode? >>>>=20 >>>> Best regards, >>>> Byron Campen >>>>=20 >>>>=20 >>>> On 8/23/17 5:36 PM, Taylor Brandstetter wrote: >>>>> I agree. This would be consistent with the spirit of the guidelines: "= don't reveal any more IP addresses than have already been revealed." This ma= y have even been the intent from the start; there's just not a clear definit= ion for "default route". "Default route used to fetch the origin" seems like= a reasonable definition. >>>>>=20 >>>>> Justin, do you recall if this has been brought up before? Do you have a= ny opinions? >>>>>=20 >>>>>> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce w= rote: >>>>>> Please forgive me if I abused the process in any way - this is my fir= st contribution to a mailing list such as this. >>>>>>=20 >>>>>> I am the submitter of the original Mozilla bug identifying this corne= r case mentioned by Byron. (I hesitate to call= it as such because the impact has been significant to our particular WebRTC= use case). I'd like to attempt to make my case... >>>>>>=20 >>>>>> I think there are both usability and privacy issues that need to be c= onsidered here. >>>>>>=20 >>>>>> In my particular case, the remote peer is on a VPN. The VPN is not in= stalled as the default route (common for corporate and organisational VPNs).= Only the remote peer is supplying media. This might seem an unusual setup, b= ut I think this kind of use will grow as the benefits of very-low latency me= dia streaming become more important. With no media to contribute, the local p= eer never calls gUM. As both peers are on a VPN, and gUM is never called, th= e connection fails outright, since the connection falls back to mode 2, but t= he VPN is not the default route - there is no opportunity to ever obtain use= r permission. >>>>>>=20 >>>>>> Perhaps more importantly there is a privacy concern as well. As I und= erstand it, the purpose of mode 2 is to prevent drive-by enumerations of add= resses of alternative routes that should remain private. The assumption seem= s to be that the address of the default route is safe to reveal. However, wh= ere the origin came via a non-default route, it seems like an unsafe assumpt= ion. As a contrived example, if I'm a corporate whistleblower, I don't want t= he external address of my default route revealed to my employer when I'm usi= ng my corporate VPN. However as the spec is currently worded, it allows just= that. >>>>>>=20 >>>>>> The obvious solution seems to be to change the behaviour of mode 2. R= ather than using the default route in all cases, we should use the route tha= t was used to fetch the origin. This seems to resolve both the usability and= privacy concerns without reducing existing security. >>>>>>=20 >>>>>> Thanks for listening, >>>>>>=20 >>>>>> James >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-A3F6E9EC-5A38-42E2-83F2-808D94C261B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 24 Aug 2017, at 15:12, Byron Campen <bcampen@mozilla.com> wrote:



On 8/24/17 2:29 AM, James Pearce wrote:
Yes, I guess it's true that you could use XHR to discover the default route's public addresses. I suppose the only difference is that it requires a bit more effort - a site that is CORS enabled that actually gathers those addresses. In those cases, a concerned individual might have taken other precautions.
   So, I guess we could consider a scenario where the machine does not have internet access at all, and there's something nefarious going on in the private network? Seems kinda out of scope for fingerprinting attacks, honestly.

Yes, I think I agree.



Even if the privacy concern isn't actually a significant issue (personally I think it is), there are still usability issues I think need addressing.

In what cases would the origin IP not be available? In those cases would it be safe to fall back to the default route?
   If you're using an http proxy, this would be the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a file instead of a web server.

Where an HTTP proxy is used to obtain the original page, wouldn't we use the proxy's address for the purpose of obtaining the usable route?


Best regards,
Byron Campen

Cheers,
James


On 24 Aug 2017, at 02:53, Justin Uberti <juberti@google.com> wrote:

This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface?

While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also, I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).


On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampen@mozilla.com> wrote:
    I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

    Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

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



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




--Apple-Mail-A3F6E9EC-5A38-42E2-83F2-808D94C261B2-- From nobody Thu Aug 24 09:38: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 CF8151321F1 for ; Thu, 24 Aug 2017 09:38: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 4gMFpgYLibIy for ; Thu, 24 Aug 2017 09:38:45 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 C56421321E6 for ; Thu, 24 Aug 2017 09:38:45 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x124so10352835oia.2 for ; Thu, 24 Aug 2017 09:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=mVyMXVHI/EnNeNU+j5mv/k+aqsET41C5ty0/ami25Nk=; b=Zr3WgkzOjfXjEH79GzPGKl7nkmWXvlB5DiofzSMNs3PrwFxTNHDanpatQCrmRpaAyq exIpfyRtb3P1HIXz9TOaqSqyI7d4hip1q6dmueVfVEKRhs2mnpmBFBB+2bmKakCvwDe6 fbX794Qu++OQwYZ5KfBoaYcnNksFFGQFInGz8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mVyMXVHI/EnNeNU+j5mv/k+aqsET41C5ty0/ami25Nk=; b=dYgcG2Ckl4ZngXnbehRGTMYCvwgrnZAA3nHELloCaq41i4aL/UaP2/QuC3Xt9KfPnD 2wTp3QwpZSOxqFXLmxXkFdCZWVSoRDJlSxZJCAeWd8pPW9H96W3Ogasv7lV8H2SWF3Su Zv6Kf3WAltxSkzrXei/07kOLts+GpDBthXsYMuanWRAR0Iu8cogE9SfuOw+/mVyXHJNG jATAHPJapE5kFFLRw0ES6OTmWan9KrMPYeyeUzEuxUEq4dbwiXT6BoCAUY9w1PmNdDz2 JoraRSYUxsiTidJQbSBqBL2Yn2Tm4pnFP8DIAq/3t1zxnZUesVUWx7lc6ZXTOmlhz7a1 ki4A== X-Gm-Message-State: AHYfb5hOdePHcmPMcvaIE1I2C9zjHT2OrxszxWf/NMv1vrjGtIQwFJW/ i3JwRmvHBRmd78J6TqFGvQ== X-Received: by 10.202.220.198 with SMTP id t189mr8287107oig.100.1503592724525; Thu, 24 Aug 2017 09:38:44 -0700 (PDT) Received: from bcampen-19607.local ([2600:1700:24d0:8760:f8a1:f24b:e7d7:c473]) by smtp.googlemail.com with ESMTPSA id s11sm4255267oif.40.2017.08.24.09.38.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 09:38:43 -0700 (PDT) To: James Pearce Cc: Justin Uberti , Taylor Brandstetter , RTCWeb IETF References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> From: Byron Campen Message-ID: <95db47e4-04fb-b3c2-30d2-e6115fd7d972@mozilla.com> Date: Thu, 24 Aug 2017 11:38:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5D8E5A90F31D59A54D6CD60D" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 16:38:50 -0000 This is a multi-part message in MIME format. --------------5D8E5A90F31D59A54D6CD60D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/24/17 11:33 AM, James Pearce wrote: > > > On 24 Aug 2017, at 15:12, Byron Campen > wrote: >> >> If you're using an http proxy, this would be the case. I think it >> would be reasonable to fall back to the default route here. Another >> case might be when you're using a file instead of a web server. > > Where an HTTP proxy is used to obtain the original page, wouldn't we > use the proxy's address for the purpose of obtaining the usable route? Either way would be sane I think. We just have to be careful how we word the spec, so it covers this case. Best regards, Byron Campen >> >>> On 24 Aug 2017, at 02:53, Justin Uberti >> > wrote: >>> >>>> This is the first time I've heard this case discussed. I assume the >>>> basic issue is that you want to use the same interface to connect >>>> to the remote endpoint as was used to load the page, even when the >>>> default route would have caused you to use a different interface? >>>> >>>> While the suggested solution seems reasonable, this may not always >>>> be possible (e.g., if you don't have access to the origin IP). >>>> Also, I think any public addresses associated with the default >>>> route will already be discoverable via other mechanisms, e.g. XHR >>>> (as Byron mentioned above). >>>> >>>> >>>> On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen >>> > wrote: >>>> >>>> I suppose that if the non-default route is being used, and >>>> there's a NAT in the way, you would be revealing information >>>> that the webserver didn't already have. But that has always >>>> been the case with mode 2. >>>> >>>> Another worthwhile question to ask: what if you're >>>> connecting to the origin via a proxy? Should that effect mode >>>> 2? Or maybe even be a different mode? >>>> >>>> Best regards, >>>> Byron Campen >>>> >>>> >>>> On 8/23/17 5:36 PM, Taylor Brandstetter wrote: >>>>> I agree. This would be consistent with the spirit of the >>>>> guidelines: "don't reveal any more IP addresses than have >>>>> already been revealed." This may have even been the intent >>>>> from the start; there's just not a clear definition for >>>>> "default route". "Default route used to fetch the origin" >>>>> seems like a reasonable definition. >>>>> >>>>> Justin, do you recall if this has been brought up before? Do >>>>> you have any opinions? >>>>> >>>>> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce >>>>> > wrote: >>>>> >>>>> Please forgive me if I abused the process in any way - >>>>> this is my first contribution to a mailing list such as this. >>>>> >>>>> I am the submitter of the original Mozilla bug identifying >>>>> this corner case mentioned by Byron. (I hesitate to call >>>>> it as such because the impact has been significant to our >>>>> particular WebRTC use case). I'd like to attempt to make >>>>> my case... >>>>> >>>>> I think there are both usability and privacy issues that >>>>> need to be considered here. >>>>> >>>>> In my particular case, the remote peer is on a VPN. The >>>>> VPN is not installed as the default route (common for >>>>> corporate and organisational VPNs). Only the remote peer >>>>> is supplying media. This might seem an unusual setup, but >>>>> I think this kind of use will grow as the benefits of >>>>> very-low latency media streaming become more important. >>>>> With no media to contribute, the local peer never calls >>>>> gUM. As both peers are on a VPN, and gUM is never called, >>>>> the connection fails outright, since the connection falls >>>>> back to mode 2, but the VPN is not the default route - >>>>> there is no opportunity to ever obtain user permission. >>>>> >>>>> Perhaps more importantly there is a privacy concern as >>>>> well. As I understand it, the purpose of mode 2 is to >>>>> prevent drive-by enumerations of addresses of alternative >>>>> routes that should remain private. The assumption seems to >>>>> be that the address of the default route is safe to >>>>> reveal. However, where the origin came via a non-default >>>>> route, it seems like an unsafe assumption. As a contrived >>>>> example, if I'm a corporate whistleblower, I don't want >>>>> the external address of my default route revealed to my >>>>> employer when I'm using my corporate VPN. However as the >>>>> spec is currently worded, it allows just that. >>>>> >>>>> The obvious solution seems to be to change the behaviour >>>>> of mode 2. Rather than using the default route in all >>>>> cases, we should use the route that was used to fetch the >>>>> origin. This seems to resolve both the usability and >>>>> privacy concerns without reducing existing security. >>>>> >>>>> Thanks for listening, >>>>> >>>>> James >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >> --------------5D8E5A90F31D59A54D6CD60D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/24/17 11:33 AM, James Pearce wrote:


On 24 Aug 2017, at 15:12, Byron Campen <bcampen@mozilla.com> wrote:

   If you're using an http proxy, this would be the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a file instead of a web server.

Where an HTTP proxy is used to obtain the original page, wouldn't we use the proxy's address for the purpose of obtaining the usable route?
    Either way would be sane I think. We just have to be careful how we word the spec, so it covers this case.

Best regards,
Byron Campen


On 24 Aug 2017, at 02:53, Justin Uberti <juberti@google.com> wrote:

This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface?

While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also, I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).


On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampen@mozilla.com> wrote:
    I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.

    Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
_______________________________________________
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





--------------5D8E5A90F31D59A54D6CD60D-- From nobody Thu Aug 24 13:10: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 F00DD132113 for ; Thu, 24 Aug 2017 13:10:31 -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, 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 LMEb8V0VmQj8 for ; Thu, 24 Aug 2017 13:10:29 -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 9AAB4132139 for ; Thu, 24 Aug 2017 13:10:29 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id b76so2309808itb.0 for ; Thu, 24 Aug 2017 13:10:29 -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=iM+/stOUcPGFP9h2OMBjBvrM6SwLUd+rggQd5FqKhl4=; b=DMm8G6/54M9k5lgYS46iaSR1Z+edwEcGMnB/2fEK3bnUVT2Q2earhyrMmLWxHiW4TZ qkwhPPLa/1pniy22IVa4/ghB+OJSSzHUz/sM18DkzU+OCIaEtDFK3SliN7Ks0UDPN4G8 uwUqW7DlpD6BmV9orEVC5FwgAO1jXf0gr5ctjX74eOUGfgzEailANmcfURapW1G3YeHe 1tsB2qCKHkX22x88u1w0yOUGsqZEK/joUgAroSZlNaB4q9otQ40OtnNq3ftNEGovc94A xj+yX4Sc8hzi96iD5P7He7jmmRQ0aOK2h/zvQuQhCJ/TdODpWVxoDBpeEdxHqXfItQ5S 0zCw== 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=iM+/stOUcPGFP9h2OMBjBvrM6SwLUd+rggQd5FqKhl4=; b=WyjO1ujDMyw8SY+ExfMvwPzlV3OsPQy6aJU9SZalTSHGshxcGQU75KpxyQB0qAcawE 9SVL8m/YpQehOxS6ccvnjvLasK0uXRCEg2UIn7F3AfZCEgTF2vMef1usyosstGrWZoA/ B2rOXBioqebCGxCMFyF3O5DCMok209uOazdGbrQJ5pzYg++3FXLBVeZGYtlpfqAwkedb nq09YIoCbGvkUex8+k7zHsNPQ6uxczdKFBaIds2v/9BV7enyBVqV3iY1iKb1JlE/nZs1 p7z9IKDVk2b6Hl3ddFRiSb3VA+2XD9pE2y7ig1jSHrQvQSTtCB6d0r35EG1VlLQlfsbV qKJA== X-Gm-Message-State: AHYfb5gGqxhrXIG/832Az2GJhDNgUgc7rkksVvZyngeHe3UEwjzpxjGA lms3rR4QU/CmwGnWV/yYSeJA8HUz3YQ5 X-Google-Smtp-Source: ADKCNb7zwBICs9eGmPaBIZHnfs+SV3n6V0rLXAdBGvgFpZs5aNfo9EGxekOYQTBawMB8EoKky/OD92m+nvc+jnfYNyg= X-Received: by 10.36.202.1 with SMTP id k1mr7453510itg.115.1503605428526; Thu, 24 Aug 2017 13:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Thu, 24 Aug 2017 13:10:07 -0700 (PDT) In-Reply-To: <95db47e4-04fb-b3c2-30d2-e6115fd7d972@mozilla.com> References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> <95db47e4-04fb-b3c2-30d2-e6115fd7d972@mozilla.com> From: Justin Uberti Date: Thu, 24 Aug 2017 13:10:07 -0700 Message-ID: To: Byron Campen Cc: James Pearce , Taylor Brandstetter , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c07ea4e74056e0557856b84" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 20:10:32 -0000 --94eb2c07ea4e74056e0557856b84 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 9:38 AM, Byron Campen wrote: > On 8/24/17 11:33 AM, James Pearce wrote: > > > > On 24 Aug 2017, at 15:12, Byron Campen wrote: > > > If you're using an http proxy, this would be the case. I think it would > be reasonable to fall back to the default route here. Another case might be > when you're using a file instead of a web server. > > > Where an HTTP proxy is used to obtain the original page, wouldn't we use > the proxy's address for the purpose of obtaining the usable route? > > Either way would be sane I think. We just have to be careful how we > word the spec, so it covers this case. > This makes sense to me. No Proxy = local v4/v6 used to load origin (bind to 0.0.0.0, connect to origin IP, getsockname to learn interface) Proxy = proxy interface File = default route Will file an issue at github.com/juberti/draughts/issues to track this. > > > Best regards, > Byron Campen > > > On 24 Aug 2017, at 02:53, Justin Uberti wrote: > > This is the first time I've heard this case discussed. I assume the basic > issue is that you want to use the same interface to connect to the remote > endpoint as was used to load the page, even when the default route would > have caused you to use a different interface? > > While the suggested solution seems reasonable, this may not always be > possible (e.g., if you don't have access to the origin IP). Also, I think > any public addresses associated with the default route will already be > discoverable via other mechanisms, e.g. XHR (as Byron mentioned above). > > > On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen wrote: > >> I suppose that if the non-default route is being used, and there's a >> NAT in the way, you would be revealing information that the webserver >> didn't already have. But that has always been the case with mode 2. >> >> Another worthwhile question to ask: what if you're connecting to the >> origin via a proxy? Should that effect mode 2? Or maybe even be a different >> mode? >> >> Best regards, >> Byron Campen >> >> >> On 8/23/17 5:36 PM, Taylor Brandstetter wrote: >> >> I agree. This would be consistent with the spirit of the guidelines: >> "don't reveal any more IP addresses than have already been revealed." This >> may have even been the intent from the start; there's just not a clear >> definition for "default route". "Default route used to fetch the origin" >> seems like a reasonable definition. >> >> Justin, do you recall if this has been brought up before? Do you have any >> opinions? >> >> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce >> wrote: >> >>> Please forgive me if I abused the process in any way - this is my first >>> contribution to a mailing list such as this. >>> >>> I am the submitter of the original Mozilla bug identifying this corner >>> case mentioned by Byron. (I hesitate to call it as such because the impact >>> has been significant to our particular WebRTC use case). I'd like to >>> attempt to make my case... >>> >>> I think there are both usability and privacy issues that need to be >>> considered here. >>> >>> In my particular case, the remote peer is on a VPN. The VPN is not >>> installed as the default route (common for corporate and organisational >>> VPNs). Only the remote peer is supplying media. This might seem an unusual >>> setup, but I think this kind of use will grow as the benefits of very-low >>> latency media streaming become more important. With no media to contribute, >>> the local peer never calls gUM. As both peers are on a VPN, and gUM is >>> never called, the connection fails outright, since the connection falls >>> back to mode 2, but the VPN is not the default route - there is no >>> opportunity to ever obtain user permission. >>> >>> Perhaps more importantly there is a privacy concern as well. As I >>> understand it, the purpose of mode 2 is to prevent drive-by enumerations of >>> addresses of alternative routes that should remain private. The assumption >>> seems to be that the address of the default route is safe to reveal. >>> However, where the origin came via a non-default route, it seems like an >>> unsafe assumption. As a contrived example, if I'm a corporate >>> whistleblower, I don't want the external address of my default route >>> revealed to my employer when I'm using my corporate VPN. However as the >>> spec is currently worded, it allows just that. >>> >>> The obvious solution seems to be to change the behaviour of mode 2. >>> Rather than using the default route in all cases, we should use the route >>> that was used to fetch the origin. This seems to resolve both the usability >>> and privacy concerns without reducing existing security. >>> >>> Thanks for listening, >>> >>> James >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> >> >> > > > --94eb2c07ea4e74056e0557856b84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Aug 24, 2017 at 9:38 AM, Byron Campen <bcampen@mozilla.com&g= t; wrote:
=20 =20 =20
On 8/24/17 11= :33 AM, James Pearce wrote:
=20
=20


On 24 Aug 2017, at 15:12, Byron Campen <bcampen@mozilla.com> wrote:

=C2=A0=C2=A0 If you're using an http proxy, this would be= the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a fil= e instead of a web server.

Where an HTTP proxy is used to obtain the original page, wouldn't we use the proxy's address for the purpose of obtaining the usable route?
=C2=A0=C2=A0=C2=A0 Either way would be sane I think. We just have to be= careful how we word the spec, so it covers this case.

This makes sense to me.
No Proxy =3D local v4/v6 used to= load origin (bind to 0.0.0.0, connect to origin IP, getsockname to learn i= nterface)
Proxy =3D proxy interface
File =3D default ro= ute

Will file an issue at github.com/juberti/draughts/issues to= track this.=C2=A0
<= div bgcolor=3D"#FFFFFF">


Best regards,
Byron Campen


On 24 Aug 2017, at 02:53, Justin Uberti <juberti@google.com> wrote:

This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface?

While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also,=C2=A0= I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).


On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <bcampen@mozilla.com&g= t; wrote:
=C2=A0=C2=A0=C2=A0 I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.
=C2=A0=C2=A0=C2=A0 Another worthwhile questio= n to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?

Best regards,
Byron Campen


On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
I agree. This would be consistent with the spirit of the guidelines: "don&#= 39;t reveal any more IP addresses than have already been revealed." Thi= s may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used= to fetch the origin" seems like a reasonable definition.
<= br>
J= ustin, do you recall if this has been brought up before? Do you have any opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <james@jamesandjo.com> wrote:
Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here.

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN= . However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James
____________________________________= ___________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb



_______________________________=
________________
rtcweb mailing list
rtcweb@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/rtcweb






--94eb2c07ea4e74056e0557856b84-- From nobody Thu Aug 24 13:23:30 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 BB34D13235C for ; Thu, 24 Aug 2017 13:23:28 -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, 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 E-EBZLu66KXK for ; Thu, 24 Aug 2017 13:23:26 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 5037B13235A for ; Thu, 24 Aug 2017 13:23:26 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id n5so2694223itb.1 for ; Thu, 24 Aug 2017 13:23:26 -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=Aqf7nWK0br7HG9wyW8uL2+/+0A0MLLR5knb9xGQ/Jqk=; b=CophFu7zkZiwtrPpNSxs7kEkREFMtqojhx2WbGJgL7LHesvYnrTf6glBKGCwGkvDUB fAEKIokZnZXHok64MDYzF8hUH2i/0xc1NfzIyuDNLMUT2o0VM9TznodcO33OKHjIusmE kuZZXsYWxZ/k/KXlMnXmyjmKfV1vjdPhUrCZUf19H3dWEMY0ekoonVJVdz5JSs0WPc+J m3bCo7SWFvs++sW81KlzWENNcRyxTOdJk/C0RGjhHRx6YP3HFea8mv9W4GQfdSvA7W0a e1yGdoV6vqtD2l7TwdGFsP8JeR76F9h8JUn84W1ebDHIaLHBNKXmUWnx/CCw8YH/6qV0 HRFg== 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=Aqf7nWK0br7HG9wyW8uL2+/+0A0MLLR5knb9xGQ/Jqk=; b=inT9Clzml0lCRsrhfttrUEYjWOulYHhEFZg8QruINMSBnDRDw0evW/fk/VvQ2aH+zh sC481rlTgFP5H2VPT/XqbRZzA5hOjJAGFsu3XQWjQG03aUhBpxk4JRXihe3Jncik4c3h iqGsfVXuCXd0V7RWHQJFmbZwNJBXTPWUssUCPwDue9BPQzGAhzTUr9cM5BqTijXJNRbh oyOLSDzt7UGS8XAigJwUbvUTzlaRRzZ27XDxgx+D3eQRiXllqSaoH2y/11capSTuJXCK cGeM5xxH2SUwDh0yg8R1oBojQIsM5K17h0zSDjhiYff3awju+Ma4XDKdAFIZcSYAzli6 zvUQ== X-Gm-Message-State: AHYfb5hZE6Nm6tKua5wMgy2DHAu32nUMtJQVc9FIsTJ1HDYQ/I2cJ4i1 jVkmN8pqawA8/rF7bs2JZotsRl7yu3fV X-Google-Smtp-Source: ADKCNb71JMy41YmxzZwcpg9bbJzvNMnjEkHA8AxjTfnFG0nVHTH/GoC6NkInjFuAGHXtpqO+0a5Xh1mKiT8aaOyc2eE= X-Received: by 10.36.202.1 with SMTP id k1mr7482716itg.115.1503606205183; Thu, 24 Aug 2017 13:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Thu, 24 Aug 2017 13:23:04 -0700 (PDT) In-Reply-To: References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> <95db47e4-04fb-b3c2-30d2-e6115fd7d972@mozilla.com> From: Justin Uberti Date: Thu, 24 Aug 2017 13:23:04 -0700 Message-ID: To: Byron Campen Cc: James Pearce , Taylor Brandstetter , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c07ea4ebe78a105578599ea" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 20:23:29 -0000 --94eb2c07ea4ebe78a105578599ea Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 1:10 PM, Justin Uberti wrote: > > On Thu, Aug 24, 2017 at 9:38 AM, Byron Campen wrote: > >> On 8/24/17 11:33 AM, James Pearce wrote: >> >> >> >> On 24 Aug 2017, at 15:12, Byron Campen wrote: >> >> >> If you're using an http proxy, this would be the case. I think it >> would be reasonable to fall back to the default route here. Another case >> might be when you're using a file instead of a web server. >> >> >> Where an HTTP proxy is used to obtain the original page, wouldn't we use >> the proxy's address for the purpose of obtaining the usable route? >> >> Either way would be sane I think. We just have to be careful how we >> word the spec, so it covers this case. >> > > This makes sense to me. > No Proxy = local v4/v6 used to load origin (bind to 0.0.0.0, connect to > origin IP, getsockname to learn interface) > Proxy = proxy interface > File = default route > > Will file an issue at github.com/juberti/draughts/issues to track this. > Having thought about it a bit more, I think that binding to 0.0.0.0 or doing the above will suffice. Essentially, this becomes a recommendation that if you bind to a specific interface, you should determine that interface via the origin IP, and not a 'well-known' IP, as was the prior guidance. --94eb2c07ea4ebe78a105578599ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 24, 2017 at 1:10 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Au= g 24, 2017 at 9:38 AM, Byron Campen <bcampen@mozilla.com> = wrote:
=20 =20 =20
On 8/24/17 11:33 AM, James Pearce wrote:
=20
=20


On 24 Aug 2017, at 15:12, Byron Campen <bcampen@mozilla.com> wrote:

=C2=A0=C2=A0 If you're using an http proxy, this would be= the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a fil= e instead of a web server.

Where an HTTP proxy is used to obtain the original page, wouldn't we use the proxy's address for the purpose of obtaining the usable route?
=C2=A0=C2=A0=C2=A0 Either way would be sane I think. We just have to be= careful how we word the spec, so it covers this case.

This makes sense to me.
No Proxy =3D local v4/v6 = used to load origin (bind to 0.0.0.0, connect to origin IP, getsockname to = learn interface)
Proxy =3D proxy interface
File =3D def= ault route

Will file an issue at github.com/juber= ti/draughts/issues to track this.=C2=A0

Having thought about it a bit more, I think t= hat binding to 0.0.0.0 or doing the above will suffice. Essentially, this b= ecomes a recommendation that if you bind to a specific interface, you shoul= d determine that interface via the origin IP, and not a 'well-known'= ; IP, as was the prior guidance.=C2=A0
--94eb2c07ea4ebe78a105578599ea-- From nobody Thu Aug 24 13:30:40 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 001001320C9 for ; Thu, 24 Aug 2017 13:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 PRGPpwV9pfIo for ; Thu, 24 Aug 2017 13:30:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 87D2F1204DA for ; Thu, 24 Aug 2017 13:30:37 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OKUXoj013184 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 15:30:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Justin Uberti , Byron Campen Cc: RTCWeb IETF , James Pearce References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <5cfd4e0a-b7f7-a2f4-ad91-fbf46e7bdbd0@mozilla.com> <25dc1921-4dfa-60cd-a746-1ec850319a3d@mozilla.com> <95db47e4-04fb-b3c2-30d2-e6115fd7d972@mozilla.com> From: Adam Roach Message-ID: <169af61c-f673-fdb5-8f95-e56bc0ac0ffd@nostrum.com> Date: Thu, 24 Aug 2017 15:30:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 24 Aug 2017 20:30:39 -0000 On 8/24/17 15:23, Justin Uberti wrote: > Essentially, this becomes a recommendation that if you bind to a > specific interface, you should determine that interface via the origin > IP, and not a 'well-known' IP, as was the prior guidance. Thus eliminating something that had always made me vaguely uneasy anyway. This seems cleaner all around. I support the proposed change. /a From nobody Fri Aug 25 02:11:30 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 238FB120720; Fri, 25 Aug 2017 02:11:29 -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, 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 LrQKfrNaRiYC; Fri, 25 Aug 2017 02:11:27 -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 13786132803; Fri, 25 Aug 2017 02:11:22 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-70-599fe9b8221c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4E.D8.21299.8B9EF995; Fri, 25 Aug 2017 11:11:21 +0200 (CEST) To: undisclosed-recipients:; Received: from [147.214.31.178] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 25 Aug 2017 11:11:19 +0200 CC: , , Ted Hardie , , , References: <150129017294.20667.17960314547810703.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: Date: Fri, 25 Aug 2017 11:11:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150129017294.20667.17960314547810703.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030405080305060602070902" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7se7Ol/MjDTbNY7LY83cRu8W+9i1M FjP+TGS26Hl7g8Vi7b92dovGuXYObB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4 Mub9/sNacNC5YvWXCUwNjDPsuhg5OSQETCTab/WxdDFycQgJHGGU6P15ggkkISIgIzF39mNW iMRmRokl1yczgySEBaokDh5dygSSYBaYwyix9coBsA4hAW+JeSsngBWxCVhI3PzRyAZi8wrY S7TdvsUOYrMIqEo0vb/HCmKLCsRI/Lz0iAWiRlDi5MwnYDangI/E9jNvWSAWdDNKzLmwlRFi gbZEQ1MHK8TdShLX511nmcAoMAtJ/yxkPSAJZgEziXmbHzJD2NoSyxa+hrJFJE5evg9lW0vM +HWQDcJWlJjS/ZAdwjaVeH30I9QcI4l3exrZFzByrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st 2cQIjK+DW36r7mC8/MbxEKMAB6MSD6/L8fmRQqyJZcWVuYcYVYDmPNqw+gKjFEtefl6qkgiv 9wugNG9KYmVValF+fFFpTmrxIUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYzex6Pr YneeWvYm9ElxleabL98bTy+JFroxzXKFkXb5S6vwc5bcZrF6HrEeEmEsWyNOLb+27Fmm9YRt PyTmcbq8+vVz842dG1xOuJgKsj3l1PYp4j3MrZ7WuGLbt2dThJ9/W3PHdpm6v6le5n3OvRkv DObcKF6hIXY58UnICutmt/R7PveWavgrsRRnJBpqMRcVJwIAmY41jrcCAAA= Archived-At: Subject: Re: [rtcweb] Last Call: (JavaScript Session Establishment Protocol) to Proposed Standard 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, 25 Aug 2017 09:11:29 -0000 --------------ms030405080305060602070902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: sv Hi, I know the IETF last call is over. However, as I was on vacation during=20 the whole last call, and my issue was known and noted since long before=20 the last call, I want to know what the plan is to do with the issue? I=20 think it is bad process to proceed to IETF last call without addressing=20 the known issues. I did in person during Prague IETF note my concern to=20 Adam in his role as AD. So this concerns issue https://github.com/rtcweb-wg/jsep/issues/745=20 which we have had ongoing discussion since before summer. My preferred way forward as it appears at least one of the editors=20 thinks what I suggested as solution, is that there are text changes to=20 primarily the first bullet in Section 3.6.2 to incorporate my suggested=20 solution. Cheers Magnus Westerlund Den 2017-07-29 kl. 03:02, skrev The IESG: > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: - 'JavaScr= ipt > Session Establishment Protocol' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits f= inal > 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 beginn= ing 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. > > > > --=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 ---------------------------------------------------------------------- --------------ms030405080305060602070902 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 SIb3DQEJBTEPFw0xNzA4MjUwOTExMTlaMC8GCSqGSIb3DQEJBDEiBCBUwPH8W8AMNsPKizFG zBPCt+H8XxpD9pvrSclGmvMlxzBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAGlvSQfW0y3EhG7QT4/SRLT1bkNE0YXZbyUA1qNBP5zEmGAPN ZVXK/U/QzT1m/zlvF5/8faZlSTe+nDz48LXXWVEo4/j6i3RgVDpIEVSykQQzdU0ueR7oPXHb dLCBTjT6urWAON0oY5zU0Ji3UNjrQUU3V5Nivdn6+vZ9LtWzlu7t4UIrt/eE/fNV6f+wwacL 5FR0ILMGDLdctJ9V8v+Afv0FDvmvFqD+yfJzA+YG/CTrPBXJTaGkDR+qo9QwFPjUOuonlEM9 +4bEDKQBjpqokQftL5gOHcenCF6AWfHhd5wxb0tpPoM/iW51278sD2xapvyxt3TFXyruFiY4 Ii/gKwAAAAAAAA== --------------ms030405080305060602070902-- From nobody Fri Aug 25 09:11:10 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 66B8A132C1E; Fri, 25 Aug 2017 09:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 95iuPOJLCmWN; Fri, 25 Aug 2017 09:11:05 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 322291321A0; Fri, 25 Aug 2017 09:11:05 -0700 (PDT) Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6416F24CF1; Fri, 25 Aug 2017 12:10:54 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B9DCB24C4C; Fri, 25 Aug 2017 12:10:53 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 25 Aug 2017 12:10:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 25 Aug 2017 10:10:52 -0600 Cc: draft-ietf-rtcweb-jsep@ietf.org, rtcweb-chairs@ietf.org, RTCWeb IETF , iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7AE0650C-9308-4BF0-992C-4204A8B68319@iii.ca> References: <150129017294.20667.17960314547810703.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Last Call: (JavaScript Session Establishment Protocol) to Proposed Standard 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, 25 Aug 2017 16:11:07 -0000 Magnus, we had been treating this as a LC comment and fully intend to = fix it. Hoping for new text really soon.=20 > On Aug 25, 2017, at 3:11 AM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > I know the IETF last call is over. However, as I was on vacation = during the whole last call, and my issue was known and noted since long = before the last call, I want to know what the plan is to do with the = issue? I think it is bad process to proceed to IETF last call without = addressing the known issues. I did in person during Prague IETF note my = concern to Adam in his role as AD. >=20 > So this concerns issue https://github.com/rtcweb-wg/jsep/issues/745 = which we have had ongoing discussion since before summer. >=20 > My preferred way forward as it appears at least one of the editors = thinks what I suggested as solution, is that there are text changes to = primarily the first bullet in Section 3.6.2 to incorporate my suggested = solution. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 >=20 > Den 2017-07-29 kl. 03:02, skrev The IESG: >> 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 >>=20 >> 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. >>=20 >> Abstract >>=20 >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ >>=20 >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >>=20 >>=20 >=20 > --=20 >=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@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 25 13:33:41 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 56B9B13219F for ; Fri, 25 Aug 2017 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 suABU_xtwhVG for ; Fri, 25 Aug 2017 13:33:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D7FEB13213F for ; Fri, 25 Aug 2017 13:33:38 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PKXbv1060077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 25 Aug 2017 15:33:38 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "rtcweb@ietf.org" Reply-To: "mmusic@ietf.org" From: Adam Roach Message-ID: <87dcbbc3-7a7e-50ba-7c91-67ce32a7dc9b@nostrum.com> Date: Fri, 25 Aug 2017 15:33:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [rtcweb] Pointer: JSEP and DTLS-SDP conflicts 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, 25 Aug 2017 20:33:40 -0000 I have just posted a message to MMUSIC detailing some places that JSEP and DTLS-SDP conflict with each other. As these tend to be general SDP-related issues, I think the conversation should take place on the MMUSIC mailing list -- but I wanted to ensure that everyone participating in RTCWEB is made aware of the conversation. See https://mailarchive.ietf.org/arch/msg/mmusic/F-CM8kFjLo0R2ro00VD3Nhac7ws for details. Follow-ups to MMUSIC, please. /a From nobody Sat Aug 26 10:57:58 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 0486A132BCF; Sat, 26 Aug 2017 10:57:51 -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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150377027097.25852.7714904338592896207@ietfa.amsl.com> Date: Sat, 26 Aug 2017 10:57:51 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-22.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: Sat, 26 Aug 2017 17:57:51 -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 WG of the IETF. Title : JavaScript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-22.txt Pages : 113 Date : 2017-08-26 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-22 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-22 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 Sat Aug 26 11:10:47 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 A184F132BCD for ; Sat, 26 Aug 2017 11:10:40 -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, SPF_PASS=-0.001] autolearn=unavailable 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 izE71op2P-3R for ; Sat, 26 Aug 2017 11:10:38 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 1170713239A for ; Sat, 26 Aug 2017 11:10:36 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id c18so6142823ioj.1 for ; Sat, 26 Aug 2017 11:10: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=8WSkQTXnpgM2agkV1fR9FVD087EiMcU7/ktnfNZOFJQ=; b=aCF1H2EEDrcsn5sH651wH2elDGCTmdJAvpnibCrfJb4k7sdN8zxzcIGupH9rsbkolm h57XHQhQqSR2LZlsmWdCTrtooFmslLuwwvR9mH6Z4CCSlHnFrD/D9mFD5Ix+vjfL4sIQ 9gnflYIttNBGLJgHr9kNg+2jCTuld48spLHmzhhP49KaJphD6CGuxSpY/HKTHG/p0NF3 Eq4PHjUb0YMdDBWqZ+KYXgFmDK3mVsHpABmeRnMC6x0c9w00hbgDm9ygCDpYYGu/lbyD 1atLNqYv3O9DY9HuSburFd0jKe3N3r8ZGdSLj489tiIrrj2UYxRlXICzWcXC8QFlBvyq zfuw== 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=8WSkQTXnpgM2agkV1fR9FVD087EiMcU7/ktnfNZOFJQ=; b=GdlIdYMbefFj74pQ/W1Rg2YBmE7fqUMdHjZo/6jXbKNgeJ3Bi/DiyvQXA7aUxbGOVy U+ARAFWw2WlhKP/ugIUDOI1sY4PM8DfK+VgVyEZg0iUgy8cMPeBK4zP6htw1pjCi5lds b6L3oOYef4Baq4Xal4CHgM016jP+QW3dg7oTKKJqSY0JK2VexWwNBshIgV6aK+wiAhMl wCSbQcYwInaq6IS9JbeAlBCV5xu9n6KmpzE9WVJ5WvWO0nay7FN/S3gr8qqbcxqCVGxJ kZxH/FGgqEH3e0Ze4r07WNL7KEZw3Hn7zUzJdDoARGmcevbQdzo19seicisYRqHclpU9 XI4g== X-Gm-Message-State: AHYfb5h1G2Hj7Q1qSxdsCJHPx0lFZ/ZLzDg0lzJ5NkrMPfRvm9iwjmKG MEpokoVFIFHUkrTc8Fph6XzBbaHnYCE8 X-Google-Smtp-Source: ADKCNb6rT3EXvRVPkw64bA0TVL87d8232qOVDRcRFhry5uWtkaMXjPOiWhqrAw+a7kPna9uaHApUL6aaWngG9j2FdjA= X-Received: by 10.107.11.217 with SMTP id 86mr1751759iol.303.1503771034989; Sat, 26 Aug 2017 11:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Sat, 26 Aug 2017 11:10:14 -0700 (PDT) In-Reply-To: <150222067484.12279.1715829344429803452@ietfa.amsl.com> References: <150222067484.12279.1715829344429803452@ietfa.amsl.com> From: Justin Uberti Date: Sat, 26 Aug 2017 11:10:14 -0700 Message-ID: To: Robert Sparks Cc: gen-art@ietf.org, draft-ietf-rtcweb-jsep.all@ietf.org, "rtcweb@ietf.org" , ietf@ietf.org Content-Type: multipart/alternative; boundary="001a113f7dba5de4320557abfa73" Archived-At: Subject: Re: [rtcweb] Genart last call review of 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: Sat, 26 Aug 2017 18:10:40 -0000 --001a113f7dba5de4320557abfa73 Content-Type: text/plain; charset="UTF-8" Thanks for this careful review. A new version of the document (-22) has been posted which addresses almost all of these comments, with a few exceptions noted below. Diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-rtcweb-jsep-21&url2=draft-ietf-rtcweb-jsep-22&difftype=--html On Tue, Aug 8, 2017 at 12:31 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-rtcweb-jsep-21 > Reviewer: Robert Sparks > Review Date: 2017-08-08 > IETF LC End Date: 2017-08-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: Almost ready for publication as a Proposed Standard RFC, but with > issues that need to be addressed before publishing > > Major issues: > > The last paragraph of 5.1 needs more context. Why woudn't you expect the > re-offer to fail, given that you already know the peer is using the older > profile strings? It's not clear from the email list and proceedings how the > document ended up with this particular text. > > Minor issues: > > Second paragraph of 3.2, last sentence: at "these parameters or reject > them" - "these" and "them" have ambiguous antecedents. It's not clear if > you > are trying to point to the parameters that don't follow the earlier stated > rule, or all parameters. The sentence is complex. Splitting it up and > finding a way to avoid the need for the semicolon will likely make it > easier to say what you mean. > > Last paragraph on page 5 - first sentence: at "One way to mitigate this" - > "this" has an unclear antecedent. Did you mean "One way to reduce the > complexity of the application's responsibilities"? > > Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please > state precisely which fields you mean. > > Odd edge: The description createAnswer (in 4.1.7) leaves open the > possibility that the application could call createAnswer twice > (back-to-back with no intervening calls to other APIs) with different > values in the options parameter. Is this ok? If not, should there be > language that says not to do that somewhere? > > Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a > reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in > RFC5764. Assuming that this is only a reference error, then the last > sentence seems like a stray. It doesn't seem to be in the right context > ("this advertisement" doesn't cast back to the discussion of the two > profiles above it, which are both UDP only). Please clarify the sentence, > giving it the right context, or remove it. > > The fourth sentence of the second bullet of section 5.2.1 is confusing. (It > starts "It is RECOMMENDED that the ".) RFC3265 requires the > initial sess-id high-order bit to be zero. As written, this can be read to > say that setting that bit to zero is only RECOMMENDED, and that it's > possible to have sess-ids that are something other than 64 bits. You mean > to say "Do what 3265 says to do and make the lower 63 bits random". Here's > one possible replacement for the sentence: "RFC 3265 requires that the > high-order bit of the initial be zero. It is RECOMMENDED that the > remaining 63 bits be initially set to a cryptographically random value." > > The last paragraph of 5.3.1 prohibits the same attributes from generated > answers that are prohibited in generated offers. Consider adding text for > what to do if an offer shows up from a peer with some of those prohibited > attributes. > This is covered by the last paragraph on page 43: Note that these requirements are in some cases stricter than those of SDP. Implementations MUST be prepared to accept compliant SDP even if it would not conform to the requirements for generating SDP in this specification. > The second paragraph of section 5.4 is confusing. A slight restructuring of > the sentences would remove much of the potential confusion, I think. I > suggest replacing the first sentence (which is very complex) with this: > "After calling setLocalDescription, the application MAY modify the SDP to > reduce the capabilities in the offer before sending it to the far side, as > long as it remains a valid SDP offer and specifies a subset of what was in > the original offer. Likewise, an application that has received an offer > from a peer MAY modify the received SDP, subject to those same constraints, > before calling setRemoteDescription." > > The first paragraph of section 5.7.1 is simply restating requirements from > RFC4566. Restating normative requirements like that has led to interop > problems through unintended introduced ambiguity and spec maintenance > problems. Please consider rewriting the paragraph to say "RFC4566 says" and > avoid the 2119 keywords. > We considered this, but found that a) RFC4566 is clearly cited, and b) the actual restatement was very minor, really just affecting the discussion of the v= and o= lines. As a result we concluded that pointing the reader elsewhere just for those two lines did not seem like an improvement. > > On page 69, at "If the application attempt to transmit DTMF when using a > media format that does not have a corresponding telephone-event format, > this MUST result in an error". This sentence is out-of-place. The section > is about applying a remote description. If the document needs to retain the > sentence, it belongs off in some "processing media" section. In particular, > the current placement of text is confusing about what and when an error > could be returned, and it could be misread to say that an error should be > returned to the setRemoteDescription call. > > Nits: > > Section 1.2 second paragraph - "This was rejected based on a feeling". Can > you write something that speaks to consensus here? "Based on a feeling" > isn't quite right. Maybe "using the argument"? > > PeerConnection is used first at the next to last paragraph of section 3. > Please add a reference at that point. > > "LS" (lipsync) is first used at 4.1.2, with no context for what it is. > Please add a reference. > > The concept of a "pending local description" is used in sections 3.5.1, > 4.1.6, and 4.1.7 but isn't really explained until much later in the > document. Please provide forward references, or move a description of what > a pending description is earlier in the document. > > In 4.1.7 (create Answer) why would calling setLocalDescription cause the > answer to be a _pending_ local description. I think it's the full on local > description at that point, not a pending one? > > At 4.1.17's first paragraph: Why is "if parsed successfully" necessary to > call out? I suggest removing the phrase. > > 4.2.3 talks about setting direction properties, but the values that can be > set aren't called out (and even then only by inference from a list in an > example) in section 4.2.5. Should there be explicit pointers to the api doc > here? (And in section 4.2.6?) > > There are two paragraphs on page 50 that start "The next step is to". They > are both referring to the same step. I suggest combining the paragraphs. > > The 4th bullet on page 64 is ambiguous at "this m= section". It looks like > this bullet should just be merged with the previous bullet. > > The second paragraph of 6.8 starts "Next, ". I think it should start > "First, ". > > It's not clear what the "Or," in the first bullet on page 65 is referring > to. Are you trying to say "If the m= section is not new, and the ICE ufrag > and password values have changed" or something else? > The intent here is as stated, "if the m= section is not new and the values have changed". We discussed this but concluded that the meaning of the current text was clear. > > In the last paragraph of section 8 at "programmer MUST recognize". That is > not an appropriate use of 2119. I suggest "needs to be aware" instead of > "MUST recognize". > > Micro Nits: > > Suggested change to the first sentence of 1.1 > > OLD: > > The thinking behind WebRTC call setup has been to fully specify and > control the media plane, but to leave the signaling plane up to the > application as much as possible. > > New: > > WebRTC call setup has been designed to focus on controlling the media > plane, leaving signaling plane behavior up to the application as much as > possible. > > The first full bullet on page 18 has a sentence that starts "Note that when > considering". Please change that to simply "When considering". As written, > there is an implication that this is a consequence of something specified > somewhere else. > > The verb "surfaced" appears three times in the document without support or > definition. Can you replace them with simpler language? > > At the second to last sub-bullet at the end of page 66, please remove "note > that". The sentence is stronger without it. > > I noted these sections as particularly hard to read when going through the > document linearly. I don't have concrete suggestions for improvement, but > perhaps other eyes (if they agree the sections could use improvement) can > come up with something: > - First sentence of the first paragraph on page 19. > - 2nd sentence of the 4th paragraph on page 19. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113f7dba5de4320557abfa73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this careful review. A new version of the docum= ent (-22) has been posted which addresses almost all of these comments, wit= h a few exceptions noted below.


On Tue, Aug 8, 2017 at 12:31 PM, Robert Sparks &l= t;rjsparks@nostru= m.com> wrote:
Reviewer: Robert Sparks
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-rtcweb-jsep-21
Reviewer: Robert Sparks
Review Date: 2017-08-08
IETF LC End Date: 2017-08-11
IESG Telechat date: Not scheduled for a telechat

Summary: Almost ready for publication as a Proposed Standard RFC, but with<= br> issues that need to be addressed before publishing

Major issues:

The last paragraph of 5.1 needs more context. Why woudn't you expect th= e
re-offer to fail, given that you already know the peer is using the older profile strings? It's not clear from the email list and proceedings how= the
document ended up with this particular text.

Minor issues:

Second paragraph of 3.2, last sentence: at "these parameters or reject=
them" - "these" and "them" have ambiguous antecede= nts. It's not clear if you
are trying to point to the parameters that don't follow the earlier sta= ted
rule, or all parameters. The sentence is complex. Splitting it up and
finding a way to avoid the need for the semicolon will likely make it
easier to say what you mean.

Last paragraph on page 5 - first sentence: at "One way to mitigate thi= s" -
"this" has an unclear antecedent. Did you mean "One way to r= educe the
complexity of the application's responsibilities"?

Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. P= lease
state precisely which fields you mean.

Odd edge: The description createAnswer (in 4.1.7) leaves open the
possibility that the application could call createAnswer twice
(back-to-back with no intervening calls to other APIs) with different
values in the options parameter. Is this ok? If not, should there be
language that says not to do that somewhere?

Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a=
reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in=
RFC5764. Assuming that this is only a reference error, then the last
sentence seems like a stray. It doesn't seem to be in the right context=
("this advertisement" doesn't cast back to the discussion of = the two
profiles above it, which are both UDP only). Please clarify the sentence, giving it the right context, or remove it.

The fourth sentence of the second bullet of section 5.2.1 is confusing. (It=
starts "It is RECOMMENDED that the <sess-id>".) RFC3265 req= uires the
initial sess-id high-order bit to be zero. As written, this can be read to<= br> say that setting that bit to zero is only RECOMMENDED, and that it's possible to have sess-ids that are something other than 64 bits. You mean to say "Do what 3265 says to do and make the lower 63 bits random"= ;. Here's
one possible replacement for the sentence: "RFC 3265 requires that the=
high-order bit of the initial <sess-id> be zero. It is RECOMMENDED th= at the
remaining 63 bits be initially set to a cryptographically random value.&quo= t;

The last paragraph of 5.3.1 prohibits the same attributes from generated answers that are prohibited in generated offers. Consider adding text for what to do if an offer shows up from a peer with some of those prohibited attributes.


   Note that these requirements are in some cases stricter than those of
   SDP.  Implementations MUST be prepared to accept compliant SDP even
   if it would not conform to the requirements for generating SDP in=C2=A0<=
/pre>
   this specification.=C2=A0




The second paragraph of section 5.4 is confusing. A slight restructuring of=


the sentences would remove much of the potential confusion, I think. I

suggest replacing the first sentence (which is very complex) with this:

"After calling setLocalDescription, the application MAY modify the SDP=
 to

reduce the capabilities in the offer before sending it to the far side, as<=
br>
long as it remains a valid SDP offer and specifies a subset of what was in<=
br>
the original offer. Likewise, an application that has received an offer

from a peer MAY modify the received SDP, subject to those same constraints,=


before calling setRemoteDescription."



The first paragraph of section 5.7.1 is simply restating requirements from<=
br>
RFC4566. Restating normative requirements like that has led to interop

problems through unintended introduced ambiguity and spec maintenance

problems. Please consider rewriting the paragraph to say "RFC4566 says=
" and

avoid the 2119 keywords.

We considered =
this, but found that a) RFC4566 is clearly cited, and b) the actual restate=
ment was very minor, really just affecting the discussion of the v=3D and o=
=3D lines. As a result we concluded that pointing the reader elsewhere just=
 for those two lines did not seem like an improvement.
=C2=A0



On page 69, at "If the application attempt to transmit DTMF when using=
 a

media format that does not have a corresponding telephone-event format,

this MUST result in an error". This sentence is out-of-place. The sect=
ion

is about applying a remote description. If the document needs to retain the=


sentence, it belongs off in some "processing media" section. In p=
articular,

the current placement of text is confusing about what and when an error

could be returned, and it could be misread to say that an error should be
returned to the setRemoteDescription call.



Nits:



Section 1.2 second paragraph - "This was rejected based on a feeling&q=
uot;. Can

you write something that speaks to consensus here? "Based on a feeling=
"

isn't quite right. Maybe "using the argument"?



PeerConnection is used first at the next to last paragraph of section 3.
Please add a reference at that point.



"LS" (lipsync) is first used at 4.1.2, with no context for what i=
t is.

Please add a reference.



The concept of a "pending local description" is used in sections =
3.5.1,

4.1.6, and 4.1.7=C2=A0 but isn't really explained until much later in t=
he

document. Please provide forward references, or move a description of what<=
br>
a pending description is earlier in the document.



In 4.1.7 (create Answer) why would calling setLocalDescription cause the
answer to be a _pending_ local description. I think it's the full on lo=
cal

description at that point, not a pending one?



At 4.1.17's first paragraph: Why is "if parsed successfully" =
necessary to

call out? I suggest removing the phrase.



4.2.3 talks about setting direction properties, but the values that can be<=
br>
set aren't called out (and even then only by inference from a list in a=
n

example) in section 4.2.5. Should there be explicit pointers to the api doc=


here? (And in section 4.2.6?)



There are two paragraphs on page 50 that start "The next step is to&qu=
ot;. They

are both referring to the same step. I suggest combining the paragraphs.


The 4th bullet on page 64 is ambiguous at "this m=3D section". It=
 looks like

this bullet should just be merged with the previous bullet.



The second paragraph of 6.8 starts "Next, ". I think it should st=
art

"First, ".



It's not clear what the "Or," in the first bullet on page 65 =
is referring

to. Are you trying to say "If the m=3D section is not new, and the ICE=
 ufrag

and password values have changed" or something else?
<=
div>
The intent here is as stated, "if the m=3D section =
is not new and the values have changed". We discussed this but conclud=
ed that the meaning of the current text was clear.
=C2=A0



In the last paragraph of section 8 at "programmer MUST recognize"=
. That is

not an appropriate use of 2119. I suggest "needs to be aware" ins=
tead of

"MUST recognize".



Micro Nits:



Suggested change to the first sentence of 1.1



=C2=A0 OLD:



=C2=A0 =C2=A0 The thinking behind WebRTC call setup has been to fully speci=
fy and

control the media plane, but to leave the signaling plane up to the

application as much as possible.



=C2=A0 New:



=C2=A0 =C2=A0 WebRTC call setup has been designed to focus on controlling t=
he media

plane, leaving signaling plane behavior up to the application as much as
possible.



The first full bullet on page 18 has a sentence that starts "Note that=
 when

considering". Please change that to simply "When considering"=
;. As written,

there is an implication that this is a consequence of something specified
somewhere else.



The verb "surfaced" appears three times in the document without s=
upport or

definition. Can you replace them with simpler language?



At the second to last sub-bullet at the end of page 66, please remove "=
;note

that". The sentence is stronger without it.



I noted these sections as particularly hard to read when going through the<=
br>
document linearly. I don't have concrete suggestions for improvement, b=
ut

perhaps other eyes (if they agree the sections could use improvement) can
come up with something:

=C2=A0- First sentence of the first paragraph on page 19.

=C2=A0- 2nd sentence of the 4th paragraph on page 19.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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

--001a113f7dba5de4320557abfa73-- From nobody Sun Aug 27 13:25: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 62B4A13293B for ; Sun, 27 Aug 2017 13:25: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 K8PLoqYUoonD for ; Sun, 27 Aug 2017 13:25:25 -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 390C4132256 for ; Sun, 27 Aug 2017 13:25:25 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id k22so10825693iod.2 for ; Sun, 27 Aug 2017 13:25:25 -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=YN5p6IfJqNiHJV1xw3GoPkafMFjOKiFF+QUaCahjV6Q=; b=vgY6Sj4+6flricRjfyNHabJju3fB7VLkHgaZG/4t9TxMOrU3fvBB1dINbaR+8PMPPc BLdm217qIqMTGe4viU2ulWrIj4cymjdnmEs/wSwTHOjhvTncxil7FmXxFxKYdmIFIWFM 0ujLm8dLPhehzC1iOIKPio2zjhbzH++3D/01bEpNsKdejwa5Uyo9mzE6J/DbdABi370C 27YHR3u4cH4xmseA5ScTisO1TQ13tH+q/7jbI3jLqpnxS6cNH5UawyoGvX2YSXxGoxn/ bvWouvhWgybm5Y3WCOV2M6d9wSEBgZrl4rXrpIt04subhwBrDBAMeaCSLHbrDjDs8cjn ezBw== 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=YN5p6IfJqNiHJV1xw3GoPkafMFjOKiFF+QUaCahjV6Q=; b=OUDeZ2fA0rJNlkMP7JHw/r8kx1QL549hWFN21jAl577qAel5ttcPBUDbRcmJWLqghC Dqb7eG6v2rAADmPMG1jeVEIWifOkJZiOSTeLlfKLAkVY+vi2e2b1//7GvmP5OlvV8/vn HS0kWAcc385DJZG8qs1BllsFoKktskxclRrzmZjk2oVneZOv5o8VPo1hODqsP5DwbfzT MzzU13lJXJOcl1g1melQrfNsZ91IyAgRkQ31kLRq9MbzWGNktlphsNf3JBESF4whjb4T qhQ5vGlW9WQXAnQfExO5boKW4R5UxViw0jCMkLuXxEhlge7j2185Ag27Ka0NmJbkXtMc W66Q== X-Gm-Message-State: AHYfb5iIpgdqR9nBTQgPMbIqabDKOK64b98/LSLTMSSoHhRTckA24oWU B5XVPFqrYYYA2wmpSh811TfL/ZXhjBnx X-Google-Smtp-Source: ADKCNb6VqDJah9nycQn7J5n3x3X8tTGrqGOnb6DkTcp7gp0L5UfYuOvhan6yBJTDYZ/JSIuSwkQoRnJRj8EZKtqXf28= X-Received: by 10.107.142.132 with SMTP id q126mr4378298iod.316.1503865524089; Sun, 27 Aug 2017 13:25:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Sun, 27 Aug 2017 13:25:03 -0700 (PDT) In-Reply-To: <554c4448-4731-a92c-67b4-dbf86a681319@ericsson.com> References: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com> <554c4448-4731-a92c-67b4-dbf86a681319@ericsson.com> From: Justin Uberti Date: Sun, 27 Aug 2017 13:25:03 -0700 Message-ID: To: Magnus Westerlund Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05c32c5b16340557c1fa79" 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: Sun, 27 Aug 2017 20:25:27 -0000 --94eb2c05c32c5b16340557c1fa79 Content-Type: text/plain; charset="UTF-8" PTAL at https://github.com/juberti/draughts/pull/89 On Fri, Jul 21, 2017 at 12:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > > > 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, 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 >> ---------------------------------------------------------------------- >> >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 <+46%2010%20714%2082%2087> > Torshamnsgatan 23 | Mobile +46 73 0949079 <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c05c32c5b16340557c1fa79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jul 21, 2017 at 12:= 51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com&= gt; wrote:
=20 =20 =20



Den 2017-07-20 kl. = 08:25, skrev Justin Uberti:
=20
Thanks for your comments. Regarding #2, the document currently says the following: 

   Since u=
se 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, 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=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| Mob=
ile +46 73 0949079

            SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@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@ericsson.com
-----------------------------------------------------------------=
-----

  






--94eb2c05c32c5b16340557c1fa79--


From nobody Mon Aug 28 02:21:34 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 72008132358; Mon, 28 Aug 2017 02:21:26 -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 d43eUnNhhqEd; Mon, 28 Aug 2017 02:21:24 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 60CF31201F8; Mon, 28 Aug 2017 02:21:23 -0700 (PDT)
X-AuditID: c1b4fb3a-9e1d49c0000051a3-ee-59a3e09150e2
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.96.20899.190E3A95; Mon, 28 Aug 2017 11:21:21 +0200 (CEST)
Received: from [147.214.161.223] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 28 Aug 2017 11:21:21 +0200
To: Cullen Jennings 
CC: , , RTCWeb IETF , 
References: <150129017294.20667.17960314547810703.idtracker@ietfa.amsl.com>  <7AE0650C-9308-4BF0-992C-4204A8B68319@iii.ca>
From: Magnus Westerlund 
Message-ID: <661ac0f1-a2f4-b5b9-57bd-e68d3043fb95@ericsson.com>
Date: Mon, 28 Aug 2017 11:21:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <7AE0650C-9308-4BF0-992C-4204A8B68319@iii.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070809030702060907000504"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7iu7EB4sjDea90LHY176FyeLD+h+M FjP+TGS26Hl7g8Vi7b92dgdWjyVLfjJ5XD7/kTGAKYrLJiU1J7MstUjfLoEr42LLH7aCnT4V v/fPZWtg3OfaxcjBISFgInHwlW4XIxeHkMARRolTX++xQjhbGCUurZzG0sXIySEs0Mwo8emm NogtIqAscW7HXWYQm1mgUGLJsVmMEA0bGSXmff/HCpJgE7CQuPmjkQ3E5hWwl1j+uZ0dxGYR UJX4enoSWI2oQIzEz0uPWCBqBCVOznwCZnMKWElc3vGDCWQos0A3o8Ti58/AGoQEtCUamjrA bAkBJYnr866zTGAUmIWkfxaynllgF9pK3Jm7mxnC1pZYtvA1lC0u0fRlJVSNtcSMXwfZIGxF iSndD9khbFOJ10c/MkLYRhLv9jSyL2DkXMUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGEsH t/y22sF48LnjIUYBDkYlHt49pxZHCrEmlhVX5h5iVAGa82jD6guMUix5+XmpSiK8LbeB0rwp iZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTDKrf195lOYhG/B NeEGRmfRA9PfbnZQ+pas/Dr95ZYpmpG/1Rast96z8Noyvd/vxGx1lbhuiLOJMEeJG367a/Sv 2OtUzO90z9o3Z/kDL4exPjzwL+T8+qm8u/r7anYcP8sllnzc0l0qanL5otfdnZNFVue9euYg ufzzrtYjvGxsdnxN2oXbQvcpsRRnJBpqMRcVJwIAxvOL+q0CAAA=
Archived-At: 
Subject: Re: [rtcweb] Last Call:  (JavaScript Session Establishment Protocol) to Proposed Standard
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: Mon, 28 Aug 2017 09:21:26 -0000

--------------ms070809030702060907000504
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-GB

Good,

Then I am satisfied. I will do my best to timely review and comment on=20
text.

/Magnus


Den 2017-08-25 kl. 18:10, skrev Cullen Jennings:
> Magnus, we had been treating this as a LC comment and fully intend to f=
ix it.  Hoping for new text really soon.
>
>
>> On Aug 25, 2017, at 3:11 AM, Magnus Westerlund  wrote:
>>
>> Hi,
>>
>> I know the IETF last call is over. However, as I was on vacation durin=
g the whole last call, and my issue was known and noted since long before=
 the last call, I want to know what the plan is to do with the issue? I t=
hink it is bad process to proceed to IETF last call without addressing th=
e known issues. I did in person during Prague IETF note my concern to Ada=
m in his role as AD.
>>
>> So this concerns issue https://github.com/rtcweb-wg/jsep/issues/745 wh=
ich we have had ongoing discussion since before summer.
>>
>> My preferred way forward as it appears at least one of the editors thi=
nks what I suggested as solution, is that there are text changes to prima=
rily the first bullet in Section 3.6.2 to incorporate my suggested soluti=
on.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>>
>>
>> Den 2017-07-29 kl. 03:02, skrev The IESG:
>>> The IESG has received a request from the Real-Time Communication in
>>> WEB-browsers WG (rtcweb) to consider the following document: - 'JavaS=
cript
>>> 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 ma=
y be
>>> sent to iesg@ietf.org instead. In either case, please retain the begi=
nning 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 sessio=
n
>>>     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.
>>>
>>>
>>>
>>>
>> --=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
>> ----------------------------------------------------------------------=

>>
>>
>> _______________________________________________
>> 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
----------------------------------------------------------------------



--------------ms070809030702060907000504
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
SIb3DQEJBTEPFw0xNzA4MjgwOTIxMTdaMC8GCSqGSIb3DQEJBDEiBCCfEd9htqip66LP+LX5
5o+beB+5+qTReVLK5fWKZUxjMzBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAONgRbpvmcFW3/GUKXB4QrUqEXN6n3Ao1h9tChBjbGLa1urgR
Bp3GAluPumxxrp85Ckq7hktsPE5N/EHiGQwjVGRWnBpH3FgaBIlB9248o53cZB0o8Y7Uqfgj
ATWieALycyqmdaOzH4Tr8GNegGBlCXaHaOL9nv9nCb9cGVlIk34m922BVsG0eCI3ZkJWhj0x
/FAz4EQHAyPS8PVvwH1pkSN469TYC2bYyu0ph0tucQciIgJJLuI1OGXkkkYlOFNWzXJIfy8j
LvkkWTmYk55BTvYtuJuTQKjqP3LC97qJMX2XsOdwATQnaqldZXk3DLOAbPXg+fh5GXA3/N0y
8hI/fgAAAAAAAA==
--------------ms070809030702060907000504--


From nobody Tue Aug 29 09:35:36 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 E54DE1321D5 for ; Tue, 29 Aug 2017 09:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 wOSh4cTgIx8Y for ; Tue, 29 Aug 2017 09:35:31 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 DAE28132D59 for ; Tue, 29 Aug 2017 09:35:30 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id 40so11310388wrv.5 for ; Tue, 29 Aug 2017 09:35:30 -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=jFkDDJqoHB49q8LivL/upAEEIl+M8PPKRTbondIEwJc=; b=qYRESDUoD4/PzCTTv7j8/Fm73IPhVMvijooDzSy0ERwo0Er31REYj+kbcvP1Broz+4 F0zwMP9c0B475i5HZKXHrgLGEhd4xkV2sMb5K9kpoeuV5L4DVQRnjDl6tXEY4QGUvHMi cEJh+N25DljiTqkwo/3XsFc3jQqUL35RrnOMJpZNNn2g7eJqRfsU0+JlIFQP1P0eapOs Bu7egVY75EGOGZ7HURDSMUBjcl4u7BJ/TMI5Z6lWBy94dRQIXssnVZgYz772rOfYv23V CshxH/b5c5kRdEWtsDoKteLdJuWzTzrMdWqyeAQOmsRBOUdBxxWfCeuny2uLaCJLgvFJ j8CA==
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=jFkDDJqoHB49q8LivL/upAEEIl+M8PPKRTbondIEwJc=; b=CzQLFa3lW2QJVEk/s958PiYKL5fcmQu6+gwJDWP3RioEjC2m00krDUVchwws7IQWZu D69wgEECx5c+cCUxnMIe38nGTf6Nc8MTJbAVDjh7vD4Pt0Qt4aJ8aAvmFPGsTnr+f0iR EXaN/BWmvHeGQUzUK1ByhIEY59wthp1gsht9fT9tC5HUlOr5c8RBO2arUBi7ivD72blU bXMdCyZBXgLi6yV+b9ksR2nErzmjFOs8ngYxg8XR6WQI4pUJX6893YXmps7jDj22cbk1 5VnaBhlRkYJ+LdWM23n6NGs6OCGG6ov0ftvh+D3tiDbDP24ZiAzyldP4VbKO20F1v/wC HtMA==
X-Gm-Message-State: AHYfb5iPlSN8e1Ai52hvwDdVkZvahphQ1bXTf6z3y1kk0hf0ngiC2hqT u5K3aRXHye0ZAoevjM86UTlf3qZgOJopNAOkag==
X-Google-Smtp-Source: ADKCNb5DwSOxcEsAeubnUteI0B3anm3sOFTIVog+xbuZIR+nd00M5L/XGN7C55pTcHiQcsrXMNqAP1uyZgXoDgbAIiE=
X-Received: by 10.223.185.24 with SMTP id k24mr597323wrf.195.1504024528406; Tue, 29 Aug 2017 09:35:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.55 with HTTP; Tue, 29 Aug 2017 09:35:27 -0700 (PDT)
From: Taylor Brandstetter 
Date: Tue, 29 Aug 2017 09:35:27 -0700
Message-ID: 
To: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="f403045f5424c038910557e6ff27"
Archived-At: 
Subject: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 29 Aug 2017 16:35:34 -0000

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

Spawned from this thread on public-webrtc@w3.org:
https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

And raised as an issue on webrtc-pc's github page here:
https://github.com/w3c/webrtc-pc/issues/1563

The main issue, as I interpret it, is that BUNDLE is written with the
assumption that a transport can be identified by an address (the "BUNDLE
address"). An offer has a different meaning depending on whether a "shared
address" or "unique address" is used for the m= sections in the BUNDLE
group. But for ICE (and specifically trickle ICE), this assumption doesn't
hold. The address used by an ICE session may change from one offer to the
next, and if no candidates have been gathered yet, it may just be "0.0.0.0:9".
So there's no piece of information that can be used authoritatively to
match an ICE transport in one blob of SDP to an ICE transport in another
blob.

So, current implementations (at least Chrome/Firefox) follow a simplified
model of "transport follows m= section".  However, this behavior isn't
covered explicitly by the standard, and it has its downsides. It means if
the m= section associated with the current ICE transport is rejected, a new
ICE transport needs to be set up (or worse, things just stop working
completely).

Example:

*Offer (for already-established BUNDLE group)*

a=group:BUNDLE audio video
m=audio 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:video

*Answer*

a=group:BUNDLE video
m=audio 0 ...
c=IN IP4 0.0.0.0
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:baz
a=ice-pwd:buz
a=mid:video


Does this mean the existing "audio" ICE session continues to be used, or is
a new "video" one created? There's no established way for the offerer to
indicate what it desires, since there's no way to provide a "unique/shared
address" distinction. Where "unique" means "can fall back to using a
different transport," and "shared" means "will use the existing transport"
(assuming I've interpreted BUNDLE correctly; I may be reading between the
lines too much).

There are other ambiguous situations, but this is the one that started the
recent discussion.

Is this a real issue, or have I missed something? Given that there's now an
API for rejecting "m=" sections, it's no longer just a corner case, but
something possible with basic usage of the PeerConnection API. So it seems
worth addressing.

Some ideas for how to resolve it:

1. Require ufrags to be unique for different ICE sessions (JSEP already
requires this), and use the ufrag as the unique identifier. Then the BUNDLE
semantics could be used as-is, with "unique/shared ufrag" replacing
"unique/shared address".
2. For ICE, instead of using a "shared address" to mean "guaranteed to use
the existing BUNDLE transport", use "a=bundle-only" in subsequent offers.
If we were to do this, we may also need to allow the offerer BUNDLE-tag
section to be rejected; that's currently not supported (
https://github.com/cdh4u/draft-sdp-bundle/issues/22).
3. Since the "shared address" rules say "don't associate
TRANSPORT/IDENTICAL category attributes with m= sections other than the
offerer BUNDLE-tag section", we could interpret "m= section has no
transport attributes of its own" as "using shared address".

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



A=
nd raised as an issue on webrtc-pc's github page here:=C2=A0https://github.com/w3c/webrtc=
-pc/issues/1563

The main issue, as I interpret=
 it, is that BUNDLE is written with the assumption that a transport can be =
identified by an address (the "BUNDLE address"). An offer has a d=
ifferent meaning depending on whether a "shared address" or "=
;unique address" is used for the m=3D sections in the BUNDLE group. Bu=
t for ICE (and specifically trickle ICE), this assumption doesn't hold.=
 The address used by an ICE session may change from one offer to the next, =
and if no candidates have been gathered yet, it may just be "0.0.0.0:9". So there's no piece of infor=
mation that can be used authoritatively to match an ICE transport in one bl=
ob of SDP to an ICE transport in another blob.

So,=
 current implementations (at least Chrome/Firefox) follow a simplified mode=
l of "transport follows m=3D section".=C2=A0 However, this behavi=
or isn't covered explicitly by the standard, and it has its downsides. =
It means if the m=3D section associated with the current ICE transport is r=
ejected, a new ICE transport needs to be set up (or worse, things just stop=
 working completely).

Example:

Offer (for already-established BUNDLE group)

a=3Dgroup:BUNDLE audio video
m=3Daudio 9 ...
c=
=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:bar=

a=3Dmid:audio
...
m=3Dvideo 9 ...
=
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:ba=
r
a=3Dmid:video

Answer
=

a=3Dgroup:BUNDLE video
m=3Daudio 0 ...
c=
=3DIN IP4 0.0.0.0
a=3Dmid:audio
...
m=3Dv=
ideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:baz
a=3Dice-pwd:buz
a=3Dmid:video

Does this mean the existing "audio" ICE session conti=
nues to be used, or is a new "video" one created? There's no =
established way for the offerer to indicate what it desires, since there=
9;s no way to provide a "unique/shared address" distinction. Wher=
e "unique" means "can fall back to using a different transpo=
rt," and "shared" means "will use the existing transpor=
t" (assuming I've interpreted BUNDLE correctly; I may be reading b=
etween the lines too much).

There are other ambigu=
ous situations, but this is the one that started the recent discussion.

Is this a real issue, or have I missed something? Giv=
en that there's now an API for rejecting "m=3D" sections, it&=
#39;s no longer just a corner case, but something possible with basic usage=
 of the PeerConnection API. So it seems worth addressing.

Some ideas for how to resolve it:

1. Requi=
re ufrags to be unique for different ICE sessions (JSEP already requires th=
is), and use the ufrag as the unique identifier. Then the BUNDLE semantics =
could be used as-is, with "unique/shared ufrag" replacing "u=
nique/shared address".
2. For ICE, instead of using a "=
shared address" to mean "guaranteed to use the existing BUNDLE tr=
ansport", use "a=3Dbundle-only" in subsequent offers. If we =
were to do this, we may also need to allow the offerer BUNDLE-tag section t=
o be rejected; that's currently not supported (https://github.com/cdh4u/draft-sdp-=
bundle/issues/22).
3. Since the "shared address" ru=
les say "don't associate TRANSPORT/IDENTICAL category attributes w=
ith m=3D sections other than the offerer BUNDLE-tag section", we could=
 interpret "m=3D section has no transport attributes of its own" =
as "using shared address".


--f403045f5424c038910557e6ff27--


From nobody Tue Aug 29 09:46:03 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 30AF8132716 for ; Tue, 29 Aug 2017 09:46:02 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 9RoYym1lCfcS for ; Tue, 29 Aug 2017 09:46:00 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 EB1771321D5 for ; Tue, 29 Aug 2017 09:45:59 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id r203so32029856oih.0 for ; Tue, 29 Aug 2017 09:45:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=L5NTgJismcB33fb0JoBsKcl62QzAMvUMlydsat0T0UY=; b=DlkGd7Kyz+N2OEjhxF/unH9Vuxd98O2B/miWa/0F8M/oMd7emRgCgcPX1KK9fH48/K W0Rekhy8C7Z9P5y2DvUFudng8i1tBMzyBNMQB4AnNBTWpQ8dISHX7EEzRzQr+or/j+x3 3Nxw+imndid1mD+OE2qEIyDGXE+VJBkF8tstc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=L5NTgJismcB33fb0JoBsKcl62QzAMvUMlydsat0T0UY=; b=uenWU7DyfcjhJweUEt6oo9hHl07nMYYk+lH2td6RY0OBtXiyg6CeGuAAb+ruLGpYhJ SXhnmz25ou6xDWMiIFSSihzo4q7ynqhEHQm7z7uS0Fs2MPjUEfZ44/n84fnalYQQjI8O kstjNG3uPCmrNWojWvuNudiuWr1EbJ0yvxCMa66HntowAfvkmR792wjimBkIDmsImkB/ yvrxRTpcXWUVBN30kvQjZIo/x8YwQLo25MPMe48efSYmgUiIxpc2er0q45sRFOt+HQPK CX5NUMNQDwfijLnuisQxmrm5dtm2eNqOn0y1NXH3yW7nO7o2bAgrtvqTkFlAdtg6EM9O 6dUA==
X-Gm-Message-State: AHYfb5gm5ZPFF4GWTFWk9UxB4zoACvC8OfPZREd+memsUWdf8LJodndo TIR6yg67Rqce7MydwOJNUA==
X-Google-Smtp-Source: ADKCNb7PjErEEexW4E2A1HWvgWeGIqqKW3RB+Pr5Ta7+cpje5dDmyOLlCxW4qqMQTiGjfg5qO/eR5Q==
X-Received: by 10.202.197.14 with SMTP id v14mr833825oif.118.1504025158903; Tue, 29 Aug 2017 09:45:58 -0700 (PDT)
Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id a9sm3590102oii.11.2017.08.29.09.45.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 09:45:58 -0700 (PDT)
To: Taylor Brandstetter , RTCWeb IETF 
References: 
From: Byron Campen 
Message-ID: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>
Date: Tue, 29 Aug 2017 11:45:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 29 Aug 2017 16:46:02 -0000

On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
> Some ideas for how to resolve it:
>
> 1. Require ufrags to be unique for different ICE sessions (JSEP 
> already requires this), and use the ufrag as the unique identifier. 
> Then the BUNDLE semantics could be used as-is, with "unique/shared 
> ufrag" replacing "unique/shared address".

     I think this is our best option. It should allow trickle ICE to 
work as well as anything else. We might still want to do some of the 
below in addition.

> 2. For ICE, instead of using a "shared address" to mean "guaranteed to 
> use the existing BUNDLE transport", use "a=bundle-only" in subsequent 
> offers. If we were to do this, we may also need to allow the offerer 
> BUNDLE-tag section to be rejected; that's currently not supported 
> (https://github.com/cdh4u/draft-sdp-bundle/issues/22).

     This does not help clarify things when the offerer changes the 
BUNDLE tag (disable, remove from BUNDLE, make something else the 
BUNDLE-tag, etc).

> 3. Since the "shared address" rules say "don't associate 
> TRANSPORT/IDENTICAL category attributes with m= sections other than 
> the offerer BUNDLE-tag section", we could interpret "m= section has no 
> transport attributes of its own" as "using shared address".

     I don't think this helps when the offerer changes the BUNDLE-tag 
either.

Best regards,
Byron Campen


From nobody Tue Aug 29 23:11:17 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 902C31320DC for ; Tue, 29 Aug 2017 23:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 qxjTNUTwqcxf for ; Tue, 29 Aug 2017 23:11:13 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 DA265126B71 for ; Tue, 29 Aug 2017 23:11:12 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id a77so24081438qkb.1 for ; Tue, 29 Aug 2017 23:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=szq+UnrEFzbj5nnVKKcb0SkmOxSK+aInWFyWDXkippk=; b=D92QfglmbrBptjKPa7/BU2J/QzvKsNvuvOc3G4BH98liBRbOeCU6ramHQqxvpJXjEa SgsS1VJLgaHVDd9X6diAD+HvBkV67+/nezN3K7qYv5sCE0XMxD5FndbjcaOFKVcIcMPR CrrgjIKokKiJr+9I687sof28VVGn9SvXg7q/igxMyZ5MXE0IIn5/6D8XrvvaijRF+lHy zOU8xe8BBHkBhAil8wYS0+IySZ3KZMGqL7y7uHTNQkWwjssRiCDyiVJVv1U3siwCxci7 hUjQuzGySQodwCVZ0xhLanK2tvPoGOTCc8SDr8lg4WYhzN2/Am0u4f2RZWQunhlUkhMZ DXCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=szq+UnrEFzbj5nnVKKcb0SkmOxSK+aInWFyWDXkippk=; b=THBmmDaUYX9PVXNojA0BFKZN7AMXfGbQ8LYjtO0U407x/WrQ84ZTG0RzyPSr4WDg00 thWrM3o4f3434zYwvnSEoMvTGPwKMFWQO4HmwaizGi/AFy2ucz+n0jRwfCE3dtilZecC gvudDwNDzvO1Yt2OfhqfNcOFu8j6kg0qGo3TeyWNXvvI+KR1ryKy6t9opKlgKGkpja69 D4TYfsBcvaUn8rjm71sQPQ+E3bjkpiFWL9CSSdJQCJcpTyy2G3w6Mi6La80Ioh+aIJe5 0PB21z3HeuKeLukLC9yLIudRT0Be0RRyE5+X1/1U0+uLhUtZ8dmE9l3xDYnRqIJ9Z+39 N9aw==
X-Gm-Message-State: AHYfb5hXWNoRCljjuVDoHjUKLH4Esi4Z0BNT6WrflVkPUpIAcWDG5XBd JNZVgRgcyiUzATp278Zw6yZFwY/izPiiWu8=
X-Google-Smtp-Source: ADKCNb7jXt/8l6HLvzmWvoy8uagB00+x0febCuwUHIwivJ4prKQEKFE9Xckw4BZyg8ctYGbHmTdAKJPOk/wUl7Rthu0=
X-Received: by 10.55.77.204 with SMTP id a195mr9301540qkb.141.1504073471860; Tue, 29 Aug 2017 23:11:11 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Peter Thatcher 
Date: Wed, 30 Aug 2017 06:10:59 +0000
Message-ID: 
To: Taylor Brandstetter , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a114881aa02267a0557f265e3"
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 06:11:15 -0000

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

On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter 
wrote:

> Spawned from this thread on public-webrtc@w3.org:
> https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html
>
> And raised as an issue on webrtc-pc's github page here:
> https://github.com/w3c/webrtc-pc/issues/1563
>
> The main issue, as I interpret it, is that BUNDLE is written with the
> assumption that a transport can be identified by an address (the "BUNDLE
> address"). An offer has a different meaning depending on whether a "shared
> address" or "unique address" is used for the m= sections in the BUNDLE
> group. But for ICE (and specifically trickle ICE), this assumption doesn't
> hold. The address used by an ICE session may change from one offer to the
> next, and if no candidates have been gathered yet, it may just be "
> 0.0.0.0:9". So there's no piece of information that can be used
> authoritatively to match an ICE transport in one blob of SDP to an ICE
> transport in another blob.
>

It does seem like a serious oversight that BUNDLE is written in terms of
using addresses as identifiers when such addresses don't exist when doing
trickle ICE.  That means (BUNDLE + trickle ICE) may have lots of things
undefined.

It seems like we need to define an ID for (BUNDLE + trickle ICE), either by
saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE by
saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes more
sense.


>
> So, current implementations (at least Chrome/Firefox) follow a simplified
> model of "transport follows m= section".  However, this behavior isn't
> covered explicitly by the standard, and it has its downsides. It means if
> the m= section associated with the current ICE transport is rejected, a new
> ICE transport needs to be set up (or worse, things just stop working
> completely).
>
> Example:
>
> *Offer (for already-established BUNDLE group)*
>
> a=group:BUNDLE audio video
> m=audio 9 ...
> c=IN IP4 0.0.0.0
> a=ice-ufrag:foo
> a=ice-pwd:bar
> a=mid:audio
> ...
> m=video 9 ...
> c=IN IP4 0.0.0.0
> a=ice-ufrag:foo
> a=ice-pwd:bar
> a=mid:video
>
> *Answer*
>
> a=group:BUNDLE video
> m=audio 0 ...
> c=IN IP4 0.0.0.0
> a=mid:audio
> ...
> m=video 9 ...
> c=IN IP4 0.0.0.0
> a=ice-ufrag:baz
> a=ice-pwd:buz
> a=mid:video
>
>
> Does this mean the existing "audio" ICE session continues to be used, or
> is a new "video" one created? There's no established way for the offerer to
> indicate what it desires, since there's no way to provide a "unique/shared
> address" distinction. Where "unique" means "can fall back to using a
> different transport," and "shared" means "will use the existing transport"
> (assuming I've interpreted BUNDLE correctly; I may be reading between the
> lines too much).
>
>
So let me see if I understand this...  First, it's only for re-offer cases,
right?
In that case, the re-offer would like to say one of the following?

1.  (Shared) "We're currently sending contents CA and CB over transport TA;
let's keep doing that;  but if you want to stop sending CA, let's keep
sending CB over TA".

or

2.  (Unique) "We're currently sending contents CA and CB over transport TA;
let's keep doing that;  but if you want to stop sending CA, throw away TA
and let's make a new TB and send CB over that".


But right now all the re-offerer can say is "We're currently sending
contents CA and CB over transport TA; let's keep doing that;  if you reject
CA ... I don't know; please don't do that".


There are other ambiguous situations, but this is the one that started the
> recent discussion.
>
> Is this a real issue, or have I missed something? Given that there's now
> an API for rejecting "m=" sections, it's no longer just a corner case, but
> something possible with basic usage of the PeerConnection API. So it seems
> worth addressing.
>

> Some ideas for how to resolve it:
>
> 1. Require ufrags to be unique for different ICE sessions (JSEP already
> requires this), and use the ufrag as the unique identifier. Then the BUNDLE
> semantics could be used as-is, with "unique/shared ufrag" replacing
> "unique/shared address".
>

This seems like a good approach.  We're already using ufrag as an ICE
session identifier in trickle ICE to handle ICE restart edge cases.   And
there might be lots of edge cases around the problem of not being able to
identify transports with addresses.


> 2. For ICE, instead of using a "shared address" to mean "guaranteed to use
> the existing BUNDLE transport", use "a=bundle-only" in subsequent offers.
> If we were to do this, we may also need to allow the offerer BUNDLE-tag
> section to be rejected; that's currently not supported (
> https://github.com/cdh4u/draft-sdp-bundle/issues/22).
> 3. Since the "shared address" rules say "don't associate
> TRANSPORT/IDENTICAL category attributes with m= sections other than the
> offerer BUNDLE-tag section", we could interpret "m= section has no
> transport attributes of its own" as "using shared address".
>

Another option might be to define an "a=ice-id" just like we have an
"a=dtls-id".   When using ICE, that can function as the ID instead of the
address.  Or we could go with "a=transport-id" and just have an ID for the
transport that works for ICE and non-ICE and we could rewrite everything in
BUNDLE that relies on addresses for IDs and use the a=transport-id
instead.  Would that work?


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

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




On Tue=
, Aug 29, 2017 at 9:35 AM Taylor Brandstetter <deadbeef@google.com> wrote:
Spawned from this thread on public-webrtc@w3.org: https://lists.w3.org/Archives/Public/public-webrtc/20=
17Aug/0076.html

And raised as an issue on =
webrtc-pc's github page here:=C2=A0https://github.com/w3c/webrtc-pc/iss=
ues/1563

The main issue, as I interpret it, is=
 that BUNDLE is written with the assumption that a transport can be identif=
ied by an address (the "BUNDLE address"). An offer has a differen=
t meaning depending on whether a "shared address" or "unique=
 address" is used for the m=3D sections in the BUNDLE group. But for I=
CE (and specifically trickle ICE), this assumption doesn't hold. The ad=
dress used by an ICE session may change from one offer to the next, and if =
no candidates have been gathered yet, it may just be "0.0.0.0:9". So there's no piece=
 of information that can be used authoritatively to match an ICE transport =
in one blob of SDP to an ICE transport in another blob.

It does seem like a serious oversight that BUNDLE =
is written in terms of using addresses as identifiers when such addresses d=
on't exist when doing trickle ICE.=C2=A0 That means (BUNDLE=C2=A0+ tric=
kle ICE) may have lots of things undefined.

It see=
ms like we need to define an ID for (BUNDLE=C2=A0+ trickle ICE), either by =
saying in BUNDLE "when using trickle ICE, the ID is X" or in tric=
kle ICE by saying "when BUNDLing, the ID is "X.=C2=A0 I think put=
ting in BUNDLE makes more sense. =C2=A0
=C2=A0

So, current implemen=
tations (at least Chrome/Firefox) follow a simplified model of "transp=
ort follows m=3D section".=C2=A0 However, this behavior isn't cove=
red explicitly by the standard, and it has its downsides. It means if the m=
=3D section associated with the current ICE transport is rejected, a new IC=
E transport needs to be set up (or worse, things just stop working complete=
ly).

Example:

Offer (f=
or already-established BUNDLE group)

a=3Dgroup=
:BUNDLE audio video
m=3Daudio 9 ...
c=3DIN IP4 0.0.0.0<=
br>
a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid=
:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0=

a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmi=
d:video

Answer

a=
=3Dgroup:BUNDLE video
m=3Daudio 0 ...
c=3DIN IP4 0.0.0.=
0
a=3Dmid:audio
...
m=3Dvideo 9 ...
=

c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:baz
a=3Dice-p=
wd:buz
a=3Dmid:video


Does=
 this mean the existing "audio" ICE session continues to be used,=
 or is a new "video" one created? There's no established way =
for the offerer to indicate what it desires, since there's no way to pr=
ovide a "unique/shared address" distinction. Where "unique&q=
uot; means "can fall back to using a different transport," and &q=
uot;shared" means "will use the existing transport" (assumin=
g I've interpreted BUNDLE correctly; I may be reading between the lines=
 too much).


So l=
et me see if I understand this...=C2=A0 First, it's only for re-offer c=
ases, right?=C2=A0
In that case, the re-offer would like to say o=
ne of the following?

1. =C2=A0(Shared) "We=
9;re currently sending contents CA and CB over transport TA; let's keep=
 doing that; =C2=A0but if you want to stop sending CA, let's keep sendi=
ng CB over TA".

or=C2=A0

=

2. =C2=A0(Unique) "We're currently sending contents CA a=
nd CB over transport TA; let's keep doing that; =C2=A0but if you want t=
o stop sending CA, throw away TA and let's make a new TB and send CB ov=
er that".


But right now all the re-offerer can say is &quo=
t;We're currently sending contents CA and CB over transport TA; let'=
;s keep doing that; =C2=A0if you reject CA ... I don't know; please don=
't do that".


There are other ambiguous situa=
tions, but this is the one that started the recent discussion.
Is this a real issue, or have I missed something? Given that t=
here's now an API for rejecting "m=3D" sections, it's no =
longer just a corner case, but something possible with basic usage of the P=
eerConnection API. So it seems worth addressing.

Some idea=
s for how to resolve it:

1. Require ufrags to be u=
nique for different ICE sessions (JSEP already requires this), and use the =
ufrag as the unique identifier. Then the BUNDLE semantics could be used as-=
is, with "unique/shared ufrag" replacing "unique/shared addr=
ess".

This seems like a go=
od approach.=C2=A0 We're already using ufrag as an ICE session identifi=
er in trickle ICE to handle ICE restart edge cases. =C2=A0 And there might =
be lots of edge cases around the problem of not being able to identify tran=
sports with addresses. =C2=A0
=C2=A0
2. For ICE, instead of using a "shared a=
ddress" to mean "guaranteed to use the existing BUNDLE transport&=
quot;, use "a=3Dbundle-only" in subsequent offers. If we were to =
do this, we may also need to allow the offerer BUNDLE-tag section to be rej=
ected; that's currently not supported (https://github.com/cdh4u/=
draft-sdp-bundle/issues/22).
3. Since the "shared addres=
s" rules say "don't associate TRANSPORT/IDENTICAL category at=
tributes with m=3D sections other than the offerer BUNDLE-tag section"=
, we could interpret "m=3D section has no transport attributes of its =
own" as "using shared address".

Another option might be to define an "a=3Dice-id"=
 just like we have an "a=3Ddtls-id". =C2=A0 When using ICE, that =
can function as the ID instead of the address.=C2=A0 Or we could go with &q=
uot;a=3Dtransport-id" and just have an ID for the transport that works=
 for ICE and non-ICE and we could rewrite everything in BUNDLE that relies =
on addresses for IDs and use the a=3Dtransport-id instead.=C2=A0 Would that=
 work?
=C2=A0

_______________________________________________

rtcweb mailing list

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




--001a114881aa02267a0557f265e3--


From nobody Wed Aug 30 02:52:03 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 1406A132D46 for ; Wed, 30 Aug 2017 02:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level: 
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=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 Bh8P6j8F8FeD for ; Wed, 30 Aug 2017 02:51:59 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 70931132CEB for ; Wed, 30 Aug 2017 02:51:59 -0700 (PDT)
X-AuditID: c1b4fb3a-617ff700000051a3-fa-59a68abdc7c7
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EF.55.20899.DBA86A95; Wed, 30 Aug 2017 11:51:57 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 11:51:57 +0200
From: Christer Holmberg 
To: Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKcu3QA
Date: Wed, 30 Aug 2017 09:51:56 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_D5CC65B6208F8christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ru7ermWRBtte6lpcXvGQ1WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAldE3eRtjwdroiiNbfzA3MC727WLk4JAQMJF4 fsC2i5GLQ0jgCKPE9H0X2CGcJYwSzbO/sYMUsQlYSHT/0+5i5OQQEfCRePXnBzOILSzgKHHs xDywEhEBJ4lfDdEQJUYSiyceYwGxWQRUJc6suABm8wpYS6yftYQJxBYSCJBYv/YVK4jNKRAo MXHreUYQm1FATOL7qTVgNcwC4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VZK2ogJ7Eu/2eEGFF ifanDYwQrQkSf/5sZINYKyhxcuYTlgmMIrOQTJ2FpGwWkjKIuIHE+3PzmSFsbYllC19D2foS G7+cZYSwrSU+PP3BhKxmASPHKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAODu45bfVDsaD zx0PMQpwMCrx8DIULosUYk0sK67MPcQowcGsJMKb1QAU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgbHJ6O205/xlz/bs9sm5Y/TWY9uGtR+2mOgK6FtP e7TaZecaU1flrQGnkst1t9lWLCreO4khsfe4aXD1BrYLx6Lm2mU/YNCfXvUq/HFt1r6Np8+K HDLhOPXnrn7jHs2wVfv5VvlwLX1nvDfidXlVZdLyV3tC+y8cVb5gIfps+8KSTau2MC38d8xX iaU4I9FQi7moOBEAyHEA+68CAAA=
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 09:52:02 -0000

--_000_D5CC65B6208F8christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

Before I go deeper into this, a question for clarification:

You talk about =93audio=94 ICE session and =93video=94 ICE session.

Once the BUNDLE group has been established, you only have one ICE session (=
let=92s call it the =93bundle=94 ICE session), don=92t you?

So, when the audio is rejected (see your example) you would continue using =
the =93bundle=94 ICE session for video, since the video is still part of th=
e BUNDLE group. Or?

Regards,

Christer





From: rtcweb > on b=
ehalf of Taylor Brandstetter >
Date: Tuesday 29 August 2017 at 19:35
To: "rtcweb@ietf.org" >
Subject: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Spawned from this thread on public-webrtc@w3.org: https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

And raised as an issue on webrtc-pc's github page here: https://github.com/=
w3c/webrtc-pc/issues/1563

The main issue, as I interpret it, is that BUNDLE is written with the assum=
ption that a transport can be identified by an address (the "BUNDLE address=
"). An offer has a different meaning depending on whether a "shared address=
" or "unique address" is used for the m=3D sections in the BUNDLE group. Bu=
t for ICE (and specifically trickle ICE), this assumption doesn't hold. The=
 address used by an ICE session may change from one offer to the next, and =
if no candidates have been gathered yet, it may just be "0.0.0.0:9". So there's no piece of information that can be used authoritati=
vely to match an ICE transport in one blob of SDP to an ICE transport in an=
other blob.

So, current implementations (at least Chrome/Firefox) follow a simplified m=
odel of "transport follows m=3D section".  However, this behavior isn't cov=
ered explicitly by the standard, and it has its downsides. It means if the =
m=3D section associated with the current ICE transport is rejected, a new I=
CE transport needs to be set up (or worse, things just stop working complet=
ely).

Example:

Offer (for already-established BUNDLE group)

a=3Dgroup:BUNDLE audio video
m=3Daudio 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:video

Answer

a=3Dgroup:BUNDLE video
m=3Daudio 0 ...
c=3DIN IP4 0.0.0.0
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:baz
a=3Dice-pwd:buz
a=3Dmid:video


Does this mean the existing "audio" ICE session continues to be used, or is=
 a new "video" one created? There's no established way for the offerer to i=
ndicate what it desires, since there's no way to provide a "unique/shared a=
ddress" distinction. Where "unique" means "can fall back to using a differe=
nt transport," and "shared" means "will use the existing transport" (assumi=
ng I've interpreted BUNDLE correctly; I may be reading between the lines to=
o much).

There are other ambiguous situations, but this is the one that started the =
recent discussion.

Is this a real issue, or have I missed something? Given that there's now an=
 API for rejecting "m=3D" sections, it's no longer just a corner case, but =
something possible with basic usage of the PeerConnection API. So it seems =
worth addressing.

Some ideas for how to resolve it:

1. Require ufrags to be unique for different ICE sessions (JSEP already req=
uires this), and use the ufrag as the unique identifier. Then the BUNDLE se=
mantics could be used as-is, with "unique/shared ufrag" replacing "unique/s=
hared address".
2. For ICE, instead of using a "shared address" to mean "guaranteed to use =
the existing BUNDLE transport", use "a=3Dbundle-only" in subsequent offers.=
 If we were to do this, we may also need to allow the offerer BUNDLE-tag se=
ction to be rejected; that's currently not supported (https://github.com/cd=
h4u/draft-sdp-bundle/issues/22).
3. Since the "shared address" rules say "don't associate TRANSPORT/IDENTICA=
L category attributes with m=3D sections other than the offerer BUNDLE-tag =
section", we could interpret "m=3D section has no transport attributes of i=
ts own" as "using shared address".

--_000_D5CC65B6208F8christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,







Before I go deeper into this, a question for clarification:







You talk about =93audio=94 ICE session and =93video=94 ICE session.






Once the BUNDLE group has been established, you only have one ICE sess=
ion (let=92s call it the =93bundle=94 ICE session), don=92t you?







So, when the audio is rejected (see your example) you would continue u=
sing the =93bundle=94 ICE session for video, since the video is still part =
of the BUNDLE group. Or?







Regards,







Christer





























From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Taylo=
r Brandstetter <deadbeef@google.c=
om>

Date: Tuesday 29 August 2017 at 19:=
35

To: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: [rtcweb] Ambiguities with =
BUNDLE when used with ICE?



























The main issue, as I interpret it, is that BUNDLE is written with the =
assumption that a transport can be identified by an address (the "BUND=
LE address"). An offer has a different meaning depending on whether a =
"shared address" or "unique address" is used
 for the m=3D sections in the BUNDLE group. But for ICE (and specifically t=
rickle ICE), this assumption doesn't hold. The address used by an ICE sessi=
on may change from one offer to the next, and if no candidates have been ga=
thered yet, it may just be "0.0.0.0:9=
".
 So there's no piece of information that can be used authoritatively to mat=
ch an ICE transport in one blob of SDP to an ICE transport in another blob.=








So, current implementations (at least Chrome/Firefox) follow a simplif=
ied model of "transport follows m=3D section".  However, thi=
s behavior isn't covered explicitly by the standard, and it has its downsid=
es. It means if the m=3D section associated with the
 current ICE transport is rejected, a new ICE transport needs to be set up =
(or worse, things just stop working completely).







Example:







Offer (for already-established BUNDLE group)







a=3Dgroup:BUNDLE audio video


m=3Daudio 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:foo


a=3Dice-pwd:bar


a=3Dmid:audio


...


m=3Dvideo 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:foo


a=3Dice-pwd:bar


a=3Dmid:video







Answer







a=3Dgroup:BUNDLE video


m=3Daudio 0 ...


c=3DIN IP4 0.0.0.0




a=3Dmid:audio


...


m=3Dvideo 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:baz


a=3Dice-pwd:buz


a=3Dmid:video












Does this mean the existing "audio" ICE session continues to=
 be used, or is a new "video" one created? There's no established=
 way for the offerer to indicate what it desires, since there's no way to p=
rovide a "unique/shared address" distinction. Where
 "unique" means "can fall back to using a different transpor=
t," and "shared" means "will use the existing transport=
" (assuming I've interpreted BUNDLE correctly; I may be reading betwee=
n the lines too much).







There are other ambiguous situations, but this is the one that started=
 the recent discussion.







Is this a real issue, or have I missed something? Given that there's n=
ow an API for rejecting "m=3D" sections, it's no longer just a co=
rner case, but something possible with basic usage of the PeerConnection AP=
I. So it seems worth addressing.







Some ideas for how to resolve it:







1. Require ufrags to be unique for different ICE sessions (JSEP alread=
y requires this), and use the ufrag as the unique identifier. Then the BUND=
LE semantics could be used as-is, with "unique/shared ufrag" repl=
acing "unique/shared address".


2. For ICE, instead of using a "shared address" to mean &quo=
t;guaranteed to use the existing BUNDLE transport", use "a=3Dbund=
le-only" in subsequent offers. If we were to do this, we may also need=
 to allow the offerer BUNDLE-tag section to be rejected; that's
 currently not supported (https://github.com/cdh4u/draft-sdp-bundle/issues/22).

3. Since the "shared address" rules say "don't associat=
e TRANSPORT/IDENTICAL category attributes with m=3D sections other than the=
 offerer BUNDLE-tag section", we could interpret "m=3D section ha=
s no transport attributes of its own" as "using shared address&qu=
ot;.











--_000_D5CC65B6208F8christerholmbergericssoncom_--


From nobody Wed Aug 30 03:18:27 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 C066B132E17 for ; Wed, 30 Aug 2017 03:18:25 -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 9g1FwfkdQGVR for ; Wed, 30 Aug 2017 03:18:24 -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 CCBBF132E16 for ; Wed, 30 Aug 2017 03:18:23 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-31-59a690ed39b2
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.EE.21299.DE096A95; Wed, 30 Aug 2017 12:18:21 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 12:18:21 +0200
From: Christer Holmberg 
To: Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgA=
Date: Wed, 30 Aug 2017 10:18:20 +0000
Message-ID: 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>
In-Reply-To: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <69FEA9F9AFA7F14BB3BADCD3ACD89EB7@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7lu7bCcsiDXYvMLBYeK+VxeLyioes Fmv/tbM7MHss2FTqsWTJTyaPvgNdrAHMUVw2Kak5mWWpRfp2CVwZUzf0shS84K+4c+oxYwPj G54uRk4OCQETiS0n3jB2MXJxCAkcYZR4u/4eM4SzhFFi6cLFQBkODjYBC4nuf9ogDSICRRJn jm1hArGFBRwljp2Yxw5SIiLgJPGrIRqixEqi4/wCRhCbRUBVYveWu2DlvALWEss+7mCCGN/K KHH43UqwBKeAvcTneUuZQWxGATGJ76fWgMWZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xguwV FdCTeLffEyKsKPHx1T5GiFY9iRtTp7BB2NYSXY3rmSFsbYllC18zQ9wjKHFy5hOWCYxis5Bs m4WkfRaS9llI2mchaV/AyLqKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzDODm75rbqD8fIb x0OMAhyMSjy814uXRQqxJpYVV+YeYpTgYFYS4e3uAwrxpiRWVqUW5ccXleakFh9ilOZgURLn ddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAKHTVyiZT/f6iP09Ut19cut+i+ea8Z1VbXp96/Cz9 3sJ8p7cd8xNnzt682G062+be/NJJTmpNvPLBRmf9zSZ8mfK7vXSvkOSblTpHrx4/vEZ+zSr5 uDMGm7dOqgzQnJ+qoPv/jrr3tMtVYVYuv6fqlm77EfysncOrlW/F5XUuX90txD/+9g0RYFBi Kc5INNRiLipOBAB1c2AKrwIAAA==
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 10:18:25 -0000

Hi,

Maybe I=B9m missing something, but I fail to see what the problem is.

If the BUNDLE-tag section is changed (e.g., because the current BUNDLE-tag
section m- line is rejected) you simply include the TRANSPORT/IDENTICAL
category attributes in the new BUNDLE-tag section m- line.

Regards,

Christer





On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"
 wrote:

>
>
>On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
>> Some ideas for how to resolve it:
>>
>> 1. Require ufrags to be unique for different ICE sessions (JSEP
>> already requires this), and use the ufrag as the unique identifier.
>> Then the BUNDLE semantics could be used as-is, with "unique/shared
>> ufrag" replacing "unique/shared address".
>
>     I think this is our best option. It should allow trickle ICE to
>work as well as anything else. We might still want to do some of the
>below in addition.
>
>> 2. For ICE, instead of using a "shared address" to mean "guaranteed to
>> use the existing BUNDLE transport", use "a=3Dbundle-only" in subsequent
>> offers. If we were to do this, we may also need to allow the offerer
>> BUNDLE-tag section to be rejected; that's currently not supported
>> (https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>
>     This does not help clarify things when the offerer changes the
>BUNDLE tag (disable, remove from BUNDLE, make something else the
>BUNDLE-tag, etc).
>
>> 3. Since the "shared address" rules say "don't associate
>> TRANSPORT/IDENTICAL category attributes with m=3D sections other than
>> the offerer BUNDLE-tag section", we could interpret "m=3D section has no
>> transport attributes of its own" as "using shared address".
>
>     I don't think this helps when the offerer changes the BUNDLE-tag
>either.
>
>Best regards,
>Byron Campen
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Wed Aug 30 05:52:47 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 1641E1331E3 for ; Wed, 30 Aug 2017 05:52:46 -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=mozilla.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 w8rsVDhG-m-H for ; Wed, 30 Aug 2017 05:52:41 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 4DA5C1331D9 for ; Wed, 30 Aug 2017 05:52:41 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id r203so50223861oih.0 for ; Wed, 30 Aug 2017 05:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=CnHf8sQNpieD64xbjP7bQVWpkNeuhs0mpWrzD/iOuj0=; b=gFujX6GCIPxbR9ldw66HDFNojPjV1TP4t5mfxAlLu9rHfaqAVMrc1Dtq0Dz3DCeh3Q DAvBOMB+077epuff4PTAfDXK/1V9VM8jQummTZWCkWjvGeA6Ps55HEwCCT4Lvj67zFa9 5bwjHrSm4wTyroKYb81ENvFkmqD1lmMi+VhtM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CnHf8sQNpieD64xbjP7bQVWpkNeuhs0mpWrzD/iOuj0=; b=k0RAvZycXHPwpRBqLUO137/Iy/8EW8O66lho3MLkzNb0IqzYJr+hXcinE9PL9kzyFV GyBtcGwDnGLkVXwC6yvvJlEwys4nVyOqYB+7+NchiHCiXXLY4tCKESxIdrOnfcCZlMn7 CDMWfQLyGoQ9cng41KtTGSFoWrUFkefdZnfbCTWCI4DKe0vTOGufatOrRgKh49lviwdq l+1bIreRClBmvu6fTpM3yW/Bz7yR0yshx9pnD+E8TFp4NELc/VKwIQTOjYkiJDYPqmb+ cgs3OXPEFBH2YNM/6/Veemegw17aqweftfRkQcP35QGSFFwsYLkM+nkvNQlsTfiDPFZD EoLQ==
X-Gm-Message-State: AHYfb5gz1BR0g25IttzmAQFd3guCUwK7LMotq89MshHcC/025nJnKfTz 0hkbu46x3ZRxHGkjO8GulQ==
X-Google-Smtp-Source: ADKCNb69S5VkCkH0eqnIsyuf1D34q+Quf8lXyFD7BoLQGsySQ7QyRxDnxvhxeTHr8h1M5WkMFO63vQ==
X-Received: by 10.202.245.4 with SMTP id t4mr1433845oih.41.1504097560181; Wed, 30 Aug 2017 05:52:40 -0700 (PDT)
Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id z69sm5337031oig.31.2017.08.30.05.52.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 05:52:39 -0700 (PDT)
To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> 
From: Byron Campen 
Message-ID: <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>
Date: Wed, 30 Aug 2017 07:52:41 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 12:52:46 -0000

     Alright, if we want to write a rule that the transport follows the 
bundle, what about this?

a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4

and in a reoffer

a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1

     What transport goes where?

Best regards,
Byron Campen

On 8/30/17 5:18 AM, Christer Holmberg wrote:
> Hi,
>
> Maybe I¹m missing something, but I fail to see what the problem is.
>
> If the BUNDLE-tag section is changed (e.g., because the current BUNDLE-tag
> section m- line is rejected) you simply include the TRANSPORT/IDENTICAL
> category attributes in the new BUNDLE-tag section m- line.
>
> Regards,
>
> Christer
>
>
>
>
>
> On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"
>  wrote:
>
>>
>> On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
>>> Some ideas for how to resolve it:
>>>
>>> 1. Require ufrags to be unique for different ICE sessions (JSEP
>>> already requires this), and use the ufrag as the unique identifier.
>>> Then the BUNDLE semantics could be used as-is, with "unique/shared
>>> ufrag" replacing "unique/shared address".
>>      I think this is our best option. It should allow trickle ICE to
>> work as well as anything else. We might still want to do some of the
>> below in addition.
>>
>>> 2. For ICE, instead of using a "shared address" to mean "guaranteed to
>>> use the existing BUNDLE transport", use "a=bundle-only" in subsequent
>>> offers. If we were to do this, we may also need to allow the offerer
>>> BUNDLE-tag section to be rejected; that's currently not supported
>>> (https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>>      This does not help clarify things when the offerer changes the
>> BUNDLE tag (disable, remove from BUNDLE, make something else the
>> BUNDLE-tag, etc).
>>
>>> 3. Since the "shared address" rules say "don't associate
>>> TRANSPORT/IDENTICAL category attributes with m= sections other than
>>> the offerer BUNDLE-tag section", we could interpret "m= section has no
>>> transport attributes of its own" as "using shared address".
>>      I don't think this helps when the offerer changes the BUNDLE-tag
>> either.
>>
>> Best regards,
>> Byron Campen
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb



From nobody Wed Aug 30 06:29:04 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 19548133281 for ; Wed, 30 Aug 2017 06:29:03 -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 jAXhjconr-8s for ; Wed, 30 Aug 2017 06:29:00 -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 9235B133278 for ; Wed, 30 Aug 2017 06:29:00 -0700 (PDT)
X-AuditID: c1b4fb30-597ff70000005897-46-59a6bd9a2c12
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 86.BD.22679.A9DB6A95; Wed, 30 Aug 2017 15:28:58 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 15:28:58 +0200
From: Christer Holmberg 
To: Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A
Date: Wed, 30 Aug 2017 13:28:57 +0000
Message-ID: 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>
In-Reply-To: <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <60AC0F18C11C8446BA73234F504293EA@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7q+6svcsiDVomKVosvNfKYnF5xUNW i7X/2tkdmD0WbCr1WLLkJ5NH34Eu1gDmKC6blNSczLLUIn27BK6MC3s/MRdskq1ofevQwHhB pouRg0NCwETi3tyYLkYuDiGBI4wSXc+/MkI4Sxgl+ltOMYEUsQlYSHT/0+5i5OQQESiSOHNs CxOILSzgKHHsxDx2kBIRASeJXw3RECVuEje/7mMGCbMIqErMe1QEEuYVsJbY9HQ3C8T0N4wS T18sYwWp4RSwl3hxNh+khlFATOL7qTVg05kFxCVuPZkPZksICEgs2XOeGcIWlXj5+B9Yq6iA nsS7/Z4QYUWJj6/2MUK0akl8+bGPDcK2llh/4TszhK0oMaX7ITvEOYISJ2c+YZnAKDYLybZZ SNpnIWmfhaR9FpL2BYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+vglt8GOxhfPnc8 xCjAwajEw3t3/bJIIdbEsuLK3EOMEhzMSiK8J1cBhXhTEiurUovy44tKc1KLDzFKc7AoifM6 7rsQISSQnliSmp2aWpBaBJNl4uCUamC0EvgovMuCf+chJ4X9V53Vp739xOaykv1j8vHmKx67 ndJmXg6xnlSTHf1j76m4VWf6yrOP87F2FUas3vLl5rQTTVM+8l18xjfP+qjAik0+X4WSf8X1 lXauTZVveH74Xov+pL71Vcp7BT+FCUS9t+1X2JErbsjvpZ7edvaH6nnZyRIVv52X/3BWYinO SDTUYi4qTgQA93IVK6sCAAA=
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 13:29:03 -0000

SGksDQoNCj4gICAgIEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBydWxlIHRoYXQgdGhl
IHRyYW5zcG9ydCBmb2xsb3dzIHRoZQ0KPmJ1bmRsZSwgd2hhdCBhYm91dCB0aGlzPw0KPg0KPmE9
Z3JvdXA6QlVORExFIG1pZDEgbWlkMg0KPmE9Z3JvdXA6QlVORExFIG1pZDMgbWlkNA0KPg0KPmFu
ZCBpbiBhIHJlb2ZmZXINCj4NCj5hPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCj5hPWdyb3VwOkJV
TkRMRSBtaWQ0IG1pZDENCj4NCj4gICAgIFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/DQoNCg0K
SSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRv
aW5nIGFib3ZlIGlzDQptb3Zpbmcgc3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5v
dGhlciwgYW5kIG1peGluZyB0aGUgQlVORExFDQpncm91cHMgdXAsIGFuZCBJIGRvbqGvdCB0aGlu
ayB0aGF0oa9zIGEgZ29vZCBpZGVhLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoN
Cg0KDQo+DQo+QmVzdCByZWdhcmRzLA0KPkJ5cm9uIENhbXBlbg0KPg0KPk9uIDgvMzAvMTcgNTox
OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBNYXliZSBJqfZt
IG1pc3Npbmcgc29tZXRoaW5nLCBidXQgSSBmYWlsIHRvIHNlZSB3aGF0IHRoZSBwcm9ibGVtIGlz
Lg0KPj4NCj4+IElmIHRoZSBCVU5ETEUtdGFnIHNlY3Rpb24gaXMgY2hhbmdlZCAoZS5nLiwgYmVj
YXVzZSB0aGUgY3VycmVudA0KPj5CVU5ETEUtdGFnDQo+PiBzZWN0aW9uIG0tIGxpbmUgaXMgcmVq
ZWN0ZWQpIHlvdSBzaW1wbHkgaW5jbHVkZSB0aGUgVFJBTlNQT1JUL0lERU5USUNBTA0KPj4gY2F0
ZWdvcnkgYXR0cmlidXRlcyBpbiB0aGUgbmV3IEJVTkRMRS10YWcgc2VjdGlvbiBtLSBsaW5lLg0K
Pj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4g
T24gMjkvMDgvMTcgMTk6NDUsICJydGN3ZWIgb24gYmVoYWxmIG9mIEJ5cm9uIENhbXBlbiINCj4+
IDxydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmNhbXBlbkBtb3ppbGxhLmNv
bT4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj4gT24gOC8yOS8xNyAxMTozNSBBTSwgVGF5bG9yIEJyYW5k
c3RldHRlciB3cm90ZToNCj4+Pj4gU29tZSBpZGVhcyBmb3IgaG93IHRvIHJlc29sdmUgaXQ6DQo+
Pj4+DQo+Pj4+IDEuIFJlcXVpcmUgdWZyYWdzIHRvIGJlIHVuaXF1ZSBmb3IgZGlmZmVyZW50IElD
RSBzZXNzaW9ucyAoSlNFUA0KPj4+PiBhbHJlYWR5IHJlcXVpcmVzIHRoaXMpLCBhbmQgdXNlIHRo
ZSB1ZnJhZyBhcyB0aGUgdW5pcXVlIGlkZW50aWZpZXIuDQo+Pj4+IFRoZW4gdGhlIEJVTkRMRSBz
ZW1hbnRpY3MgY291bGQgYmUgdXNlZCBhcy1pcywgd2l0aCAidW5pcXVlL3NoYXJlZA0KPj4+PiB1
ZnJhZyIgcmVwbGFjaW5nICJ1bmlxdWUvc2hhcmVkIGFkZHJlc3MiLg0KPj4+ICAgICAgSSB0aGlu
ayB0aGlzIGlzIG91ciBiZXN0IG9wdGlvbi4gSXQgc2hvdWxkIGFsbG93IHRyaWNrbGUgSUNFIHRv
DQo+Pj4gd29yayBhcyB3ZWxsIGFzIGFueXRoaW5nIGVsc2UuIFdlIG1pZ2h0IHN0aWxsIHdhbnQg
dG8gZG8gc29tZSBvZiB0aGUNCj4+PiBiZWxvdyBpbiBhZGRpdGlvbi4NCj4+Pg0KPj4+PiAyLiBG
b3IgSUNFLCBpbnN0ZWFkIG9mIHVzaW5nIGEgInNoYXJlZCBhZGRyZXNzIiB0byBtZWFuICJndWFy
YW50ZWVkIHRvDQo+Pj4+IHVzZSB0aGUgZXhpc3RpbmcgQlVORExFIHRyYW5zcG9ydCIsIHVzZSAi
YT1idW5kbGUtb25seSIgaW4gc3Vic2VxdWVudA0KPj4+PiBvZmZlcnMuIElmIHdlIHdlcmUgdG8g
ZG8gdGhpcywgd2UgbWF5IGFsc28gbmVlZCB0byBhbGxvdyB0aGUgb2ZmZXJlcg0KPj4+PiBCVU5E
TEUtdGFnIHNlY3Rpb24gdG8gYmUgcmVqZWN0ZWQ7IHRoYXQncyBjdXJyZW50bHkgbm90IHN1cHBv
cnRlZA0KPj4+PiAoaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvaXNz
dWVzLzIyKS4NCj4+PiAgICAgIFRoaXMgZG9lcyBub3QgaGVscCBjbGFyaWZ5IHRoaW5ncyB3aGVu
IHRoZSBvZmZlcmVyIGNoYW5nZXMgdGhlDQo+Pj4gQlVORExFIHRhZyAoZGlzYWJsZSwgcmVtb3Zl
IGZyb20gQlVORExFLCBtYWtlIHNvbWV0aGluZyBlbHNlIHRoZQ0KPj4+IEJVTkRMRS10YWcsIGV0
YykuDQo+Pj4NCj4+Pj4gMy4gU2luY2UgdGhlICJzaGFyZWQgYWRkcmVzcyIgcnVsZXMgc2F5ICJk
b24ndCBhc3NvY2lhdGUNCj4+Pj4gVFJBTlNQT1JUL0lERU5USUNBTCBjYXRlZ29yeSBhdHRyaWJ1
dGVzIHdpdGggbT0gc2VjdGlvbnMgb3RoZXIgdGhhbg0KPj4+PiB0aGUgb2ZmZXJlciBCVU5ETEUt
dGFnIHNlY3Rpb24iLCB3ZSBjb3VsZCBpbnRlcnByZXQgIm09IHNlY3Rpb24gaGFzIG5vDQo+Pj4+
IHRyYW5zcG9ydCBhdHRyaWJ1dGVzIG9mIGl0cyBvd24iIGFzICJ1c2luZyBzaGFyZWQgYWRkcmVz
cyIuDQo+Pj4gICAgICBJIGRvbid0IHRoaW5rIHRoaXMgaGVscHMgd2hlbiB0aGUgb2ZmZXJlciBj
aGFuZ2VzIHRoZSBCVU5ETEUtdGFnDQo+Pj4gZWl0aGVyLg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRz
LA0KPj4+IEJ5cm9uIENhbXBlbg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4gcnRjd2Vi
QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3
ZWINCj4NCj4NCg0K


From nobody Wed Aug 30 06:46: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 A5CA913316D for ; Wed, 30 Aug 2017 06:46:44 -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=mozilla.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 WLU8JMmyAPG7 for ; Wed, 30 Aug 2017 06:46:41 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 A52EF1332BD for ; Wed, 30 Aug 2017 06:46:41 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id k77so51403144oib.2 for ; Wed, 30 Aug 2017 06:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ojRlIIAJOAgNGS0Ir9cTrlxqUxAhSC2h7nAmT1LNnSw=; b=HdcwTRU5jCT5kzm/aokZxzS65iud3K4bQlXKp7WO8Tm7q+a5PWlFTYM0U47+mLtqnp mgvY/MC041fXxxLgH9NHa42pLfe4yKbwFyhXgxL2YWKDMcXwJQx2TEQVGb21LS2FdsWm o6uzKcwtkbNMYA6/47tLR2U/EKXVCuz2ckysY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ojRlIIAJOAgNGS0Ir9cTrlxqUxAhSC2h7nAmT1LNnSw=; b=hnTnjQ3uJMT1mI2fraUXI11s/frBzind1UTY5Zl4IBiso52kzBtktiPjsanNBhR0Uc isKuXYPtk0oXdtwCvsBsqrsdoXDpQckwm3N/LDbBVydAKQ2KC2xJMdl4xXuGSVT2zV+s HH27swNhnO2BswaKNgOVPfXDxu0KxQ16fCA+aNaNkrs4T8q3Kw1tsT7S5jZfz8eIixye kGjSchXc6xyOTqFxByVtjyTLkC/c6c1wRqAtzqMlbDRB5qqnTq2pVyn2OBU19tbW08uh r3njPUx2nDPjlFeDJXcyYsauyKHDHFDcAj3GXVUc2H1qbxxBenHnlzYK0wCo0BSI16QI VFHQ==
X-Gm-Message-State: AHYfb5h6ChgtniG156i/6Fy65kpYMo7vTnNvQ5dt5xotvJVIg5qUHgYG a/vJEfCVGIYUeXOiLzEyQQ==
X-Google-Smtp-Source: ADKCNb7ViR0LCn6X6X6TCz/FuwgXhSzHs/tS6xRHeGWdFVz1uZTG6EQ5c5kAh9LvY0CUB7MRZoFwIw==
X-Received: by 10.202.72.17 with SMTP id v17mr1464444oia.129.1504100800482; Wed, 30 Aug 2017 06:46:40 -0700 (PDT)
Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id w8sm5181401oiw.9.2017.08.30.06.46.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 06:46:39 -0700 (PDT)
To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> 
From: Byron Campen 
Message-ID: <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>
Date: Wed, 30 Aug 2017 08:46:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 13:46:45 -0000

On 8/30/17 8:28 AM, Christer Holmberg wrote:
> Hi,
>
>>      Alright, if we want to write a rule that the transport follows the
>> bundle, what about this?
>>
>> a=group:BUNDLE mid1 mid2
>> a=group:BUNDLE mid3 mid4
>>
>> and in a reoffer
>>
>> a=group:BUNDLE mid2 mid3
>> a=group:BUNDLE mid4 mid1
>>
>>      What transport goes where?
>
> I think Taylor raised this issue earlier. What you are doing above is
> moving streams from one BUNDLE group to another, and mixing the BUNDLE
> groups up, and I don’t think that’s a good idea.
>
> Regards,
>
> Christer

     If you want to classify this as a bad idea, we need normative 
language forbidding it. For instance, a rule that once a mid is placed 
in a bundle, the only way to remove it is to disable it, as well as a 
rule to handle the following:

a=group:BUNDLE mid2 mid3
a=mid: mid1 <--- not bundled
...
a=mid: mid2
...
a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

     We would need to define which transport is retained; mid1's, or the 
bundle's. Or perhaps a rule forbidding previously unbundled mids to be 
added to a bundle.

     There are lots of corner cases here that simply aren't specified 
right now. In the non-trickle-ICE case, this is ok, because the offerer 
unambiguously signals what transports it uses where in the c= line.

Best regards,
Byron Campen
>
>
>
>
>
>
>
>> Best regards,
>> Byron Campen
>>
>> On 8/30/17 5:18 AM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> Maybe I¹m missing something, but I fail to see what the problem is.
>>>
>>> If the BUNDLE-tag section is changed (e.g., because the current
>>> BUNDLE-tag
>>> section m- line is rejected) you simply include the TRANSPORT/IDENTICAL
>>> category attributes in the new BUNDLE-tag section m- line.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"
>>>  wrote:
>>>
>>>> On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
>>>>> Some ideas for how to resolve it:
>>>>>
>>>>> 1. Require ufrags to be unique for different ICE sessions (JSEP
>>>>> already requires this), and use the ufrag as the unique identifier.
>>>>> Then the BUNDLE semantics could be used as-is, with "unique/shared
>>>>> ufrag" replacing "unique/shared address".
>>>>       I think this is our best option. It should allow trickle ICE to
>>>> work as well as anything else. We might still want to do some of the
>>>> below in addition.
>>>>
>>>>> 2. For ICE, instead of using a "shared address" to mean "guaranteed to
>>>>> use the existing BUNDLE transport", use "a=bundle-only" in subsequent
>>>>> offers. If we were to do this, we may also need to allow the offerer
>>>>> BUNDLE-tag section to be rejected; that's currently not supported
>>>>> (https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>>>>       This does not help clarify things when the offerer changes the
>>>> BUNDLE tag (disable, remove from BUNDLE, make something else the
>>>> BUNDLE-tag, etc).
>>>>
>>>>> 3. Since the "shared address" rules say "don't associate
>>>>> TRANSPORT/IDENTICAL category attributes with m= sections other than
>>>>> the offerer BUNDLE-tag section", we could interpret "m= section has no
>>>>> transport attributes of its own" as "using shared address".
>>>>       I don't think this helps when the offerer changes the BUNDLE-tag
>>>> either.
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>


From nobody Wed Aug 30 07:28: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 1D1BB1329C7 for ; Wed, 30 Aug 2017 07:28:26 -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 8nlMb9lshMSJ for ; Wed, 30 Aug 2017 07:28:24 -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 C6F51120727 for ; Wed, 30 Aug 2017 07:28:23 -0700 (PDT)
X-AuditID: c1b4fb2d-4e93a9c0000057a4-6e-59a6cb85d2db
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.50.22436.58BC6A95; Wed, 30 Aug 2017 16:28:22 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 16:27:25 +0200
From: Christer Holmberg 
To: Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAACvJcA==
Date: Wed, 30 Aug 2017 14:27:24 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD0AFA1@ESESSMB109.ericsson.se>
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>
In-Reply-To: <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7um7b6WWRBpffc1gsvNfKYnF5xUNW i7X/2tkdmD0WbCr1WLLkJ5NH34Eu1gDmKC6blNSczLLUIn27BK6M8323mApuaVbcXHiJrYHx gkYXIyeHhICJxItvT9i6GLk4hASOMErMWd/BCOEsYZS409XP1MXIwcEmYCHR/U8bpEFEoEji zLEtYGFhAUeJCfOEQEwRASeJXw3REBVhErvuv2QECbMIqEq8W1UFYvIK+Ep0H/WBmH2ZSeLI wW+sIOWcAvYSNx8cZQSxGQXEJL6fWsMEYjMLiEvcejKfCeJKAYkle84zQ9iiEi8f/2OFsJUk Vmy/BLaKWUBTYv0ufYhWRYkp3Q/ZQWxeAUGJkzOfsExgFJmFZOoshI5ZSDpmIelYwMiyilG0 OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwLg5u+a27g3H1a8dDjAIcjEo8vBUblkUKsSaWFVfm HmKU4GBWEuE9uQooxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwT B6dUA2PWFd2Jf3kTD3ItPrc0WDJp+RQJITedB+xW+5LPWN44rFnZdZ+z+5W94EvrwF3/bcN9 vbgyVkySOPKqcn8kF/ui9j0plQunnV67cHKIQF6A3HTnyW1bNgrvrV11Nbn4+Nr666qnVQqz Qj6rnks8pf/aiP3mrjuzVEtutvGnt6pK71b8vUjkwXwlluKMREMt5qLiRABqkxxChwIAAA==
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 14:28:26 -0000

SGksDQoNCj4+PiAgICAgIEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBydWxlIHRoYXQg
dGhlIHRyYW5zcG9ydCBmb2xsb3dzIA0KPj4+IHRoZSBidW5kbGUsIHdoYXQgYWJvdXQgdGhpcz8N
Cj4+Pg0KPj4+IGE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMg0KPj4+IGE9Z3JvdXA6QlVORExFIG1p
ZDMgbWlkNA0KPj4+DQo+Pj4gYW5kIGluIGEgcmVvZmZlcg0KPj4+DQo+Pj4gYT1ncm91cDpCVU5E
TEUgbWlkMiBtaWQzDQo+Pj4gYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQo+Pj4NCj4+PiAgICAg
IFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/DQo+Pg0KPj4gSSB0aGluayBUYXlsb3IgcmFpc2Vk
IHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlIGlzIA0KPj4gbW92
aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRvIGFub3RoZXIsIGFuZCBtaXhpbmcg
dGhlIEJVTkRMRSANCj4+IGdyb3VwcyB1cCwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGF04oCZcyBh
IGdvb2QgaWRlYS4NCj4NCj4gSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkgdGhpcyBhcyBhIGJhZCBp
ZGVhLCB3ZSBuZWVkIG5vcm1hdGl2ZSBsYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5zdGFu
Y2UsIGEgcnVsZSB0aGF0IA0KPiBvbmNlIGEgbWlkIGlzIHBsYWNlZCBpbiBhIGJ1bmRsZSwgdGhl
IG9ubHkgd2F5IHRvIHJlbW92ZSBpdCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxsIGFzIGEgcnVs
ZSB0byBoYW5kbGUgdGhlIGZvbGxvd2luZzoNCj4NCj4gYT1ncm91cDpCVU5ETEUgbWlkMiBtaWQz
DQo+IGE9bWlkOiBtaWQxIDwtLS0gbm90IGJ1bmRsZWQNCj4uLi4NCj5hPW1pZDogbWlkMg0KPi4u
Lg0KPmE9bWlkOiBtaWQzDQo+DQo+YW5kIGluIGEgcmVvZmZlcg0KPg0KPmE9Z3JvdXAgbWlkMSBt
aWQyIG1pZDMNCj4NCj7CoMKgV2Ugd291bGQgbmVlZCB0byBkZWZpbmUgd2hpY2ggdHJhbnNwb3J0
IGlzIHJldGFpbmVkOyBtaWQxJ3MsIG9yIHRoZSBidW5kbGUncy4gT3IgcGVyaGFwcyBhIHJ1bGUg
Zm9yYmlkZGluZyBwcmV2aW91c2x5IHVuYnVuZGxlZCBtaWRzIHRvIGJlIGFkZGVkIHRvIGEgYnVu
ZGxlLg0KDQpNZSBhbmQgVGF5bG9yIGRpZCBkaXNjdXNzIHNvbWUgcmVzdHJpY3Rpb24gdGV4dC4g
SSdsbCBkaWcgaW4gbXkgYWNoaWV2ZS4NCg0KPlRoZXJlIGFyZSBsb3RzIG9mIGNvcm5lciBjYXNl
cyBoZXJlIHRoYXQgc2ltcGx5IGFyZW4ndCBzcGVjaWZpZWQgcmlnaHQgbm93LiBJbiB0aGUgbm9u
LXRyaWNrbGUtSUNFIGNhc2UsIHRoaXMgaXMgb2ssIGJlY2F1c2UgDQo+dGhlIG9mZmVyZXIgdW5h
bWJpZ3VvdXNseSBzaWduYWxzIHdoYXQgdHJhbnNwb3J0cyBpdCB1c2VzIHdoZXJlIGluIHRoZSBj
PSBsaW5lLg0KDQpJIHRoaW5rIHRoYXQncyBhIHNlcGFyYXRlIHByb2JsZW0uDQoNCkkgZG8gYWdy
ZWUgdGhhdCB0aGUgQlVORExFIGdyb3VwIHRyYW5zcG9ydCBpcyBjdXJyZW50bHkgYm91bmQgdG8g
dGhlIGMvbS0gbGluZS4gSWYgSUNFIGlzIHVzZWQsIHdlIHNob3VsZCBwcm9iYWJseSB1c2UgY2Fu
ZGlkYXRlIGluZm9ybWF0aW9uIGluc3RlYWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K
DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBCeXJvbiBDYW1wZW4NCj4+DQo+PiBPbiA4LzMwLzE3IDU6
MTggQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gTWF5YmUg
ScK5bSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZmFpbCB0byBzZWUgd2hhdCB0aGUgcHJvYmxl
bSBpcy4NCj4+Pg0KPj4+IElmIHRoZSBCVU5ETEUtdGFnIHNlY3Rpb24gaXMgY2hhbmdlZCAoZS5n
LiwgYmVjYXVzZSB0aGUgY3VycmVudCANCj4+PiBCVU5ETEUtdGFnIHNlY3Rpb24gbS0gbGluZSBp
cyByZWplY3RlZCkgeW91IHNpbXBseSBpbmNsdWRlIHRoZSANCj4+PiBUUkFOU1BPUlQvSURFTlRJ
Q0FMIGNhdGVnb3J5IGF0dHJpYnV0ZXMgaW4gdGhlIG5ldyBCVU5ETEUtdGFnIA0KPj4+IHNlY3Rp
b24gbS0gbGluZS4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+PiBDaHJpc3Rlcg0KPj4+DQo+
Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAyOS8wOC8xNyAxOTo0NSwgInJ0Y3dlYiBvbiBiZWhh
bGYgb2YgQnlyb24gQ2FtcGVuIg0KPj4+IDxydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh
bGYgb2YgYmNhbXBlbkBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gT24gOC8yOS8xNyAx
MTozNSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToNCj4+Pj4+IFNvbWUgaWRlYXMgZm9y
IGhvdyB0byByZXNvbHZlIGl0Og0KPj4+Pj4NCj4+Pj4+IDEuIFJlcXVpcmUgdWZyYWdzIHRvIGJl
IHVuaXF1ZSBmb3IgZGlmZmVyZW50IElDRSBzZXNzaW9ucyAoSlNFUCANCj4+Pj4+IGFscmVhZHkg
cmVxdWlyZXMgdGhpcyksIGFuZCB1c2UgdGhlIHVmcmFnIGFzIHRoZSB1bmlxdWUgaWRlbnRpZmll
ci4NCj4+Pj4+IFRoZW4gdGhlIEJVTkRMRSBzZW1hbnRpY3MgY291bGQgYmUgdXNlZCBhcy1pcywg
d2l0aCAidW5pcXVlL3NoYXJlZCANCj4+Pj4+IHVmcmFnIiByZXBsYWNpbmcgInVuaXF1ZS9zaGFy
ZWQgYWRkcmVzcyIuDQo+Pj4+ICAgICAgIEkgdGhpbmsgdGhpcyBpcyBvdXIgYmVzdCBvcHRpb24u
IEl0IHNob3VsZCBhbGxvdyB0cmlja2xlIElDRSANCj4+Pj4gdG8gd29yayBhcyB3ZWxsIGFzIGFu
eXRoaW5nIGVsc2UuIFdlIG1pZ2h0IHN0aWxsIHdhbnQgdG8gZG8gc29tZSBvZiANCj4+Pj4gdGhl
IGJlbG93IGluIGFkZGl0aW9uLg0KPj4+Pg0KPj4+Pj4gMi4gRm9yIElDRSwgaW5zdGVhZCBvZiB1
c2luZyBhICJzaGFyZWQgYWRkcmVzcyIgdG8gbWVhbiANCj4+Pj4+ICJndWFyYW50ZWVkIHRvIHVz
ZSB0aGUgZXhpc3RpbmcgQlVORExFIHRyYW5zcG9ydCIsIHVzZSANCj4+Pj4+ICJhPWJ1bmRsZS1v
bmx5IiBpbiBzdWJzZXF1ZW50IG9mZmVycy4gSWYgd2Ugd2VyZSB0byBkbyB0aGlzLCB3ZSANCj4+
Pj4+IG1heSBhbHNvIG5lZWQgdG8gYWxsb3cgdGhlIG9mZmVyZXIgQlVORExFLXRhZyBzZWN0aW9u
IHRvIGJlIA0KPj4+Pj4gcmVqZWN0ZWQ7IHRoYXQncyBjdXJyZW50bHkgbm90IHN1cHBvcnRlZCAo
aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvaXNzdWVzLzIyKS4NCj4+
Pj4gICAgICAgVGhpcyBkb2VzIG5vdCBoZWxwIGNsYXJpZnkgdGhpbmdzIHdoZW4gdGhlIG9mZmVy
ZXIgY2hhbmdlcyANCj4+Pj4gdGhlIEJVTkRMRSB0YWcgKGRpc2FibGUsIHJlbW92ZSBmcm9tIEJV
TkRMRSwgbWFrZSBzb21ldGhpbmcgZWxzZSANCj4+Pj4gdGhlIEJVTkRMRS10YWcsIGV0YykuDQo+
Pj4+DQo+Pj4+PiAzLiBTaW5jZSB0aGUgInNoYXJlZCBhZGRyZXNzIiBydWxlcyBzYXkgImRvbid0
IGFzc29jaWF0ZSANCj4+Pj4+IFRSQU5TUE9SVC9JREVOVElDQUwgY2F0ZWdvcnkgYXR0cmlidXRl
cyB3aXRoIG09IHNlY3Rpb25zIG90aGVyIA0KPj4+Pj4gdGhhbiB0aGUgb2ZmZXJlciBCVU5ETEUt
dGFnIHNlY3Rpb24iLCB3ZSBjb3VsZCBpbnRlcnByZXQgIm09IA0KPj4+Pj4gc2VjdGlvbiBoYXMg
bm8gdHJhbnNwb3J0IGF0dHJpYnV0ZXMgb2YgaXRzIG93biIgYXMgInVzaW5nIHNoYXJlZCBhZGRy
ZXNzIi4NCj4+Pj4gICAgICAgSSBkb24ndCB0aGluayB0aGlzIGhlbHBzIHdoZW4gdGhlIG9mZmVy
ZXIgY2hhbmdlcyB0aGUgDQo+Pj4+IEJVTkRMRS10YWcgZWl0aGVyLg0KPj4+Pg0KPj4+PiBCZXN0
IHJlZ2FyZHMsDQo+Pj4+IEJ5cm9uIENhbXBlbg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0
DQo+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3J0Y3dlYg0KPj4NCg0K


From nobody Wed Aug 30 07:36:21 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 8B69F132DBF for ; Wed, 30 Aug 2017 07:36:20 -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 SCUek39RiYaP for ; Wed, 30 Aug 2017 07:36:18 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 EE637132D69 for ; Wed, 30 Aug 2017 07:36:15 -0700 (PDT)
X-AuditID: c1b4fb3a-5ffff700000051a3-29-59a6cd5e02f0
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.EF.20899.E5DC6A95; Wed, 30 Aug 2017 16:36:14 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 16:36:13 +0200
From: Christer Holmberg 
To: Christer Holmberg , Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAACvJcIAAA1zw
Date: Wed, 30 Aug 2017 14:36:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD0B071@ESESSMB109.ericsson.se>
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD0AFA1@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CD0AFA1@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2J7oG7c2WWRBg1LhCwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGpV2LGAtWGVZcOqLQwNhh 0MXIySEhYCLxf/9c9i5GLg4hgSOMEgsO7meBcJYwSix/8I61i5GDg03AQqL7nzZIXERgBaPE lovf2EHiwgKOEhPmCYGYIgJOEr8aoiHMKIlPv/RBxrMIqErs3bwCbAivgK/E3395EMOnM0vs m/SAHaSGU8BPYnLTZ0YQm1FATOL7qTVMIDazgLjErSfzmSDOFJBYsuc8M4QtKvHy8T9WCFtJ YsX2S4wg85kFNCXW79KHaFWUmNL9EGw8r4CgxMmZT1gmMIrMQjJ1FkLHLCQds5B0LGBkWcUo WpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGBcHt/y22sF48LnjIUYBDkYlHt5ZZ5ZFCrEmlhVX 5h5ilOBgVhLhPbkKKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS1OzU1ILUIpgs EwenVANjysepClPXv9hvqdf1wsPsxtXZv6uMlrZZMJwMfPchJyQnfGnXl9X2S9MsCpzTjBzV /cyWd2wzizm09eZrX7vOPQfvzWaKDcjW2b6tke9jtqrengi7GO+GM992T5hlt6PwSoTsvJig xXmx6UZdzzSv9PydyCj/+EtRS+krqcfuewNm5wuJfNumxFKckWioxVxUnAgAxgz7sYcCAAA=
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 14:36:20 -0000

SGksDQoNCkhlcmUgaXMgdGhlIEdpdEh1YiBpc3N1ZSB3aGVyZSBtZSBhbmQgVGF5bG9yIGRpc2N1
c3NlZCB0aGlzOg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9p
c3N1ZXMvMjYNCg0KVGhlIG91dGNvbWUgd2FzIHRoYXQgd2UgbmVlZCB0byBzYXkgInNvbWV0aGlu
ZyIsIGJ1dCB0aGVyZSBpcyBub3QgbW9yZSB0aGFuIHRoYXQsIHNvIGZlZWwgZnJlZSB0byBzdWdn
ZXN0IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAzMCBBdWd1c3QgMjAxNyAxNjoyNw0KVG86
IEJ5cm9uIENhbXBlbiA8YmNhbXBlbkBtb3ppbGxhLmNvbT47IFRheWxvciBCcmFuZHN0ZXR0ZXIg
PGRlYWRiZWVmQGdvb2dsZS5jb20+OyBSVENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtydGN3ZWJdIEFtYmlndWl0aWVzIHdpdGggQlVORExFIHdoZW4gdXNlZCB3aXRo
IElDRT8NCg0KSGksDQoNCj4+PiAgICAgIEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBy
dWxlIHRoYXQgdGhlIHRyYW5zcG9ydCBmb2xsb3dzIA0KPj4+IHRoZSBidW5kbGUsIHdoYXQgYWJv
dXQgdGhpcz8NCj4+Pg0KPj4+IGE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMg0KPj4+IGE9Z3JvdXA6
QlVORExFIG1pZDMgbWlkNA0KPj4+DQo+Pj4gYW5kIGluIGEgcmVvZmZlcg0KPj4+DQo+Pj4gYT1n
cm91cDpCVU5ETEUgbWlkMiBtaWQzDQo+Pj4gYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQo+Pj4N
Cj4+PiAgICAgIFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/DQo+Pg0KPj4gSSB0aGluayBUYXls
b3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlIGlz
IA0KPj4gbW92aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRvIGFub3RoZXIsIGFu
ZCBtaXhpbmcgdGhlIA0KPj4gQlVORExFIGdyb3VwcyB1cCwgYW5kIEkgZG9u4oCZdCB0aGluayB0
aGF04oCZcyBhIGdvb2QgaWRlYS4NCj4NCj4gSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkgdGhpcyBh
cyBhIGJhZCBpZGVhLCB3ZSBuZWVkIG5vcm1hdGl2ZSBsYW5ndWFnZSANCj4gZm9yYmlkZGluZyBp
dC4gRm9yIGluc3RhbmNlLCBhIHJ1bGUgdGhhdCBvbmNlIGEgbWlkIGlzIHBsYWNlZCBpbiBhIGJ1
bmRsZSwgdGhlIG9ubHkgd2F5IHRvIHJlbW92ZSBpdCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxs
IGFzIGEgcnVsZSB0byBoYW5kbGUgdGhlIGZvbGxvd2luZzoNCj4NCj4gYT1ncm91cDpCVU5ETEUg
bWlkMiBtaWQzDQo+IGE9bWlkOiBtaWQxIDwtLS0gbm90IGJ1bmRsZWQNCj4uLi4NCj5hPW1pZDog
bWlkMg0KPi4uLg0KPmE9bWlkOiBtaWQzDQo+DQo+YW5kIGluIGEgcmVvZmZlcg0KPg0KPmE9Z3Jv
dXAgbWlkMSBtaWQyIG1pZDMNCj4NCj7CoMKgV2Ugd291bGQgbmVlZCB0byBkZWZpbmUgd2hpY2gg
dHJhbnNwb3J0IGlzIHJldGFpbmVkOyBtaWQxJ3MsIG9yIHRoZSBidW5kbGUncy4gT3IgcGVyaGFw
cyBhIHJ1bGUgZm9yYmlkZGluZyBwcmV2aW91c2x5IHVuYnVuZGxlZCBtaWRzIHRvIGJlIGFkZGVk
IHRvIGEgYnVuZGxlLg0KDQpNZSBhbmQgVGF5bG9yIGRpZCBkaXNjdXNzIHNvbWUgcmVzdHJpY3Rp
b24gdGV4dC4gSSdsbCBkaWcgaW4gbXkgYWNoaWV2ZS4NCg0KPlRoZXJlIGFyZSBsb3RzIG9mIGNv
cm5lciBjYXNlcyBoZXJlIHRoYXQgc2ltcGx5IGFyZW4ndCBzcGVjaWZpZWQgcmlnaHQgDQo+bm93
LiBJbiB0aGUgbm9uLXRyaWNrbGUtSUNFIGNhc2UsIHRoaXMgaXMgb2ssIGJlY2F1c2UgdGhlIG9m
ZmVyZXIgdW5hbWJpZ3VvdXNseSBzaWduYWxzIHdoYXQgdHJhbnNwb3J0cyBpdCB1c2VzIHdoZXJl
IGluIHRoZSBjPSBsaW5lLg0KDQpJIHRoaW5rIHRoYXQncyBhIHNlcGFyYXRlIHByb2JsZW0uDQoN
CkkgZG8gYWdyZWUgdGhhdCB0aGUgQlVORExFIGdyb3VwIHRyYW5zcG9ydCBpcyBjdXJyZW50bHkg
Ym91bmQgdG8gdGhlIGMvbS0gbGluZS4gSWYgSUNFIGlzIHVzZWQsIHdlIHNob3VsZCBwcm9iYWJs
eSB1c2UgY2FuZGlkYXRlIGluZm9ybWF0aW9uIGluc3RlYWQuDQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQoNCg0KDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBCeXJvbiBDYW1wZW4NCj4+DQo+PiBPbiA4
LzMwLzE3IDU6MTggQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+
Pj4gTWF5YmUgScK5bSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZmFpbCB0byBzZWUgd2hhdCB0
aGUgcHJvYmxlbSBpcy4NCj4+Pg0KPj4+IElmIHRoZSBCVU5ETEUtdGFnIHNlY3Rpb24gaXMgY2hh
bmdlZCAoZS5nLiwgYmVjYXVzZSB0aGUgY3VycmVudCANCj4+PiBCVU5ETEUtdGFnIHNlY3Rpb24g
bS0gbGluZSBpcyByZWplY3RlZCkgeW91IHNpbXBseSBpbmNsdWRlIHRoZSANCj4+PiBUUkFOU1BP
UlQvSURFTlRJQ0FMIGNhdGVnb3J5IGF0dHJpYnV0ZXMgaW4gdGhlIG5ldyBCVU5ETEUtdGFnIA0K
Pj4+IHNlY3Rpb24gbS0gbGluZS4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+PiBDaHJpc3Rl
cg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAyOS8wOC8xNyAxOTo0NSwgInJ0Y3dl
YiBvbiBiZWhhbGYgb2YgQnlyb24gQ2FtcGVuIg0KPj4+IDxydGN3ZWItYm91bmNlc0BpZXRmLm9y
ZyBvbiBiZWhhbGYgb2YgYmNhbXBlbkBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gT24g
OC8yOS8xNyAxMTozNSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToNCj4+Pj4+IFNvbWUg
aWRlYXMgZm9yIGhvdyB0byByZXNvbHZlIGl0Og0KPj4+Pj4NCj4+Pj4+IDEuIFJlcXVpcmUgdWZy
YWdzIHRvIGJlIHVuaXF1ZSBmb3IgZGlmZmVyZW50IElDRSBzZXNzaW9ucyAoSlNFUCANCj4+Pj4+
IGFscmVhZHkgcmVxdWlyZXMgdGhpcyksIGFuZCB1c2UgdGhlIHVmcmFnIGFzIHRoZSB1bmlxdWUg
aWRlbnRpZmllci4NCj4+Pj4+IFRoZW4gdGhlIEJVTkRMRSBzZW1hbnRpY3MgY291bGQgYmUgdXNl
ZCBhcy1pcywgd2l0aCAidW5pcXVlL3NoYXJlZCANCj4+Pj4+IHVmcmFnIiByZXBsYWNpbmcgInVu
aXF1ZS9zaGFyZWQgYWRkcmVzcyIuDQo+Pj4+ICAgICAgIEkgdGhpbmsgdGhpcyBpcyBvdXIgYmVz
dCBvcHRpb24uIEl0IHNob3VsZCBhbGxvdyB0cmlja2xlIElDRSANCj4+Pj4gdG8gd29yayBhcyB3
ZWxsIGFzIGFueXRoaW5nIGVsc2UuIFdlIG1pZ2h0IHN0aWxsIHdhbnQgdG8gZG8gc29tZSBvZiAN
Cj4+Pj4gdGhlIGJlbG93IGluIGFkZGl0aW9uLg0KPj4+Pg0KPj4+Pj4gMi4gRm9yIElDRSwgaW5z
dGVhZCBvZiB1c2luZyBhICJzaGFyZWQgYWRkcmVzcyIgdG8gbWVhbiANCj4+Pj4+ICJndWFyYW50
ZWVkIHRvIHVzZSB0aGUgZXhpc3RpbmcgQlVORExFIHRyYW5zcG9ydCIsIHVzZSANCj4+Pj4+ICJh
PWJ1bmRsZS1vbmx5IiBpbiBzdWJzZXF1ZW50IG9mZmVycy4gSWYgd2Ugd2VyZSB0byBkbyB0aGlz
LCB3ZSANCj4+Pj4+IG1heSBhbHNvIG5lZWQgdG8gYWxsb3cgdGhlIG9mZmVyZXIgQlVORExFLXRh
ZyBzZWN0aW9uIHRvIGJlIA0KPj4+Pj4gcmVqZWN0ZWQ7IHRoYXQncyBjdXJyZW50bHkgbm90IHN1
cHBvcnRlZCAoaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvaXNzdWVz
LzIyKS4NCj4+Pj4gICAgICAgVGhpcyBkb2VzIG5vdCBoZWxwIGNsYXJpZnkgdGhpbmdzIHdoZW4g
dGhlIG9mZmVyZXIgY2hhbmdlcyANCj4+Pj4gdGhlIEJVTkRMRSB0YWcgKGRpc2FibGUsIHJlbW92
ZSBmcm9tIEJVTkRMRSwgbWFrZSBzb21ldGhpbmcgZWxzZSANCj4+Pj4gdGhlIEJVTkRMRS10YWcs
IGV0YykuDQo+Pj4+DQo+Pj4+PiAzLiBTaW5jZSB0aGUgInNoYXJlZCBhZGRyZXNzIiBydWxlcyBz
YXkgImRvbid0IGFzc29jaWF0ZSANCj4+Pj4+IFRSQU5TUE9SVC9JREVOVElDQUwgY2F0ZWdvcnkg
YXR0cmlidXRlcyB3aXRoIG09IHNlY3Rpb25zIG90aGVyIA0KPj4+Pj4gdGhhbiB0aGUgb2ZmZXJl
ciBCVU5ETEUtdGFnIHNlY3Rpb24iLCB3ZSBjb3VsZCBpbnRlcnByZXQgIm09IA0KPj4+Pj4gc2Vj
dGlvbiBoYXMgbm8gdHJhbnNwb3J0IGF0dHJpYnV0ZXMgb2YgaXRzIG93biIgYXMgInVzaW5nIHNo
YXJlZCBhZGRyZXNzIi4NCj4+Pj4gICAgICAgSSBkb24ndCB0aGluayB0aGlzIGhlbHBzIHdoZW4g
dGhlIG9mZmVyZXIgY2hhbmdlcyB0aGUgDQo+Pj4+IEJVTkRMRS10YWcgZWl0aGVyLg0KPj4+Pg0K
Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+IEJ5cm9uIENhbXBlbg0KPj4+Pg0KPj4+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBydGN3ZWIgbWFp
bGluZyBsaXN0DQo+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg==


From nobody Wed Aug 30 11:44:58 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 13878132930 for ; Wed, 30 Aug 2017 11:44:52 -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, 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 QG5rRxfd70MB for ; Wed, 30 Aug 2017 11:44:47 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 D97F91326EA for ; Wed, 30 Aug 2017 11:44:46 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id u26so15979917wma.0 for ; Wed, 30 Aug 2017 11:44:46 -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=FNX+Ov/H7+GFy9wNj/DYMIM3Zk06Ujpt3sMBD23ZRfc=; b=EGaJgOm/3fqcg44yAnuqftH8uU988okaxBua8CD2fCKaW6bwtU0IsFePVZbE53q2cp AFdq0pywKid+JyO9KrSTokzwDOAiHTaiQzZeyA4+twjxInwfrpe4GR7IQHTuuLbm1OMX OG5DSAF4o0uwg1SKO0krpHKXuxvlsT8Z5MTr2xzFZJL/e/ZpfQ0RFoPOD5qN22eChp91 YOTIzwnjywc3XLufQWv/0TfwacX9ilNiwKe36lFyhmwJYjd+CPJQ7/qatiAVDjyP8ssl 8sD6h7KXfkyvvirDjjyzEEZldNUMNopDayDerhwFKQKPlAEO+2xhXh9w3I7G4p6b2cEe zXxQ==
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=FNX+Ov/H7+GFy9wNj/DYMIM3Zk06Ujpt3sMBD23ZRfc=; b=UfCNgJrfw8YyCf2/g8AxWL9YW90/g4JBVwbRuMRulOdwaUw6Zs+amzPrtxGL9eelxK vpJh1uOzVvdhmUpp/d7+QL3KpJ4sasu3OLOyvPNeTvBt1h9fwSEfiKtggLXvXmvYJ37c oyaNXLlM+uWqEBL7blAuEjXtHb6BGdeixgGCkFmruByFGYAd8S9Ecz0HMiPbNU11/4hu GrCPz8S69HeRXtxRTzgtYq4ohsbtZRsWjspK3k29+SMb77xr7A+cWedPO8brpaYvg+xF CmtKgvkTbvtGcEjbNxJSPUgqgjTYN4nrf4Zh1FxpCsRSbmAm4i3sdxc2jM/8uClUvMia OEQg==
X-Gm-Message-State: AHYfb5h1w5uUIHV2xVOn11xWuyNaoTdMYGMf8kPcKp2n/1+pyOnY64Io OSfXb3aO4zD27ltm/80bsI4wDW4YJkCj
X-Google-Smtp-Source: ADKCNb4vNbN2PdSxCv5tWLFHDigFPkZ0306BhaiRSnuaHLY4KIZnK0qz352UC3VyukTQPMZJG8yELXN1vDaZcRPHDAs=
X-Received: by 10.28.16.133 with SMTP id 127mr1677699wmq.75.1504118685080; Wed, 30 Aug 2017 11:44:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.55 with HTTP; Wed, 30 Aug 2017 11:44:44 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CD0B071@ESESSMB109.ericsson.se>
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD0AFA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CD0B071@ESESSMB109.ericsson.se>
From: Taylor Brandstetter 
Date: Wed, 30 Aug 2017 11:44:44 -0700
Message-ID: 
To: Christer Holmberg 
Cc: Byron Campen , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a1146d950ed15010557fceb98"
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 18:44:52 -0000

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

>
> Maybe I=C2=B9m missing something, but I fail to see what the problem is.
> If the BUNDLE-tag section is changed (e.g., because the current BUNDLE-ta=
g
> section m- line is rejected) you simply include the TRANSPORT/IDENTICAL
> category attributes in the new BUNDLE-tag section m- line.


The issue is that it may not be clear whether the offerer intended for the
same ICE session to be used, or a new ICE session that happens to use the
same attributes (ufrag/password).

Another option might be to define an "a=3Dice-id" just like we have an
> "a=3Ddtls-id".


Or it could be a generic "a=3Dtransport-id", so it would work with any othe=
r
protocol that may have this problem with BUNDLE.

On Wed, Aug 30, 2017 at 7:36 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> Here is the GitHub issue where me and Taylor discussed this:
>
> https://github.com/cdh4u/draft-sdp-bundle/issues/26
>
> The outcome was that we need to say "something", but there is not more
> than that, so feel free to suggest :)
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer
> Holmberg
> Sent: 30 August 2017 16:27
> To: Byron Campen ; Taylor Brandstetter <
> deadbeef@google.com>; RTCWeb IETF 
> Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
>
> Hi,
>
> >>>      Alright, if we want to write a rule that the transport follows
> >>> the bundle, what about this?
> >>>
> >>> a=3Dgroup:BUNDLE mid1 mid2
> >>> a=3Dgroup:BUNDLE mid3 mid4
> >>>
> >>> and in a reoffer
> >>>
> >>> a=3Dgroup:BUNDLE mid2 mid3
> >>> a=3Dgroup:BUNDLE mid4 mid1
> >>>
> >>>      What transport goes where?
> >>
> >> I think Taylor raised this issue earlier. What you are doing above is
> >> moving streams from one BUNDLE group to another, and mixing the
> >> BUNDLE groups up, and I don=E2=80=99t think that=E2=80=99s a good idea=
.
> >
> > If you want to classify this as a bad idea, we need normative language
> > forbidding it. For instance, a rule that once a mid is placed in a
> bundle, the only way to remove it is to disable it, as well as a rule to
> handle the following:
> >
> > a=3Dgroup:BUNDLE mid2 mid3
> > a=3Dmid: mid1 <--- not bundled
> >...
> >a=3Dmid: mid2
> >...
> >a=3Dmid: mid3
> >
> >and in a reoffer
> >
> >a=3Dgroup mid1 mid2 mid3
> >
> >  We would need to define which transport is retained; mid1's, or the
> bundle's. Or perhaps a rule forbidding previously unbundled mids to be
> added to a bundle.
>
> Me and Taylor did discuss some restriction text. I'll dig in my achieve.
>
> >There are lots of corner cases here that simply aren't specified right
> >now. In the non-trickle-ICE case, this is ok, because the offerer
> unambiguously signals what transports it uses where in the c=3D line.
>
> I think that's a separate problem.
>
> I do agree that the BUNDLE group transport is currently bound to the c/m-
> line. If ICE is used, we should probably use candidate information instea=
d.
>
> Regards,
>
> Christer
>
>
>
> >> Best regards,
> >> Byron Campen
> >>
> >> On 8/30/17 5:18 AM, Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>> Maybe I=C2=B9m missing something, but I fail to see what the problem =
is.
> >>>
> >>> If the BUNDLE-tag section is changed (e.g., because the current
> >>> BUNDLE-tag section m- line is rejected) you simply include the
> >>> TRANSPORT/IDENTICAL category attributes in the new BUNDLE-tag
> >>> section m- line.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"
> >>>  wrote:
> >>>
> >>>> On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
> >>>>> Some ideas for how to resolve it:
> >>>>>
> >>>>> 1. Require ufrags to be unique for different ICE sessions (JSEP
> >>>>> already requires this), and use the ufrag as the unique identifier.
> >>>>> Then the BUNDLE semantics could be used as-is, with "unique/shared
> >>>>> ufrag" replacing "unique/shared address".
> >>>>       I think this is our best option. It should allow trickle ICE
> >>>> to work as well as anything else. We might still want to do some of
> >>>> the below in addition.
> >>>>
> >>>>> 2. For ICE, instead of using a "shared address" to mean
> >>>>> "guaranteed to use the existing BUNDLE transport", use
> >>>>> "a=3Dbundle-only" in subsequent offers. If we were to do this, we
> >>>>> may also need to allow the offerer BUNDLE-tag section to be
> >>>>> rejected; that's currently not supported (https://github.com/cdh4u/
> draft-sdp-bundle/issues/22).
> >>>>       This does not help clarify things when the offerer changes
> >>>> the BUNDLE tag (disable, remove from BUNDLE, make something else
> >>>> the BUNDLE-tag, etc).
> >>>>
> >>>>> 3. Since the "shared address" rules say "don't associate
> >>>>> TRANSPORT/IDENTICAL category attributes with m=3D sections other
> >>>>> than the offerer BUNDLE-tag section", we could interpret "m=3D
> >>>>> section has no transport attributes of its own" as "using shared
> address".
> >>>>       I don't think this helps when the offerer changes the
> >>>> BUNDLE-tag either.
> >>>>
> >>>> Best regards,
> >>>> Byron Campen
> >>>>
> >>>> _______________________________________________
> >>>> 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
>

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


Maybe I=C2=B9m missing something, but I fail to se=
e what the problem is.
If the BUNDLE-tag section is changed (e.g., because the c=
urrent BUNDLE-tag
section m- lin=
e is rejected) you simply include the TRANSPORT/IDENTICAL
category attributes in the new BUNDLE-tag section=
 m- line.

The issue is that it may n=
ot be clear whether the offerer intended for the same ICE session to be use=
d, or a new ICE session that happens to use the same attributes (ufrag/pass=
word).

Another option might be to define an &qu=
ot;a=3Dice-id" just like we have an "a=3Ddtls-id".

Or it could be a generic "a=3Dtransport-=
id", so it would work with any other protocol that may have this probl=
em with BUNDLE.

On Wed, Aug 30, 2017 at 7:36 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,



Here is the GitHub issue where me and Taylor discussed this:



https://github.com/cdh4u/draft-sdp-bundle/is=
sues/26



The outcome was that we need to say "something", but there is not=
 more than that, so feel free to suggest :)



Regards,



Christer




-----Original Message-----

From: rtcweb [mailto:rtcweb-boun=
ces@ietf.org] On Behalf Of Christer Holmberg

Sent: 30 August 2017 16:27

To: Byron Campen <bcampen@mozilla=
.com>; Taylor Brandstetter <deadbeef@google.com>; RTCWeb IETF <rtcweb@ietf.org>

Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?



Hi,



>>>=C2=A0 =C2=A0 =C2=A0 Alright, if we want to write a rule that t=
he transport follows

>>> the bundle, what about this?

>>>

>>> a=3Dgroup:BUNDLE mid1 mid2

>>> a=3Dgroup:BUNDLE mid3 mid4

>>>

>>> and in a reoffer

>>>

>>> a=3Dgroup:BUNDLE mid2 mid3

>>> a=3Dgroup:BUNDLE mid4 mid1

>>>

>>>=C2=A0 =C2=A0 =C2=A0 What transport goes where?

>>

>> I think Taylor raised this issue earlier. What you are doing above=
 is

>> moving streams from one BUNDLE group to another, and mixing the
>> BUNDLE groups up, and I don=E2=80=99t think that=E2=80=99s a good =
idea.

>

> If you want to classify this as a bad idea, we need normative language=


> forbidding it. For instance, a rule that once a mid is placed in a bun=
dle, the only way to remove it is to disable it, as well as a rule to handl=
e the following:

>

> a=3Dgroup:BUNDLE mid2 mid3

> a=3Dmid: mid1 <--- not bundled

>...

>a=3Dmid: mid2

>...

>a=3Dmid: mid3

>

>and in a reoffer

>

>a=3Dgroup mid1 mid2 mid3

>

>=C2=A0=C2=A0We would need to define which transport is retained; mid1&#=
39;s, or the bundle's. Or perhaps a rule forbidding previously unbundle=
d mids to be added to a bundle.



Me and Taylor did discuss some restriction text. I'll dig in my achieve=
.



>There are lots of corner cases here that simply aren't specified ri=
ght

>now. In the non-trickle-ICE case, this is ok, because the offerer unamb=
iguously signals what transports it uses where in the c=3D line.



I think that's a separate problem.



I do agree that the BUNDLE group transport is currently bound to the c/m- l=
ine. If ICE is used, we should probably use candidate information instead.<=
br>


Regards,



Christer







>> Best regards,

>> Byron Campen

>>

>> On 8/30/17 5:18 AM, Christer Holmberg wrote:

>>> Hi,

>>>

>>> Maybe I=C2=B9m missing something, but I fail to see what the p=
roblem is.

>>>

>>> If the BUNDLE-tag section is changed (e.g., because the curren=
t

>>> BUNDLE-tag section m- line is rejected) you simply include the=


>>> TRANSPORT/IDENTICAL category attributes in the new BUNDLE-tag<=
br>
>>> section m- line.

>>>

>>> Regards,

>>>

>>> Christer

>>>

>>>

>>>

>>>

>>>

>>> On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"=
;

>>> <rtcweb-bounces@=
ietf.org on behalf of bcampen@mo=
zilla.com> wrote:

>>>

>>>> On 8/29/17 11:35 AM, Taylor Brandstetter wrote:

>>>>> Some ideas for how to resolve it:

>>>>>

>>>>> 1. Require ufrags to be unique for different ICE sessi=
ons (JSEP

>>>>> already requires this), and use the ufrag as the uniqu=
e identifier.

>>>>> Then the BUNDLE semantics could be used as-is, with &q=
uot;unique/shared

>>>>> ufrag" replacing "unique/shared address"=
;.

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0I think this is our best option.=
 It should allow trickle ICE

>>>> to work as well as anything else. We might still want to d=
o some of

>>>> the below in addition.

>>>>

>>>>> 2. For ICE, instead of using a "shared address&qu=
ot; to mean

>>>>> "guaranteed to use the existing BUNDLE transport&=
quot;, use

>>>>> "a=3Dbundle-only" in subsequent offers. If w=
e were to do this, we

>>>>> may also need to allow the offerer BUNDLE-tag section =
to be

>>>>> rejected; that's currently not supported (https://github.com/cdh4u/draft-sdp-bundle/issues/22=
).

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not help clarify thing=
s when the offerer changes

>>>> the BUNDLE tag (disable, remove from BUNDLE, make somethin=
g else

>>>> the BUNDLE-tag, etc).

>>>>

>>>>> 3. Since the "shared address" rules say &quo=
t;don't associate

>>>>> TRANSPORT/IDENTICAL category attributes with m=3D sect=
ions other

>>>>> than the offerer BUNDLE-tag section", we could in=
terpret "m=3D

>>>>> section has no transport attributes of its own" a=
s "using shared address".

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0I don't think this helps whe=
n the offerer changes the

>>>> BUNDLE-tag either.

>>>>

>>>> Best regards,

>>>> Byron Campen

>>>>

>>>> _______________________________________________

>>>> rtcweb mailing list

>>>> rtcweb@ietf.org

>>>> https://www.ietf.org/mailman/listi=
nfo/rtcweb

>>



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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




--001a1146d950ed15010557fceb98--


From nobody Wed Aug 30 12:59:17 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 10B73132351 for ; Wed, 30 Aug 2017 12:59:16 -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 yjK4fdu-HUdN for ; Wed, 30 Aug 2017 12:59:13 -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 BA3FB126B7E for ; Wed, 30 Aug 2017 12:59:12 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-f8-59a7190e919c
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3C.5E.21299.E0917A95; Wed, 30 Aug 2017 21:59:11 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 21:59:08 +0200
From: Christer Holmberg 
To: Taylor Brandstetter 
CC: Byron Campen , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAACvJcIAAA1zwgAAkJwCAADSh4A==
Date: Wed, 30 Aug 2017 19:59:07 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD0C94C@ESESSMB109.ericsson.se>
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD0AFA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CD0B071@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdUZdfcnmkwYLlTBYL77WyWFxe8ZDV Yu2/dnYHZo8Fm0o9liz5yeTRd6CLNYA5issmJTUnsyy1SN8ugSvjyvP/7AX/bCp2bHrJ0sC4 xbqLkZNDQsBE4uvvGaxdjFwcQgJHGCU2zO9nBEkICSxhlFgzObuLkYODTcBCovufNkhYREBX 4ubXhWwgNrOAq8SGH/dZQUqEBRwlJswTAjFFBJwkfjVEQ1RnSezd+psFxGYRUJW4uek0M4jN K+Ar0Td3E9TWRSwS57s7wbZyCgRK9F6cADaeUUBM4vupNUwQq8Qlbj2ZzwRxsoDEkj3nmSFs UYmXj/+xQthKEmsPb2cBuYFZQFNi/S59iFZFiSndD9kh9gpKnJz5hGUCo+gsJFNnIXTMQtIx C0nHAkaWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBEXNwy2/VHYyX3zgeYhTgYFTi4VXj Wh4pxJpYVlyZe4hRgoNZSYTXTBAoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU 7NTUgtQimCwTB6dUA2OdoV7jb8UjScfYRDOF63SleTxXhXwTidlUtddVq2lZUHfQrPMSrkdP 6lbf5k1SP1dU1buycFdtUfr2v/z8C6wO3P354fijyns/10dLLb25Ol2aNeNidPms8n3njoqH Bx+y1jk1e++Fz3WlLef/vz6yvEemn5FVNVj2RVmI+tPTtV5ZCk6LzZRYijMSDbWYi4oTAb97 gPSUAgAA
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 19:59:16 -0000

SGksDQoNCj4+IE1heWJlIEnCuW0gbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBJIGZhaWwgdG8gc2Vl
IHdoYXQgdGhlIHByb2JsZW0gaXMuDQo+PiBJZiB0aGUgQlVORExFLXRhZyBzZWN0aW9uIGlzIGNo
YW5nZWQgKGUuZy4sIGJlY2F1c2UgdGhlIGN1cnJlbnQgQlVORExFLXRhZw0KPj4gc2VjdGlvbiBt
LSBsaW5lIGlzIHJlamVjdGVkKSB5b3Ugc2ltcGx5IGluY2x1ZGUgdGhlIFRSQU5TUE9SVC9JREVO
VElDQUwNCj4+IGNhdGVnb3J5IGF0dHJpYnV0ZXMgaW4gdGhlIG5ldyBCVU5ETEUtdGFnIHNlY3Rp
b24gbS0gbGluZS4NCj4+DQo+IFRoZSBpc3N1ZSBpcyB0aGF0IGl0IG1heSBub3QgYmUgY2xlYXIg
d2hldGhlciB0aGUgb2ZmZXJlciBpbnRlbmRlZCBmb3IgdGhlIHNhbWUNCj4gSUNFIHNlc3Npb24g
dG8gYmUgdXNlZCwgb3IgYSBuZXcgSUNFIHNlc3Npb24gdGhhdCBoYXBwZW5zIHRvIHVzZSB0aGUg
c2FtZSBhdHRyaWJ1dGVzICh1ZnJhZy9wYXNzd29yZCkuDQoNCldlbGwsIHRoZW4geW91IG5lZWQg
YW5vdGhlciB3YXkgdG8gaW5kaWNhdGUgdGhhdCB5b3UgbmVlZCBhIG5ldyBJQ0Ugc2Vzc2lvbiwg
YmVjYXVzZSByZW1vdmluZy9yZWplY3RpbmcgYSBtZWRpYSBzdHJlYW0gZnJvbSBhIEJVTkRMRSBn
cm91cCBkb2VzIG5vdCB0cmlnZ2VyIGEgbmV3IElDRSBzZXNzaW9uIGJ5IGl0c2VsZi4NCg0KPiBB
bm90aGVyIG9wdGlvbiBtaWdodCBiZSB0byBkZWZpbmUgYW4gImE9aWNlLWlkIiBqdXN0IGxpa2Ug
d2UgaGF2ZSBhbiAiYT1kdGxzLWlkIi4NCj4NCj4gT3IgaXQgY291bGQgYmUgYSBnZW5lcmljICJh
PXRyYW5zcG9ydC1pZCIsIHNvIGl0IHdvdWxkIHdvcmsgd2l0aCBhbnkgb3RoZXIgcHJvdG9jb2wg
dGhhdCBtYXkgaGF2ZSB0aGlzIHByb2JsZW0gd2l0aCBCVU5ETEUuDQoNCkNvdWxkbid0IHdlIHNw
ZWNpZnkgdGhhdCBhIG5ldyB1ZnJhZyB0cmlnZ2VycyBhbiBJQ0UgcmVzdGFydD8NCg0KUmVnYXJk
cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KT24gV2VkLCBBdWcgMzAsIDIwMTcgYXQgNzoz
NiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g
d3JvdGU6DQpIaSwNCg0KSGVyZSBpcyB0aGUgR2l0SHViIGlzc3VlIHdoZXJlIG1lIGFuZCBUYXls
b3IgZGlzY3Vzc2VkIHRoaXM6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAt
YnVuZGxlL2lzc3Vlcy8yNg0KDQpUaGUgb3V0Y29tZSB3YXMgdGhhdCB3ZSBuZWVkIHRvIHNheSAi
c29tZXRoaW5nIiwgYnV0IHRoZXJlIGlzIG5vdCBtb3JlIHRoYW4gdGhhdCwgc28gZmVlbCBmcmVl
IHRvIHN1Z2dlc3QgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDMwIEF1Z3VzdCAyMDE3IDE2
OjI3DQpUbzogQnlyb24gQ2FtcGVuIDxiY2FtcGVuQG1vemlsbGEuY29tPjsgVGF5bG9yIEJyYW5k
c3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbT47IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQW1iaWd1aXRpZXMgd2l0aCBCVU5ETEUgd2hlbiB1
c2VkIHdpdGggSUNFPw0KDQpIaSwNCg0KPj4+wqAgwqAgwqAgQWxyaWdodCwgaWYgd2Ugd2FudCB0
byB3cml0ZSBhIHJ1bGUgdGhhdCB0aGUgdHJhbnNwb3J0IGZvbGxvd3MNCj4+PiB0aGUgYnVuZGxl
LCB3aGF0IGFib3V0IHRoaXM/DQo+Pj4NCj4+PiBhPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDINCj4+
PiBhPWdyb3VwOkJVTkRMRSBtaWQzIG1pZDQNCj4+Pg0KPj4+IGFuZCBpbiBhIHJlb2ZmZXINCj4+
Pg0KPj4+IGE9Z3JvdXA6QlVORExFIG1pZDIgbWlkMw0KPj4+IGE9Z3JvdXA6QlVORExFIG1pZDQg
bWlkMQ0KPj4+DQo+Pj7CoCDCoCDCoCBXaGF0IHRyYW5zcG9ydCBnb2VzIHdoZXJlPw0KPj4NCj4+
IEkgdGhpbmsgVGF5bG9yIHJhaXNlZCB0aGlzIGlzc3VlIGVhcmxpZXIuIFdoYXQgeW91IGFyZSBk
b2luZyBhYm92ZSBpcw0KPj4gbW92aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRv
IGFub3RoZXIsIGFuZCBtaXhpbmcgdGhlDQo+PiBCVU5ETEUgZ3JvdXBzIHVwLCBhbmQgSSBkb27i
gJl0IHRoaW5rIHRoYXTigJlzIGEgZ29vZCBpZGVhLg0KPg0KPiBJZiB5b3Ugd2FudCB0byBjbGFz
c2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlIGxhbmd1YWdlDQo+IGZv
cmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBpcyBwbGFj
ZWQgaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMgdG8gZGlzYWJsZSBp
dCwgYXMgd2VsbCBhcyBhIHJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dpbmc6DQo+DQo+IGE9Z3Jv
dXA6QlVORExFIG1pZDIgbWlkMw0KPiBhPW1pZDogbWlkMSA8LS0tIG5vdCBidW5kbGVkDQo+Li4u
DQo+YT1taWQ6IG1pZDINCj4uLi4NCj5hPW1pZDogbWlkMw0KPg0KPmFuZCBpbiBhIHJlb2ZmZXIN
Cj4NCj5hPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQo+DQo+wqDCoFdlIHdvdWxkIG5lZWQgdG8gZGVm
aW5lIHdoaWNoIHRyYW5zcG9ydCBpcyByZXRhaW5lZDsgbWlkMSdzLCBvciB0aGUgYnVuZGxlJ3Mu
IE9yIHBlcmhhcHMgYSBydWxlIGZvcmJpZGRpbmcgcHJldmlvdXNseSB1bmJ1bmRsZWQgbWlkcyB0
byBiZSBhZGRlZCB0byBhIGJ1bmRsZS4NCg0KTWUgYW5kIFRheWxvciBkaWQgZGlzY3VzcyBzb21l
IHJlc3RyaWN0aW9uIHRleHQuIEknbGwgZGlnIGluIG15IGFjaGlldmUuDQoNCj5UaGVyZSBhcmUg
bG90cyBvZiBjb3JuZXIgY2FzZXMgaGVyZSB0aGF0IHNpbXBseSBhcmVuJ3Qgc3BlY2lmaWVkIHJp
Z2h0DQo+bm93LiBJbiB0aGUgbm9uLXRyaWNrbGUtSUNFIGNhc2UsIHRoaXMgaXMgb2ssIGJlY2F1
c2UgdGhlIG9mZmVyZXIgdW5hbWJpZ3VvdXNseSBzaWduYWxzIHdoYXQgdHJhbnNwb3J0cyBpdCB1
c2VzIHdoZXJlIGluIHRoZSBjPSBsaW5lLg0KDQpJIHRoaW5rIHRoYXQncyBhIHNlcGFyYXRlIHBy
b2JsZW0uDQoNCkkgZG8gYWdyZWUgdGhhdCB0aGUgQlVORExFIGdyb3VwIHRyYW5zcG9ydCBpcyBj
dXJyZW50bHkgYm91bmQgdG8gdGhlIGMvbS0gbGluZS4gSWYgSUNFIGlzIHVzZWQsIHdlIHNob3Vs
ZCBwcm9iYWJseSB1c2UgY2FuZGlkYXRlIGluZm9ybWF0aW9uIGluc3RlYWQuDQoNClJlZ2FyZHMs
DQoNCkNocmlzdGVyDQoNCg0KDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBCeXJvbiBDYW1wZW4NCj4+
DQo+PiBPbiA4LzMwLzE3IDU6MTggQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+IEhp
LA0KPj4+DQo+Pj4gTWF5YmUgScK5bSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZmFpbCB0byBz
ZWUgd2hhdCB0aGUgcHJvYmxlbSBpcy4NCj4+Pg0KPj4+IElmIHRoZSBCVU5ETEUtdGFnIHNlY3Rp
b24gaXMgY2hhbmdlZCAoZS5nLiwgYmVjYXVzZSB0aGUgY3VycmVudA0KPj4+IEJVTkRMRS10YWcg
c2VjdGlvbiBtLSBsaW5lIGlzIHJlamVjdGVkKSB5b3Ugc2ltcGx5IGluY2x1ZGUgdGhlDQo+Pj4g
VFJBTlNQT1JUL0lERU5USUNBTCBjYXRlZ29yeSBhdHRyaWJ1dGVzIGluIHRoZSBuZXcgQlVORExF
LXRhZw0KPj4+IHNlY3Rpb24gbS0gbGluZS4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+PiBD
aHJpc3Rlcg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAyOS8wOC8xNyAxOTo0NSwg
InJ0Y3dlYiBvbiBiZWhhbGYgb2YgQnlyb24gQ2FtcGVuIg0KPj4+IDxydGN3ZWItYm91bmNlc0Bp
ZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmNhbXBlbkBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+Pj4NCj4+
Pj4gT24gOC8yOS8xNyAxMTozNSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToNCj4+Pj4+
IFNvbWUgaWRlYXMgZm9yIGhvdyB0byByZXNvbHZlIGl0Og0KPj4+Pj4NCj4+Pj4+IDEuIFJlcXVp
cmUgdWZyYWdzIHRvIGJlIHVuaXF1ZSBmb3IgZGlmZmVyZW50IElDRSBzZXNzaW9ucyAoSlNFUA0K
Pj4+Pj4gYWxyZWFkeSByZXF1aXJlcyB0aGlzKSwgYW5kIHVzZSB0aGUgdWZyYWcgYXMgdGhlIHVu
aXF1ZSBpZGVudGlmaWVyLg0KPj4+Pj4gVGhlbiB0aGUgQlVORExFIHNlbWFudGljcyBjb3VsZCBi
ZSB1c2VkIGFzLWlzLCB3aXRoICJ1bmlxdWUvc2hhcmVkDQo+Pj4+PiB1ZnJhZyIgcmVwbGFjaW5n
ICJ1bmlxdWUvc2hhcmVkIGFkZHJlc3MiLg0KPj4+PsKgIMKgIMKgIMKgSSB0aGluayB0aGlzIGlz
IG91ciBiZXN0IG9wdGlvbi4gSXQgc2hvdWxkIGFsbG93IHRyaWNrbGUgSUNFDQo+Pj4+IHRvIHdv
cmsgYXMgd2VsbCBhcyBhbnl0aGluZyBlbHNlLiBXZSBtaWdodCBzdGlsbCB3YW50IHRvIGRvIHNv
bWUgb2YNCj4+Pj4gdGhlIGJlbG93IGluIGFkZGl0aW9uLg0KPj4+Pg0KPj4+Pj4gMi4gRm9yIElD
RSwgaW5zdGVhZCBvZiB1c2luZyBhICJzaGFyZWQgYWRkcmVzcyIgdG8gbWVhbg0KPj4+Pj4gImd1
YXJhbnRlZWQgdG8gdXNlIHRoZSBleGlzdGluZyBCVU5ETEUgdHJhbnNwb3J0IiwgdXNlDQo+Pj4+
PiAiYT1idW5kbGUtb25seSIgaW4gc3Vic2VxdWVudCBvZmZlcnMuIElmIHdlIHdlcmUgdG8gZG8g
dGhpcywgd2UNCj4+Pj4+IG1heSBhbHNvIG5lZWQgdG8gYWxsb3cgdGhlIG9mZmVyZXIgQlVORExF
LXRhZyBzZWN0aW9uIHRvIGJlDQo+Pj4+PiByZWplY3RlZDsgdGhhdCdzIGN1cnJlbnRseSBub3Qg
c3VwcG9ydGVkIChodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9pc3N1
ZXMvMjIpLg0KPj4+PsKgIMKgIMKgIMKgVGhpcyBkb2VzIG5vdCBoZWxwIGNsYXJpZnkgdGhpbmdz
IHdoZW4gdGhlIG9mZmVyZXIgY2hhbmdlcw0KPj4+PiB0aGUgQlVORExFIHRhZyAoZGlzYWJsZSwg
cmVtb3ZlIGZyb20gQlVORExFLCBtYWtlIHNvbWV0aGluZyBlbHNlDQo+Pj4+IHRoZSBCVU5ETEUt
dGFnLCBldGMpLg0KPj4+Pg0KPj4+Pj4gMy4gU2luY2UgdGhlICJzaGFyZWQgYWRkcmVzcyIgcnVs
ZXMgc2F5ICJkb24ndCBhc3NvY2lhdGUNCj4+Pj4+IFRSQU5TUE9SVC9JREVOVElDQUwgY2F0ZWdv
cnkgYXR0cmlidXRlcyB3aXRoIG09IHNlY3Rpb25zIG90aGVyDQo+Pj4+PiB0aGFuIHRoZSBvZmZl
cmVyIEJVTkRMRS10YWcgc2VjdGlvbiIsIHdlIGNvdWxkIGludGVycHJldCAibT0NCj4+Pj4+IHNl
Y3Rpb24gaGFzIG5vIHRyYW5zcG9ydCBhdHRyaWJ1dGVzIG9mIGl0cyBvd24iIGFzICJ1c2luZyBz
aGFyZWQgYWRkcmVzcyIuDQo+Pj4+wqAgwqAgwqAgwqBJIGRvbid0IHRoaW5rIHRoaXMgaGVscHMg
d2hlbiB0aGUgb2ZmZXJlciBjaGFuZ2VzIHRoZQ0KPj4+PiBCVU5ETEUtdGFnIGVpdGhlci4NCj4+
Pj4NCj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+PiBCeXJvbiBDYW1wZW4NCj4+Pj4NCj4+Pj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gcnRjd2Vi
IG1haWxpbmcgbGlzdA0KPj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+DQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJA
aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN
Cg==


From nobody Wed Aug 30 14:10:24 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 34F49132A81 for ; Wed, 30 Aug 2017 14:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 GHbni9gFQw_n for ; Wed, 30 Aug 2017 14:10:19 -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 D6F74132940 for ; Wed, 30 Aug 2017 14:10:18 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id s101so11390046ioe.0 for ; Wed, 30 Aug 2017 14:10:18 -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=0t62tKGL+hHjNOpTlRhLKIoKToSQvKoBIAvHlszzDAA=; b=Di9gvG9uf0PoY9sHwnLWuL0OvgkbGRFxVHoyBq+NfDj9y1c0T0sB/uRZ1z2c8OfIUH mRN83F6TenKhtDRvMADFTgsZGvXrjHOrljch376XNd0b/XCq6etPt7X5X7EkruyDf7H9 +ye0Ju1X5kNij2QSyd1MvxO9BfAhFW1NYkVxsGfFhumDQ1KfD/DJp3z4WA0/rSBzFiwq q0JFJMu4V3fNnM0PZ+qyxhSqtx9uHeVyB3mJ3nedjWWC84YFDYUfIYwgqgd8Crm0RYOF e3ZCm9UnDUK3hJ5HTsALf77tz+CZiLQULjn21y3wNXKd7Ub+G+r7glc1eSbMDrSTuuLc 2Zbw==
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=0t62tKGL+hHjNOpTlRhLKIoKToSQvKoBIAvHlszzDAA=; b=EgDzpZhnuyPZEFn+VO/XT79qsibboQdNlOn2QL7xVQiKJn8WydEDZyZpr1QCSLlUyv 1SPyKxe49JynEIWS8juiUzO2mrq9J8cpTj+aDfVfovDMENobZKwGGVhUlvH7wqQptNEq XoGKLrci/pPmLjsl0NxTcCaSwiEQZOzpPITio/h1po9E5ANkQE6fDDMxVa/274QeCScS R5PS7X5Om8yLPDStj1ZdIP86W1A5obQEyQRTUH1LOeZgRlLFGTkTYkldoefk/0wZ+cAD F+3L3baYgYWkVR8OBo4noTig9LtbSAZFZYleRRox9NQqLL6Ean/EXG2xRfCrdVlkBvZH Lozg==
X-Gm-Message-State: AHYfb5gtMP0At/knvwq93YDZUQIIRzNtM6NlH17SnivBvlZUq0H+qZG9 TUliZAA7ydjqRU253yBWyjXxUMsXM0YJ
X-Google-Smtp-Source: ADKCNb7opnOxmBY1MuGcYZfbspwIj7yzdnu6PIgWQKonDSaWGb9edBlEDcEOZmP1s0xo//OPOgNxiURNsmWrhYbWp/M=
X-Received: by 10.36.84.193 with SMTP id t184mr2410763ita.115.1504127417610; Wed, 30 Aug 2017 14:10:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.148.209 with HTTP; Wed, 30 Aug 2017 14:09:56 -0700 (PDT)
In-Reply-To: 
References:  
From: Justin Uberti 
Date: Wed, 30 Aug 2017 14:09:56 -0700
Message-ID: 
To: Peter Thatcher 
Cc: Taylor Brandstetter , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a11c156726d31f60557fef4c9"
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 21:10:22 -0000

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

On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher 
wrote:

>
>
> On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter 
> wrote:
>
>> Spawned from this thread on public-webrtc@w3.org:
>> https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html
>>
>> And raised as an issue on webrtc-pc's github page here:
>> https://github.com/w3c/webrtc-pc/issues/1563
>>
>> The main issue, as I interpret it, is that BUNDLE is written with the
>> assumption that a transport can be identified by an address (the "BUNDLE
>> address"). An offer has a different meaning depending on whether a "shared
>> address" or "unique address" is used for the m= sections in the BUNDLE
>> group. But for ICE (and specifically trickle ICE), this assumption doesn't
>> hold. The address used by an ICE session may change from one offer to the
>> next, and if no candidates have been gathered yet, it may just be "
>> 0.0.0.0:9". So there's no piece of information that can be used
>> authoritatively to match an ICE transport in one blob of SDP to an ICE
>> transport in another blob.
>>
>
> It does seem like a serious oversight that BUNDLE is written in terms of
> using addresses as identifiers when such addresses don't exist when doing
> trickle ICE.  That means (BUNDLE + trickle ICE) may have lots of things
> undefined.
>
> It seems like we need to define an ID for (BUNDLE + trickle ICE), either
> by saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE
> by saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes
> more sense.
>
>
>>
>> So, current implementations (at least Chrome/Firefox) follow a simplified
>> model of "transport follows m= section".  However, this behavior isn't
>> covered explicitly by the standard, and it has its downsides. It means if
>> the m= section associated with the current ICE transport is rejected, a new
>> ICE transport needs to be set up (or worse, things just stop working
>> completely).
>>
>> Example:
>>
>> *Offer (for already-established BUNDLE group)*
>>
>> a=group:BUNDLE audio video
>> m=audio 9 ...
>> c=IN IP4 0.0.0.0
>> a=ice-ufrag:foo
>> a=ice-pwd:bar
>> a=mid:audio
>> ...
>> m=video 9 ...
>> c=IN IP4 0.0.0.0
>> a=ice-ufrag:foo
>> a=ice-pwd:bar
>> a=mid:video
>>
>> *Answer*
>>
>> a=group:BUNDLE video
>> m=audio 0 ...
>> c=IN IP4 0.0.0.0
>> a=mid:audio
>> ...
>> m=video 9 ...
>> c=IN IP4 0.0.0.0
>> a=ice-ufrag:baz
>> a=ice-pwd:buz
>> a=mid:video
>>
>>
>> Does this mean the existing "audio" ICE session continues to be used, or
>> is a new "video" one created? There's no established way for the offerer to
>> indicate what it desires, since there's no way to provide a "unique/shared
>> address" distinction. Where "unique" means "can fall back to using a
>> different transport," and "shared" means "will use the existing transport"
>> (assuming I've interpreted BUNDLE correctly; I may be reading between the
>> lines too much).
>>
>>
> So let me see if I understand this...  First, it's only for re-offer
> cases, right?
> In that case, the re-offer would like to say one of the following?
>
> 1.  (Shared) "We're currently sending contents CA and CB over transport
> TA; let's keep doing that;  but if you want to stop sending CA, let's keep
> sending CB over TA".
>
> or
>
> 2.  (Unique) "We're currently sending contents CA and CB over transport
> TA; let's keep doing that;  but if you want to stop sending CA, throw away
> TA and let's make a new TB and send CB over that".
>
>
> But right now all the re-offerer can say is "We're currently sending
> contents CA and CB over transport TA; let's keep doing that;  if you reject
> CA ... I don't know; please don't do that".
>
>
> There are other ambiguous situations, but this is the one that started the
>> recent discussion.
>>
>> Is this a real issue, or have I missed something? Given that there's now
>> an API for rejecting "m=" sections, it's no longer just a corner case, but
>> something possible with basic usage of the PeerConnection API. So it seems
>> worth addressing.
>>
>
>> Some ideas for how to resolve it:
>>
>> 1. Require ufrags to be unique for different ICE sessions (JSEP already
>> requires this), and use the ufrag as the unique identifier. Then the BUNDLE
>> semantics could be used as-is, with "unique/shared ufrag" replacing
>> "unique/shared address".
>>
>
> This seems like a good approach.  We're already using ufrag as an ICE
> session identifier in trickle ICE to handle ICE restart edge cases.   And
> there might be lots of edge cases around the problem of not being able to
> identify transports with addresses.
>
>
>> 2. For ICE, instead of using a "shared address" to mean "guaranteed to
>> use the existing BUNDLE transport", use "a=bundle-only" in subsequent
>> offers. If we were to do this, we may also need to allow the offerer
>> BUNDLE-tag section to be rejected; that's currently not supported (
>> https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>> 3. Since the "shared address" rules say "don't associate
>> TRANSPORT/IDENTICAL category attributes with m= sections other than the
>> offerer BUNDLE-tag section", we could interpret "m= section has no
>> transport attributes of its own" as "using shared address".
>>
>
> Another option might be to define an "a=ice-id" just like we have an
> "a=dtls-id".   When using ICE, that can function as the ID instead of the
> address.  Or we could go with "a=transport-id" and just have an ID for the
> transport that works for ICE and non-ICE and we could rewrite everything in
> BUNDLE that relies on addresses for IDs and use the a=transport-id
> instead.  Would that work?
>
>

We're starting to accumulate a lot of IDs in SDP. If we can make ufrag work
as an identifier for the ICE session in BUNDLE, I think we should do so; as
you note, we're already using it as such elsewhere.

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




On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher <=
pthatcher@google.=
com> wrote:


On T=
ue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter <deadbeef@google.com> wrote:

<=
div>And raised as an issue on webrtc-pc's github page here:=C2=A0https:=
//github.com/w3c/webrtc-pc/issues/1563

Th=
e main issue, as I interpret it, is that BUNDLE is written with the assumpt=
ion that a transport can be identified by an address (the "BUNDLE addr=
ess"). An offer has a different meaning depending on whether a "s=
hared address" or "unique address" is used for the m=3D sect=
ions in the BUNDLE group. But for ICE (and specifically trickle ICE), this =
assumption doesn't hold. The address used by an ICE session may change =
from one offer to the next, and if no candidates have been gathered yet, it=
 may just be "0.0.0.0:9=
". So there's no piece of information that can be used authori=
tatively to match an ICE transport in one blob of SDP to an ICE transport i=
n another blob.

It does =
seem like a serious oversight that BUNDLE is written in terms of using addr=
esses as identifiers when such addresses don't exist when doing trickle=
 ICE.=C2=A0 That means (BUNDLE=C2=A0+ trickle ICE) may have lots of things =
undefined.

It seems like we need to define an ID f=
or (BUNDLE=C2=A0+ trickle ICE), either by saying in BUNDLE "when using=
 trickle ICE, the ID is X" or in trickle ICE by saying "when BUND=
Ling, the ID is "X.=C2=A0 I think putting in BUNDLE makes more sense. =
=C2=A0
=C2=A0

So, current implementations (a=
t least Chrome/Firefox) follow a simplified model of "transport follow=
s m=3D section".=C2=A0 However, this behavior isn't covered explic=
itly by the standard, and it has its downsides. It means if the m=3D sectio=
n associated with the current ICE transport is rejected, a new ICE transpor=
t needs to be set up (or worse, things just stop working completely).
=


Example:

Offer (for already=
-established BUNDLE group)

a=3Dgroup:BUNDLE au=
dio video
m=3Daudio 9 ...
c=3DIN IP4 0.0.0.0
<=
div>a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
=

a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:video

Answer

a=3Dgroup:BUN=
DLE video
m=3Daudio 0 ...
c=3DIN IP4 0.0.0.0
<=
div>a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN =
IP4 0.0.0.0
a=3Dice-ufrag:baz
a=3Dice-pwd:buz
=

a=3Dmid:video


Does this mean t=
he existing "audio" ICE session continues to be used, or is a new=
 "video" one created? There's no established way for the offe=
rer to indicate what it desires, since there's no way to provide a &quo=
t;unique/shared address" distinction. Where "unique" means &=
quot;can fall back to using a different transport," and "shared&q=
uot; means "will use the existing transport" (assuming I've i=
nterpreted BUNDLE correctly; I may be reading between the lines too much).<=
/div>


So l=
et me see if I understand this...=C2=A0 First, it's only for re-offer c=
ases, right?=C2=A0
In that case, the re-offer would like to say o=
ne of the following?

1. =C2=A0(Shared) "We=
9;re currently sending contents CA and CB over transport TA; let's keep=
 doing that; =C2=A0but if you want to stop sending CA, let's keep sendi=
ng CB over TA".

or=C2=A0

=

2. =C2=A0(Unique) "We're currently sending contents CA a=
nd CB over transport TA; let's keep doing that; =C2=A0but if you want t=
o stop sending CA, throw away TA and let's make a new TB and send CB ov=
er that".


But right now all the re-offerer can say is &quo=
t;We're currently sending contents CA and CB over transport TA; let'=
;s keep doing that; =C2=A0if you reject CA ... I don't know; please don=
't do that".


There are othe=
r ambiguous situations, but this is the one that started the recent discuss=
ion.

Is this a real issue, or have I missed someth=
ing? Given that there's now an API for rejecting "m=3D" secti=
ons, it's no longer just a corner case, but something possible with bas=
ic usage of the PeerConnection API. So it seems worth addressing.

Some ideas for how to resolve it:

1. Requi=
re ufrags to be unique for different ICE sessions (JSEP already requires th=
is), and use the ufrag as the unique identifier. Then the BUNDLE semantics =
could be used as-is, with "unique/shared ufrag" replacing "u=
nique/shared address".

<=
div>This seems like a good approach.=C2=A0 We're already using ufrag as=
 an ICE session identifier in trickle ICE to handle ICE restart edge cases.=
 =C2=A0 And there might be lots of edge cases around the problem of not bei=
ng able to identify transports with addresses. =C2=A0
=C2=A0
2. F=
or ICE, instead of using a "shared address" to mean "guarant=
eed to use the existing BUNDLE transport", use "a=3Dbundle-only&q=
uot; in subsequent offers. If we were to do this, we may also need to allow=
 the offerer BUNDLE-tag section to be rejected; that's currently not su=
pported (https://github.com/cdh4u/draft-sdp-bundle/issues/22).

=C2=A0

We're starting to accumulate a lot of IDs in SDP. If we can make ufra=
g work as an identifier for the ICE session in BUNDLE, I think we should do=
 so; as you note, we're already using it as such elsewhere.
=



--001a11c156726d31f60557fef4c9--


From nobody Wed Aug 30 14:16:37 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 7DA721321D8 for ; Wed, 30 Aug 2017 14:16:35 -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 GoTEA3pzMsde for ; Wed, 30 Aug 2017 14:16:33 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 92892132195 for ; Wed, 30 Aug 2017 14:16:33 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id z91so21667071wrc.1 for ; Wed, 30 Aug 2017 14:16:33 -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=eiMyp9gEr4qX8tRzgDGW8eHvolPZiNGgGp+2WRdDM/A=; b=FwEZ60S8HPwxwDhFq0Pynu/kBVkraVCBkwmOWQvlD5E+00cBEohql661V4QsmCbw0M ZUIRwClioG7LVrflCEjJ5No8+aG5rZzuN2WBMBtGbL/j6pfw8zhzoul4qnneJWwKAVm8 m97x1EBQ8jcnfUlFrq7rVWr4PR/aKnDjs13TJsKi0V+t3ZwJZsstJi1iCN1VfS2ef4tJ KV8NcBSpui6eRfPcahKOh2nZNqTw7vwwJNxjRxfEM7RgGdF8+D/p7HXRRPpTUnEMSqyA QjZH+8q62uBYSU7JmQ2FsRO9+65WLVHn+LqrPCAaVUdaLmkBtdEmJO9xGp7kBt6Gbd8p V/6Q==
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=eiMyp9gEr4qX8tRzgDGW8eHvolPZiNGgGp+2WRdDM/A=; b=qd/y/jE0li5jYCsc7Q/6mHUDBzjmnOMsIvyf+jkMk35CyfFrNXEbetxmFfXNgVtJ/G lvKl4YWzzDKrAwPo4Q8f4Axr7v0OoautOJ3jFgw8KK4zXb3nvqhWMrv7jVDbUZLQ22TP 15YnzOZ8LKR+tSYPQcsEi1kGcDM4sWrc4FiV5H35iTodNYxjtbswcEG6i6z4M8ikWv+4 aeCZcf7lfTMy88sG+GFe1zCG+pDIFFrsXwRIXLd4NX08RL2RgWpTRsz4WJLHFQZAG0eV q55Un5XLz0rZFgiXrlHxz2bbh2rvT8xiBUEkmu8kG6y5wsPrgEarVOc5OA9K7xah/asN Tauw==
X-Gm-Message-State: AHYfb5g8WfB1YD1tPlT4LqA3s0eG3BExaz6/jvMACWuAZQpl0LESvg8G k55nWfZDkhMfduhQVZJnRrm4UmK2Wg==
X-Received: by 10.223.171.29 with SMTP id q29mr1690144wrc.30.1504127792009; Wed, 30 Aug 2017 14:16:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.43.135 with HTTP; Wed, 30 Aug 2017 14:16:31 -0700 (PDT)
In-Reply-To: 
References:   
From: Sergio Garcia Murillo 
Date: Wed, 30 Aug 2017 23:16:31 +0200
Message-ID: 
To: Justin Uberti 
Cc: "rtcweb@ietf.org" , Peter Thatcher 
Content-Type: multipart/alternative; boundary="94eb2c1b4d9cbd59620557ff0abe"
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 21:16:35 -0000

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

+1

El 30/8/2017 23:10, "Justin Uberti"  escribi=C3=B3:

>
> We're starting to accumulate a lot of IDs in SDP. If we can make ufrag
> work as an identifier for the ICE session in BUNDLE, I think we should do
> so; as you note, we're already using it as such elsewhere.
>
>
>

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


+1

<=
div class=3D"gmail_quote">El 30/8/2017 23:10, "Justin Uberti" <=
;juberti@google.com=
> escribi=C3=B3:
=


We're starting to accumulate a lot of IDs in SDP. I=
f we can make ufrag work as an identifier for the ICE session in BUNDLE, I =
think we should do so; as you note, we're already using it as such else=
where.







--94eb2c1b4d9cbd59620557ff0abe--


From nobody Wed Aug 30 14:53:58 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 6AF87132A89 for ; Wed, 30 Aug 2017 14:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 YQ0OOK9pEqjQ for ; Wed, 30 Aug 2017 14:53:53 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 07B2413239A for ; Wed, 30 Aug 2017 14:53:52 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id k126so33789889qkb.4 for ; Wed, 30 Aug 2017 14:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ahi4JaDBnklqLyhLWY8fGOSARhjudRe4BvDs52w2QBc=; b=T1Q+ZAsqsUuOPpctZ3FLKr08dl8G7cu6kV3qnlpWyY4Wchg6kiadkae2J4gjFZGL+W Y8SJHRdJqIe0fMKM9I8YWKAVER3ju03KLiBASzaFaHv594IPPR1Izj4OAiOVhSj/zYrR 3wrZiJ+4MRnwmF2LUjfiUpIXyN4KfDqp7kGRxSDUZccyOhTdXjeeqdb9Sb8anxAj/5KZ 8YmgRZ8xZ5iPR9bG8+xP6Y5Xy1FkiHaAa6EEPyZfAJ92WAakuZTNcXCwB/UjCrp02dFL ClgNgB1txT4b2DTNoJgKJvsdv/UGUB5WhDzKHgHwQ2i0l2yF50rDZrb/1n9JMf3ZneO5 ZNUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ahi4JaDBnklqLyhLWY8fGOSARhjudRe4BvDs52w2QBc=; b=pZ1f9bs7mDZbe4iOw1nYBZDDLdglfKjC/ra3OJTjkBxozLYj4OdHbB5BFDk++Kyt33 fOrF6bpZuXbVDBi2dD136RaG0LgArcJZxKh0sr7E0KEUXODNPDWvSmfz0+o4vQy8YXIU 2E77a9bUlxw0Z97BIS/g6XDw3tvybsbj2RhmHm+570vUkKuh2OZlaRGqNAc8abwlPiI/ bhvmAOVcsTpMoUrbxgGZW/L7jYEWXYtbsf/C24iXrFFTV+WXjuKrHyVoVTtWEAA1Bq1a mfzUvb6wRYEDc4lP1MtW64dXryie0dCyYJd6xRbpx8IlHI64kTHEYqVj9Ihn/kdtICZh c3+g==
X-Gm-Message-State: AHPjjUgVIvO9o+BlTa42N5EC9qbvQQRlef6EWePymcmuseEIVAM0upMf mGV/rZgEH0qC1uDzvAbI8ZD2iztl6pcp
X-Google-Smtp-Source: ADKCNb5VBwgkWBYzW0M4c1EreGbGvXkGeEj0X1cIOST1GYFbN0tmd6mEd5VgZ3Gu7pFwi6GJLxI8AixOp4k5WrlJhc8=
X-Received: by 10.55.79.81 with SMTP id d78mr987763qkb.19.1504130031949; Wed, 30 Aug 2017 14:53:51 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Peter Thatcher 
Date: Wed, 30 Aug 2017 21:53:41 +0000
Message-ID: 
To: Justin Uberti 
Cc: Taylor Brandstetter , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a114a758e409a6f0557ff9003"
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 30 Aug 2017 21:53:56 -0000

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

Yes, I prefer ufrag as the ID, assuming it works.

On Wed, Aug 30, 2017 at 2:10 PM Justin Uberti  wrote:

> On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher 
> wrote:
>
>>
>>
>> On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter 
>> wrote:
>>
>>> Spawned from this thread on public-webrtc@w3.org:
>>> https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html
>>>
>>> And raised as an issue on webrtc-pc's github page here:
>>> https://github.com/w3c/webrtc-pc/issues/1563
>>>
>>> The main issue, as I interpret it, is that BUNDLE is written with the
>>> assumption that a transport can be identified by an address (the "BUNDLE
>>> address"). An offer has a different meaning depending on whether a "shared
>>> address" or "unique address" is used for the m= sections in the BUNDLE
>>> group. But for ICE (and specifically trickle ICE), this assumption doesn't
>>> hold. The address used by an ICE session may change from one offer to the
>>> next, and if no candidates have been gathered yet, it may just be "
>>> 0.0.0.0:9". So there's no piece of information that can be used
>>> authoritatively to match an ICE transport in one blob of SDP to an ICE
>>> transport in another blob.
>>>
>>
>> It does seem like a serious oversight that BUNDLE is written in terms of
>> using addresses as identifiers when such addresses don't exist when doing
>> trickle ICE.  That means (BUNDLE + trickle ICE) may have lots of things
>> undefined.
>>
>> It seems like we need to define an ID for (BUNDLE + trickle ICE), either
>> by saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE
>> by saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes
>> more sense.
>>
>>
>>>
>>> So, current implementations (at least Chrome/Firefox) follow a
>>> simplified model of "transport follows m= section".  However, this behavior
>>> isn't covered explicitly by the standard, and it has its downsides. It
>>> means if the m= section associated with the current ICE transport is
>>> rejected, a new ICE transport needs to be set up (or worse, things just
>>> stop working completely).
>>>
>>> Example:
>>>
>>> *Offer (for already-established BUNDLE group)*
>>>
>>> a=group:BUNDLE audio video
>>> m=audio 9 ...
>>> c=IN IP4 0.0.0.0
>>> a=ice-ufrag:foo
>>> a=ice-pwd:bar
>>> a=mid:audio
>>> ...
>>> m=video 9 ...
>>> c=IN IP4 0.0.0.0
>>> a=ice-ufrag:foo
>>> a=ice-pwd:bar
>>> a=mid:video
>>>
>>> *Answer*
>>>
>>> a=group:BUNDLE video
>>> m=audio 0 ...
>>> c=IN IP4 0.0.0.0
>>> a=mid:audio
>>> ...
>>> m=video 9 ...
>>> c=IN IP4 0.0.0.0
>>> a=ice-ufrag:baz
>>> a=ice-pwd:buz
>>> a=mid:video
>>>
>>>
>>> Does this mean the existing "audio" ICE session continues to be used, or
>>> is a new "video" one created? There's no established way for the offerer to
>>> indicate what it desires, since there's no way to provide a "unique/shared
>>> address" distinction. Where "unique" means "can fall back to using a
>>> different transport," and "shared" means "will use the existing transport"
>>> (assuming I've interpreted BUNDLE correctly; I may be reading between the
>>> lines too much).
>>>
>>>
>> So let me see if I understand this...  First, it's only for re-offer
>> cases, right?
>> In that case, the re-offer would like to say one of the following?
>>
>> 1.  (Shared) "We're currently sending contents CA and CB over transport
>> TA; let's keep doing that;  but if you want to stop sending CA, let's keep
>> sending CB over TA".
>>
>> or
>>
>> 2.  (Unique) "We're currently sending contents CA and CB over transport
>> TA; let's keep doing that;  but if you want to stop sending CA, throw away
>> TA and let's make a new TB and send CB over that".
>>
>>
>> But right now all the re-offerer can say is "We're currently sending
>> contents CA and CB over transport TA; let's keep doing that;  if you reject
>> CA ... I don't know; please don't do that".
>>
>>
>> There are other ambiguous situations, but this is the one that started
>>> the recent discussion.
>>>
>>> Is this a real issue, or have I missed something? Given that there's now
>>> an API for rejecting "m=" sections, it's no longer just a corner case, but
>>> something possible with basic usage of the PeerConnection API. So it seems
>>> worth addressing.
>>>
>>
>>> Some ideas for how to resolve it:
>>>
>>> 1. Require ufrags to be unique for different ICE sessions (JSEP already
>>> requires this), and use the ufrag as the unique identifier. Then the BUNDLE
>>> semantics could be used as-is, with "unique/shared ufrag" replacing
>>> "unique/shared address".
>>>
>>
>> This seems like a good approach.  We're already using ufrag as an ICE
>> session identifier in trickle ICE to handle ICE restart edge cases.   And
>> there might be lots of edge cases around the problem of not being able to
>> identify transports with addresses.
>>
>>
>>> 2. For ICE, instead of using a "shared address" to mean "guaranteed to
>>> use the existing BUNDLE transport", use "a=bundle-only" in subsequent
>>> offers. If we were to do this, we may also need to allow the offerer
>>> BUNDLE-tag section to be rejected; that's currently not supported (
>>> https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>>> 3. Since the "shared address" rules say "don't associate
>>> TRANSPORT/IDENTICAL category attributes with m= sections other than the
>>> offerer BUNDLE-tag section", we could interpret "m= section has no
>>> transport attributes of its own" as "using shared address".
>>>
>>
>> Another option might be to define an "a=ice-id" just like we have an
>> "a=dtls-id".   When using ICE, that can function as the ID instead of the
>> address.  Or we could go with "a=transport-id" and just have an ID for the
>> transport that works for ICE and non-ICE and we could rewrite everything in
>> BUNDLE that relies on addresses for IDs and use the a=transport-id
>> instead.  Would that work?
>>
>>
>
> We're starting to accumulate a lot of IDs in SDP. If we can make ufrag
> work as an identifier for the ICE session in BUNDLE, I think we should do
> so; as you note, we're already using it as such elsewhere.
>
>

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


Yes, I prefer ufrag as the ID, assuming it works.

<=
div class=3D"gmail_quote">
On Wed, Aug 30, 2017 at 2:10 PM =
Justin Uberti <juberti@google.com<=
/a>> wrote:
On Tue, Aug 29, 2017 at =
11:10 PM, Peter Thatcher <pthatcher@google.com> wrote:


On Tue, Aug 29, 2017 at 9:35 AM Taylor Bran=
dstetter <deadb=
eef@google.com> wrote:

And raised as an issue on webrtc-pc's git=
hub page here:=C2=A0https://github.com/w3c/webrtc-pc/issues/1563
<=
div>
The main issue, as I interpret it, is that BUNDLE is wri=
tten with the assumption that a transport can be identified by an address (=
the "BUNDLE address"). An offer has a different meaning depending=
 on whether a "shared address" or "unique address" is u=
sed for the m=3D sections in the BUNDLE group. But for ICE (and specificall=
y trickle ICE), this assumption doesn't hold. The address used by an IC=
E session may change from one offer to the next, and if no candidates have =
been gathered yet, it may just be "0.0.0.0:9". So there's no piece of information tha=
t can be used authoritatively to match an ICE transport in one blob of SDP =
to an ICE transport in another blob.

It does seem like a serious oversight that BUNDLE is written i=
n terms of using addresses as identifiers when such addresses don't exi=
st when doing trickle ICE.=C2=A0 That means (BUNDLE=C2=A0+ trickle ICE) may=
 have lots of things undefined.

It seems like we n=
eed to define an ID for (BUNDLE=C2=A0+ trickle ICE), either by saying in BU=
NDLE "when using trickle ICE, the ID is X" or in trickle ICE by s=
aying "when BUNDLing, the ID is "X.=C2=A0 I think putting in BUND=
LE makes more sense. =C2=A0
=C2=A0
So, current implementations (at least Chrome/Firefox) follow a =
simplified model of "transport follows m=3D section".=C2=A0 Howev=
er, this behavior isn't covered explicitly by the standard, and it has =
its downsides. It means if the m=3D section associated with the current ICE=
 transport is rejected, a new ICE transport needs to be set up (or worse, t=
hings just stop working completely).

Example:

Offer (for already-established BUNDLE group)

a=3Dgroup:BUNDLE audio video
m=3Daudio 9 .=
..
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=
=3Dice-pwd:bar
a=3Dmid:audio
...
m=3Dvideo 9 =
...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
=
a=3Dice-pwd:bar
a=3Dmid:video

Answer<=
/b>

a=3Dgroup:BUNDLE video
m=3Daudio 0 .=
..
c=3DIN IP4 0.0.0.0
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice=
-ufrag:baz
a=3Dice-pwd:buz
a=3Dmid:video

=


Does this mean the existing "audio" ICE=
 session continues to be used, or is a new "video" one created? T=
here's no established way for the offerer to indicate what it desires, =
since there's no way to provide a "unique/shared address" dis=
tinction. Where "unique" means "can fall back to using a dif=
ferent transport," and "shared" means "will use the exi=
sting transport" (assuming I've interpreted BUNDLE correctly; I ma=
y be reading between the lines too much).


So let me see if I understand this...=
=C2=A0 First, it's only for re-offer cases, right?=C2=A0
In t=
hat case, the re-offer would like to say one of the following?
1. =C2=A0(Shared) "We're currently sending contents C=
A and CB over transport TA; let's keep doing that; =C2=A0but if you wan=
t to stop sending CA, let's keep sending CB over TA".
or=C2=A0

2. =C2=A0(Unique) "=
;We're currently sending contents CA and CB over transport TA; let'=
s keep doing that; =C2=A0but if you want to stop sending CA, throw away TA =
and let's make a new TB and send CB over that".


But righ=
t now all the re-offerer can say is "We're currently sending conte=
nts CA and CB over transport TA; let's keep doing that; =C2=A0if you re=
ject CA ... I don't know; please don't do that".


<=
div>
There are other ambiguous situations, but this is the one th=
at started the recent discussion.

Is this a real i=
ssue, or have I missed something? Given that there's now an API for rej=
ecting "m=3D" sections, it's no longer just a corner case, bu=
t something possible with basic usage of the PeerConnection API. So it seem=
s worth addressing.
=


Some ideas for how to resolve it:

1. Require ufrags to be unique for different ICE sessi=
ons (JSEP already requires this), and use the ufrag as the unique identifie=
r. Then the BUNDLE semantics could be used as-is, with "unique/shared =
ufrag" replacing "unique/shared address".

This seems like a good approach.=C2=A0 We&=
#39;re already using ufrag as an ICE session identifier in trickle ICE to h=
andle ICE restart edge cases. =C2=A0 And there might be lots of edge cases =
around the problem of not being able to identify transports with addresses.=
 =C2=A0
=C2=A0
2. For ICE, instead of using a "shared address" to =
mean "guaranteed to use the existing BUNDLE transport", use "=
;a=3Dbundle-only" in subsequent offers. If we were to do this, we may =
also need to allow the offerer BUNDLE-tag section to be rejected; that'=
s currently not supported (https://github.com/cdh4u/draft-sdp-bundle=
/issues/22).
3. Since the "shared address" rules sa=
y "don't associate TRANSPORT/IDENTICAL category attributes with m=
=3D sections other than the offerer BUNDLE-tag section", we could inte=
rpret "m=3D section has no transport attributes of its own" as &q=
uot;using shared address".

Another option might be to define an "a=3Dice-id" just li=
ke we have an "a=3Ddtls-id". =C2=A0 When using ICE, that can func=
tion as the ID instead of the address.=C2=A0 Or we could go with "a=3D=
transport-id" and just have an ID for the transport that works for ICE=
 and non-ICE and we could rewrite everything in BUNDLE that relies on addre=
sses for IDs and use the a=3Dtransport-id instead.=C2=A0 Would that work?
=C2=A0

<=
/div>
We're starting to accumulate a lot of IDs in SDP. If =
we can make ufrag work as an identifier for the ICE session in BUNDLE, I th=
ink we should do so; as you note, we're already using it as such elsewh=
ere.





--001a114a758e409a6f0557ff9003--


From nobody Wed Aug 30 23:29:53 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 EB47113207A for ; Wed, 30 Aug 2017 23:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Level: 
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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, WEIRD_PORT=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 gIbGTulgXZi3 for ; Wed, 30 Aug 2017 23:29:47 -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 C129613218F for ; Wed, 30 Aug 2017 23:29:46 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-1f-59a7acbb4fa0
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.EB.21299.BBCA7A95; Thu, 31 Aug 2017 08:29:15 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 08:29:08 +0200
From: Christer Holmberg 
To: Peter Thatcher , Justin Uberti 
CC: RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKcSi6AgAD7KgCAAAw5gIAAw5EA
Date: Thu, 31 Aug 2017 06:29:07 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_D5CD862A20C1Dchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7k+6NNcsjDXpfillsnSpkcW35a1aL tf/a2R2YPRZsKvVYsuQnUwBTFJdNSmpOZllqkb5dAlfGtpU72QqOLWKs2DfrFmMDY2sHYxcj J4eEgInEnuffWboYuTiEBI4wSpy5f5EdwlnCKPHs9xu2LkYODjYBC4nuf9ogDSICvhJ3Ti9n AbGZBRQlviyfzwZiCws4Shw7MY8dpFxEwEniV0M0RLmbxKoLV9lBbBYBVYn+/gesIDavgLXE kt/zGSFWLWWSaLp1GGwOp0CgxMGp95lBbEYBMYnvp9YwQewSl7j1ZD4TxNECEkv2nGeGsEUl Xj7+xwqyV1RAT+Ldfk8QU0JASWLa1jSIzgSJ1sM7GCHWCkqcnPmEZQKj6CwkQ2chKZuFpAwi biDx/tx8ZghbW2LZwtdQtr7Exi9ngeo5gGxribmripCVLGDkWMUoWpxanJSbbmSsl1qUmVxc nJ+nl5dasokRGIsHt/xW3cF4+Y3jIUYBDkYlHt5Vi5ZHCrEmlhVX5h5ilOBgVhLhtVgFFOJN SaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJanZqakFqEUyWiYNTqoFxgr9au5sO05zi bvsjJ5k3pBm+fz7hnHz5k919Nuv6N4k2fC4Ok/m2u9+i9crhj2de6XnXPrmn/l6j54ai59uj 7EenN7/x31CXIR6jU6j/01PNpNrcoa78mEzFR1E3j4L/m9vYBLWDxR7Z9U9n9Hl7UvT8BDuz 7Ic6x8VimMMq7+3/srTEa6YSS3FGoqEWc1FxIgBHv6kuwQIAAA==
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 06:29:51 -0000

--_000_D5CD862A20C1Dchristerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

Doesn=92t RFC 5245 specify that a ufrag change requires an ICE restart?

Section 9.1.1.1. Says:

   "To restart ICE, an agent MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer."

Now, in my reading it is a little clear whether that text means that a chan=
ge in ufrag triggers an ICE restart, or whether an ICE restart triggered by=
 something else require a change in ufrag.


Section 9.1.2. says:

   "The username fragments, password, and implementation level MUST
   remain the same as used previously.  If an agent needs to change one
   of these, it MUST restart ICE for that media stream."

I think that text implicitly says that a change in ufrag requires an ICE re=
start.

I  guess we could clarify the text in ICEbis, but the requirement already s=
eems to be there. So, an implementation doing an ICE restart WITHOUT changi=
ng the ufrag is not standard compliant =96 at least that=92s my understandi=
ng.

Regards,

Christer


From: rtcweb > on b=
ehalf of "pthatcher@google.com" >
Date: Thursday 31 August 2017 at 00:53
To: Justin Uberti >
Cc: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Yes, I prefer ufrag as the ID, assuming it works.

On Wed, Aug 30, 2017 at 2:10 PM Justin Uberti > wrote:
On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher > wrote:


On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter > wrote:
Spawned from this thread on public-webrtc@w3.org: https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

And raised as an issue on webrtc-pc's github page here: https://github.com/=
w3c/webrtc-pc/issues/1563

The main issue, as I interpret it, is that BUNDLE is written with the assum=
ption that a transport can be identified by an address (the "BUNDLE address=
"). An offer has a different meaning depending on whether a "shared address=
" or "unique address" is used for the m=3D sections in the BUNDLE group. Bu=
t for ICE (and specifically trickle ICE), this assumption doesn't hold. The=
 address used by an ICE session may change from one offer to the next, and =
if no candidates have been gathered yet, it may just be "0.0.0.0:9". So there's no piece of information that can be used authoritati=
vely to match an ICE transport in one blob of SDP to an ICE transport in an=
other blob.

It does seem like a serious oversight that BUNDLE is written in terms of us=
ing addresses as identifiers when such addresses don't exist when doing tri=
ckle ICE.  That means (BUNDLE + trickle ICE) may have lots of things undefi=
ned.

It seems like we need to define an ID for (BUNDLE + trickle ICE), either by=
 saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE b=
y saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes mor=
e sense.


So, current implementations (at least Chrome/Firefox) follow a simplified m=
odel of "transport follows m=3D section".  However, this behavior isn't cov=
ered explicitly by the standard, and it has its downsides. It means if the =
m=3D section associated with the current ICE transport is rejected, a new I=
CE transport needs to be set up (or worse, things just stop working complet=
ely).

Example:

Offer (for already-established BUNDLE group)

a=3Dgroup:BUNDLE audio video
m=3Daudio 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:foo
a=3Dice-pwd:bar
a=3Dmid:video

Answer

a=3Dgroup:BUNDLE video
m=3Daudio 0 ...
c=3DIN IP4 0.0.0.0
a=3Dmid:audio
...
m=3Dvideo 9 ...
c=3DIN IP4 0.0.0.0
a=3Dice-ufrag:baz
a=3Dice-pwd:buz
a=3Dmid:video


Does this mean the existing "audio" ICE session continues to be used, or is=
 a new "video" one created? There's no established way for the offerer to i=
ndicate what it desires, since there's no way to provide a "unique/shared a=
ddress" distinction. Where "unique" means "can fall back to using a differe=
nt transport," and "shared" means "will use the existing transport" (assumi=
ng I've interpreted BUNDLE correctly; I may be reading between the lines to=
o much).


So let me see if I understand this...  First, it's only for re-offer cases,=
 right?
In that case, the re-offer would like to say one of the following?

1.  (Shared) "We're currently sending contents CA and CB over transport TA;=
 let's keep doing that;  but if you want to stop sending CA, let's keep sen=
ding CB over TA".

or

2.  (Unique) "We're currently sending contents CA and CB over transport TA;=
 let's keep doing that;  but if you want to stop sending CA, throw away TA =
and let's make a new TB and send CB over that".


But right now all the re-offerer can say is "We're currently sending conten=
ts CA and CB over transport TA; let's keep doing that;  if you reject CA ..=
. I don't know; please don't do that".


There are other ambiguous situations, but this is the one that started the =
recent discussion.

Is this a real issue, or have I missed something? Given that there's now an=
 API for rejecting "m=3D" sections, it's no longer just a corner case, but =
something possible with basic usage of the PeerConnection API. So it seems =
worth addressing.

Some ideas for how to resolve it:

1. Require ufrags to be unique for different ICE sessions (JSEP already req=
uires this), and use the ufrag as the unique identifier. Then the BUNDLE se=
mantics could be used as-is, with "unique/shared ufrag" replacing "unique/s=
hared address".

This seems like a good approach.  We're already using ufrag as an ICE sessi=
on identifier in trickle ICE to handle ICE restart edge cases.   And there =
might be lots of edge cases around the problem of not being able to identif=
y transports with addresses.

2. For ICE, instead of using a "shared address" to mean "guaranteed to use =
the existing BUNDLE transport", use "a=3Dbundle-only" in subsequent offers.=
 If we were to do this, we may also need to allow the offerer BUNDLE-tag se=
ction to be rejected; that's currently not supported (https://github.com/cd=
h4u/draft-sdp-bundle/issues/22).
3. Since the "shared address" rules say "don't associate TRANSPORT/IDENTICA=
L category attributes with m=3D sections other than the offerer BUNDLE-tag =
section", we could interpret "m=3D section has no transport attributes of i=
ts own" as "using shared address".

Another option might be to define an "a=3Dice-id" just like we have an "a=
=3Ddtls-id".   When using ICE, that can function as the ID instead of the a=
ddress.  Or we could go with "a=3Dtransport-id" and just have an ID for the=
 transport that works for ICE and non-ICE and we could rewrite everything i=
n BUNDLE that relies on addresses for IDs and use the a=3Dtransport-id inst=
ead.  Would that work?


We're starting to accumulate a lot of IDs in SDP. If we can make ufrag work=
 as an identifier for the ICE session in BUNDLE, I think we should do so; a=
s you note, we're already using it as such elsewhere.


--_000_D5CD862A20C1Dchristerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,







Doesn=92t RFC 5245 specify that a ufrag change requires an ICE restart=
?









Section 9.1.1.1. Says:






   "To restart ICE, an agent =
MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer."




Now, in my reading it is a little clear whether that text means that a=
 change in ufrag triggers an ICE restart, or whether an ICE restart trigger=
ed by something else require a change in ufrag.












Section 9.1.2. says:




   "The username fragments, p=
assword, and implementation level MUST
   remain the same as used previously.  If an agent needs to change one
   of these, it MUST restart ICE for that media stream."




I think that text implicitly says that a change in ufrag requires an I=
CE restart. 







I  guess we could clarify the text in ICEbis, but the requirement=
 already seems to be there. So, an implementation doing an ICE restart WITH=
OUT changing the ufrag is not standard compliant =96 at least that=92s my u=
nderstanding.







Regards,







Christer














From: rtcweb <rtcweb-bounces@ietf.org> on behalf of "=
;pthatcher@google.com" <=
;pthatcher@google.com>

Date: Thursday 31 August 2017 at 00=
:53

To: Justin Uberti <juberti@google.com>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [rtcweb] Ambiguities w=
ith BUNDLE when used with ICE?













Yes, I prefer ufrag as the ID, assuming it works.






On Wed, Aug 30, 2017 at 2:10 PM Justin Uberti <juberti@google.com> wrote:










On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher=
 
<pthatcher@goo=
gle.com> wrote:











On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter <deadbeef@google.com<=
/a>> wrote:














And raised as an issue on webrtc-pc's github page here: https:/=
/github.com/w3c/webrtc-pc/issues/1563







The main issue, as I interpret it, is that BUNDLE is written with the =
assumption that a transport can be identified by an address (the "BUND=
LE address"). An offer has a different meaning depending on whether a =
"shared address" or "unique address" is used
 for the m=3D sections in the BUNDLE group. But for ICE (and specifically t=
rickle ICE), this assumption doesn't hold. The address used by an ICE sessi=
on may change from one offer to the next, and if no candidates have been ga=
thered yet, it may just be "0.0.0.0:9".
 So there's no piece of information that can be used authoritatively to mat=
ch an ICE transport in one blob of SDP to an ICE transport in another blob.=













It does seem like a serious oversight that BUNDLE is written in terms =
of using addresses as identifiers when such addresses don't exist when doin=
g trickle ICE.  That means (BUNDLE + trickle ICE) may have lo=
ts of things undefined.







It seems like we need to define an ID for (BUNDLE + trickle I=
CE), either by saying in BUNDLE "when using trickle ICE, the ID is X&q=
uot; or in trickle ICE by saying "when BUNDLing, the ID is "X.&nb=
sp; I think putting in BUNDLE makes more sense.  






 











So, current implementations (at least Chrome/Firefox) follow a simplif=
ied model of "transport follows m=3D section".  However, thi=
s behavior isn't covered explicitly by the standard, and it has its downsid=
es. It means if the m=3D section associated with the
 current ICE transport is rejected, a new ICE transport needs to be set up =
(or worse, things just stop working completely).







Example:







Offer (for already-established BUNDLE group)







a=3Dgroup:BUNDLE audio video


m=3Daudio 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:foo


a=3Dice-pwd:bar


a=3Dmid:audio


...


m=3Dvideo 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:foo


a=3Dice-pwd:bar


a=3Dmid:video







Answer







a=3Dgroup:BUNDLE video


m=3Daudio 0 ...


c=3DIN IP4 0.0.0.0




a=3Dmid:audio


...


m=3Dvideo 9 ...


c=3DIN IP4 0.0.0.0




a=3Dice-ufrag:baz


a=3Dice-pwd:buz


a=3Dmid:video












Does this mean the existing "audio" ICE session continues to=
 be used, or is a new "video" one created? There's no established=
 way for the offerer to indicate what it desires, since there's no way to p=
rovide a "unique/shared address" distinction. Where
 "unique" means "can fall back to using a different transpor=
t," and "shared" means "will use the existing transport=
" (assuming I've interpreted BUNDLE correctly; I may be reading betwee=
n the lines too much).




















So let me see if I understand this...  First, it's only for re-of=
fer cases, right? 


In that case, the re-offer would like to say one of the following?






1.  (Shared) "We're currently sending contents CA and CB ove=
r transport TA; let's keep doing that;  but if you want to stop sendin=
g CA, let's keep sending CB over TA".







or 









2.  (Unique) "We're currently sending contents CA and CB ove=
r transport TA; let's keep doing that;  but if you want to stop sendin=
g CA, throw away TA and let's make a new TB and send CB over that".












But right now all the re-offerer can say is "We're currently sending c=
ontents CA and CB over transport TA; let's keep doing that;  if you re=
ject CA ... I don't know; please don't do that".


















There are other ambiguous situations, but this is the one that started=
 the recent discussion.







Is this a real issue, or have I missed something? Given that there's n=
ow an API for rejecting "m=3D" sections, it's no longer just a co=
rner case, but something possible with basic usage of the PeerConnection AP=
I. So it seems worth addressing.















Some ideas for how to resolve it:







1. Require ufrags to be unique for different ICE sessions (JSEP alread=
y requires this), and use the ufrag as the unique identifier. Then the BUND=
LE semantics could be used as-is, with "unique/shared ufrag" repl=
acing "unique/shared address".












This seems like a good approach.  We're already using ufrag as an=
 ICE session identifier in trickle ICE to handle ICE restart edge cases. &n=
bsp; And there might be lots of edge cases around the problem of not being =
able to identify transports with addresses.
  



 






2. For ICE, instead of using a "shared address" to mean &quo=
t;guaranteed to use the existing BUNDLE transport", use "a=3Dbund=
le-only" in subsequent offers. If we were to do this, we may also need=
 to allow the offerer BUNDLE-tag section to be rejected; that's
 currently not supported (https://github.com/cdh4u/draft-sdp-bundle/=
issues/22).


3. Since the "shared address" rules say "don't associat=
e TRANSPORT/IDENTICAL category attributes with m=3D sections other than the=
 offerer BUNDLE-tag section", we could interpret "m=3D section ha=
s no transport attributes of its own" as "using shared address&qu=
ot;.












Another option might be to define an "a=3Dice-id" just like =
we have an "a=3Ddtls-id".   When using ICE, that can functio=
n as the ID instead of the address.  Or we could go with "a=3Dtra=
nsport-id" and just have an ID for the transport that works for ICE an=
d non-ICE
 and we could rewrite everything in BUNDLE that relies on addresses for IDs=
 and use the a=3Dtransport-id instead.  Would that work?



 

























We're starting to accumulate a lot of IDs in SDP. If we can make ufrag=
 work as an identifier for the ICE session in BUNDLE, I think we should do =
so; as you note, we're already using it as such elsewhere.























--_000_D5CD862A20C1Dchristerholmbergericssoncom_--


From nobody Thu Aug 31 06:03:23 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 6B531132D8B for ; Thu, 31 Aug 2017 06:03:22 -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, 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 SoUGK0v1NOpl for ; Thu, 31 Aug 2017 06:03:15 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1EE94132DF6 for ; Thu, 31 Aug 2017 06:03:11 -0700 (PDT)
X-AuditID: c1b4fb3a-9e1d49c0000051a3-20-59a8090eca0e
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6C.95.20899.E0908A95; Thu, 31 Aug 2017 15:03:10 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 15:03:01 +0200
From: Christer Holmberg 
To: Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gA==
Date: Thu, 31 Aug 2017 13:03:00 +0000
Message-ID: 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>
In-Reply-To: <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <07F200E97CF737459C4B4322583213DD@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7oi4f54pIg+MT+SwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGrp0nWAtmaFRc3LeLtYFx inoXIyeHhICJxM55M5i7GLk4hASOMErc+X2cDcJZwiixZ/s1li5GDg42AQuJ7n/aIA0iAkUS Z45tYQKxhQUcJY6dmMcOUiIi4CTxqyEaoiRMonnORyaQMIuAqsTMmWCdvALWEhvevoJadZlJ 4sjBb6wgCU4Be4mbD44ygtiMAmIS30+tARvPLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFWS+ qICexLv9niCmhICixPJ+OYhOLYkvP/axQdjWEjt2v2aEsBUlpnQ/ZIc4R1Di5MwnLBMYxWYh WTYLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgjB3c8ttqB+PB 546HGAU4GJV4eKN/L48UYk0sK67MPcQowcGsJMJbwrwiUog3JbGyKrUoP76oNCe1+BCjNAeL kjivw74LEUIC6YklqdmpqQWpRTBZJg5OqQbGjBWmSzWyMloi0+3kNZ/Vx73+IhTf256+V9vB 0PHC8fVqIbcjd559FzNvu4FNpFH+eymDe/2VXtL6M6dsmKZ/3W5nzUdT++kXZk45tMvinKyp Wnrh7AhZpj3CEtLavru6Lwtpv/Z/5faqImPZwmuRPaFKHJ4L6tcqrM5iWsg2c9Oii0xCerOU WIozEg21mIuKEwEq4pPprQIAAA==
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 13:03:22 -0000

SGksDQoNCj4+DQo+Pj4gICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0
aGF0IHRoZSB0cmFuc3BvcnQgZm9sbG93cyB0aGUNCj4+PiBidW5kbGUsIHdoYXQgYWJvdXQgdGhp
cz8NCj4+Pg0KPj4+IGE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMg0KPj4+IGE9Z3JvdXA6QlVORExF
IG1pZDMgbWlkNA0KPj4+DQo+Pj4gYW5kIGluIGEgcmVvZmZlcg0KPj4+DQo+Pj4gYT1ncm91cDpC
VU5ETEUgbWlkMiBtaWQzDQo+Pj4gYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQo+Pj4NCj4+PiAg
ICAgIFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/DQo+Pg0KPj4gSSB0aGluayBUYXlsb3IgcmFp
c2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlIGlzDQo+PiBt
b3Zpbmcgc3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5vdGhlciwgYW5kIG1peGlu
ZyB0aGUgQlVORExFDQo+PiBncm91cHMgdXAsIGFuZCBJIGRvbqGvdCB0aGluayB0aGF0oa9zIGEg
Z29vZCBpZGVhLg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4NCj4gICAgIElm
IHlvdSB3YW50IHRvIGNsYXNzaWZ5IHRoaXMgYXMgYSBiYWQgaWRlYSwgd2UgbmVlZCBub3JtYXRp
dmUNCj5sYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5zdGFuY2UsIGEgcnVsZSB0aGF0IG9u
Y2UgYSBtaWQgaXMgcGxhY2VkDQo+aW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUg
aXQgaXMgdG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBhcyBhDQo+cnVsZSB0byBoYW5kbGUgdGhlIGZv
bGxvd2luZzoNCj4NCj5hPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCj5hPW1pZDogbWlkMSA8LS0t
IG5vdCBidW5kbGVkDQo+Li4uDQo+YT1taWQ6IG1pZDINCj4uLi4NCj5hPW1pZDogbWlkMw0KPg0K
PmFuZCBpbiBhIHJlb2ZmZXINCj4NCj5hPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQo+DQo+ICAgICBX
ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEn
cywgb3IgdGhlDQo+YnVuZGxlJ3MuIE9yIHBlcmhhcHMgYSBydWxlIGZvcmJpZGRpbmcgcHJldmlv
dXNseSB1bmJ1bmRsZWQgbWlkcyB0byBiZQ0KPmFkZGVkIHRvIGEgYnVuZGxlLg0KDQpJIHRoaW5r
IHRoaXMgaXMgY292ZXJlZCBpbiBzZWN0aW9uIDguNS4yIChBZGRpbmcgYSBtZWRpYSBkZXNjcmlw
dGlvbiB0byBhDQpCVU5ETEUgZ3JvdXApIG9mIEJVTkRMRS4NCg0KQXNzdW1pbmcgeW91IGFyZSBj
aGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9mIHRoZSBtaWQxIG0tbGluZSwgeW91IGFyZQ0Kc3VnZ2Vz
dGluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXAgKGZpcnN0IGJ1bGxldCBp
biBzZWN0aW9uDQo4LjUuMikuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KPj4+
IE9uIDgvMzAvMTcgNToxOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4+IEhpLA0K
Pj4+Pg0KPj4+PiBNYXliZSBJqfZtIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgSSBmYWlsIHRvIHNl
ZSB3aGF0IHRoZSBwcm9ibGVtIGlzLg0KPj4+Pg0KPj4+PiBJZiB0aGUgQlVORExFLXRhZyBzZWN0
aW9uIGlzIGNoYW5nZWQgKGUuZy4sIGJlY2F1c2UgdGhlIGN1cnJlbnQNCj4+Pj4gQlVORExFLXRh
Zw0KPj4+PiBzZWN0aW9uIG0tIGxpbmUgaXMgcmVqZWN0ZWQpIHlvdSBzaW1wbHkgaW5jbHVkZSB0
aGUNCj4+Pj5UUkFOU1BPUlQvSURFTlRJQ0FMDQo+Pj4+IGNhdGVnb3J5IGF0dHJpYnV0ZXMgaW4g
dGhlIG5ldyBCVU5ETEUtdGFnIHNlY3Rpb24gbS0gbGluZS4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywN
Cj4+Pj4NCj4+Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4g
T24gMjkvMDgvMTcgMTk6NDUsICJydGN3ZWIgb24gYmVoYWxmIG9mIEJ5cm9uIENhbXBlbiINCj4+
Pj4gPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiY2FtcGVuQG1vemlsbGEu
Y29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IE9uIDgvMjkvMTcgMTE6MzUgQU0sIFRheWxvciBCcmFu
ZHN0ZXR0ZXIgd3JvdGU6DQo+Pj4+Pj4gU29tZSBpZGVhcyBmb3IgaG93IHRvIHJlc29sdmUgaXQ6
DQo+Pj4+Pj4NCj4+Pj4+PiAxLiBSZXF1aXJlIHVmcmFncyB0byBiZSB1bmlxdWUgZm9yIGRpZmZl
cmVudCBJQ0Ugc2Vzc2lvbnMgKEpTRVANCj4+Pj4+PiBhbHJlYWR5IHJlcXVpcmVzIHRoaXMpLCBh
bmQgdXNlIHRoZSB1ZnJhZyBhcyB0aGUgdW5pcXVlIGlkZW50aWZpZXIuDQo+Pj4+Pj4gVGhlbiB0
aGUgQlVORExFIHNlbWFudGljcyBjb3VsZCBiZSB1c2VkIGFzLWlzLCB3aXRoICJ1bmlxdWUvc2hh
cmVkDQo+Pj4+Pj4gdWZyYWciIHJlcGxhY2luZyAidW5pcXVlL3NoYXJlZCBhZGRyZXNzIi4NCj4+
Pj4+ICAgICAgIEkgdGhpbmsgdGhpcyBpcyBvdXIgYmVzdCBvcHRpb24uIEl0IHNob3VsZCBhbGxv
dyB0cmlja2xlIElDRSB0bw0KPj4+Pj4gd29yayBhcyB3ZWxsIGFzIGFueXRoaW5nIGVsc2UuIFdl
IG1pZ2h0IHN0aWxsIHdhbnQgdG8gZG8gc29tZSBvZiB0aGUNCj4+Pj4+IGJlbG93IGluIGFkZGl0
aW9uLg0KPj4+Pj4NCj4+Pj4+PiAyLiBGb3IgSUNFLCBpbnN0ZWFkIG9mIHVzaW5nIGEgInNoYXJl
ZCBhZGRyZXNzIiB0byBtZWFuICJndWFyYW50ZWVkDQo+Pj4+Pj50bw0KPj4+Pj4+IHVzZSB0aGUg
ZXhpc3RpbmcgQlVORExFIHRyYW5zcG9ydCIsIHVzZSAiYT1idW5kbGUtb25seSIgaW4NCj4+Pj4+
PnN1YnNlcXVlbnQNCj4+Pj4+PiBvZmZlcnMuIElmIHdlIHdlcmUgdG8gZG8gdGhpcywgd2UgbWF5
IGFsc28gbmVlZCB0byBhbGxvdyB0aGUgb2ZmZXJlcg0KPj4+Pj4+IEJVTkRMRS10YWcgc2VjdGlv
biB0byBiZSByZWplY3RlZDsgdGhhdCdzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkDQo+Pj4+Pj4g
KGh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlL2lzc3Vlcy8yMikuDQo+
Pj4+PiAgICAgICBUaGlzIGRvZXMgbm90IGhlbHAgY2xhcmlmeSB0aGluZ3Mgd2hlbiB0aGUgb2Zm
ZXJlciBjaGFuZ2VzIHRoZQ0KPj4+Pj4gQlVORExFIHRhZyAoZGlzYWJsZSwgcmVtb3ZlIGZyb20g
QlVORExFLCBtYWtlIHNvbWV0aGluZyBlbHNlIHRoZQ0KPj4+Pj4gQlVORExFLXRhZywgZXRjKS4N
Cj4+Pj4+DQo+Pj4+Pj4gMy4gU2luY2UgdGhlICJzaGFyZWQgYWRkcmVzcyIgcnVsZXMgc2F5ICJk
b24ndCBhc3NvY2lhdGUNCj4+Pj4+PiBUUkFOU1BPUlQvSURFTlRJQ0FMIGNhdGVnb3J5IGF0dHJp
YnV0ZXMgd2l0aCBtPSBzZWN0aW9ucyBvdGhlciB0aGFuDQo+Pj4+Pj4gdGhlIG9mZmVyZXIgQlVO
RExFLXRhZyBzZWN0aW9uIiwgd2UgY291bGQgaW50ZXJwcmV0ICJtPSBzZWN0aW9uIGhhcw0KPj4+
Pj4+bm8NCj4+Pj4+PiB0cmFuc3BvcnQgYXR0cmlidXRlcyBvZiBpdHMgb3duIiBhcyAidXNpbmcg
c2hhcmVkIGFkZHJlc3MiLg0KPj4+Pj4gICAgICAgSSBkb24ndCB0aGluayB0aGlzIGhlbHBzIHdo
ZW4gdGhlIG9mZmVyZXIgY2hhbmdlcyB0aGUNCj4+Pj4+QlVORExFLXRhZw0KPj4+Pj4gZWl0aGVy
Lg0KPj4+Pj4NCj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+IEJ5cm9uIENhbXBlbg0KPj4+Pj4N
Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
Pj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4NCj4NCg0K


From nobody Thu Aug 31 06:05:17 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 2B13F132D5B for ; Thu, 31 Aug 2017 06:05:17 -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, 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 TpTSIO52Wns9 for ; Thu, 31 Aug 2017 06:05:15 -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 0FE22132D87 for ; Thu, 31 Aug 2017 06:05:12 -0700 (PDT)
X-AuditID: c1b4fb25-967ff70000005333-e4-59a80987d39f
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.A3.21299.78908A95; Thu, 31 Aug 2017 15:05:11 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 15:05:10 +0200
From: Christer Holmberg 
To: Christer Holmberg , Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gIAAAJuA
Date: Thu, 31 Aug 2017 13:05:10 +0000
Message-ID: 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <421A0E77D7AF0448813726CD1D73F8F9@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7vW4754pIg62XxCwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfG2d9RBcd0K/a+dm9g3KDT xcjJISFgIrHrxXy2LkYuDiGBI4wSt88/ZoZwljBK9B04CJTh4GATsJDo/qcNEhcRWMEoseXi N3aQbmEBR4ljJ+axg9SICDhJ/GqIBgmLCERJbPw9kxXEZhFQldh0aDsLiM0rYC2xvm87E8T8 VmaJdxv2giU4BWwkdl18yghiMwqISXw/tYYJxGYWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scK sldUQE/i3X5PEFNCQEli2tY0iE4tiS8/9rFB2NYSr14dZIewFSWmdD9khzhHUOLkzCcsExjF ZiFZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCMHdzyW3UH 4+U3jocYBTgYlXh43/5eHinEmlhWXJl7iFGCg1lJhFeLY0WkEG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYzcpfHr62b6+MfZqz55MuHL7Uv+B48tT/za VJniat5vksmq+iCKb+/M5JYEz5nHtVc7xuSaXa46cnLloZgjWxNPPfl5SY5rw6GJHlMNOnOS j91wfWx9u7pOuLD04CETH+FWj8cWHg2TuZernGTeZp3weyJz7L6J5aJv/D5fb2b/3KVh5H62 9bcSS3FGoqEWc1FxIgDHCUSJrQIAAA==
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 13:05:17 -0000

QXNzdW1pbmcgeW91IGFyZSBOT1QgY2hhbmdpbmcgdGhlIHRyYW5zcG9ydCBvZiB0aGUgbWlkMSBt
LSBsaW5lLCB0aGF0IGlzLg0KDQpPbiAzMS8wOC8xNyAxNjowMywgInJ0Y3dlYiBvbiBiZWhhbGYg
b2YgQ2hyaXN0ZXIgSG9sbWJlcmciDQo8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm
IG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+SGksDQo+DQo+
Pj4NCj4+Pj4gICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0aGF0IHRo
ZSB0cmFuc3BvcnQgZm9sbG93cw0KPj4+PnRoZQ0KPj4+PiBidW5kbGUsIHdoYXQgYWJvdXQgdGhp
cz8NCj4+Pj4NCj4+Pj4gYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyDQo+Pj4+IGE9Z3JvdXA6QlVO
RExFIG1pZDMgbWlkNA0KPj4+Pg0KPj4+PiBhbmQgaW4gYSByZW9mZmVyDQo+Pj4+DQo+Pj4+IGE9
Z3JvdXA6QlVORExFIG1pZDIgbWlkMw0KPj4+PiBhPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDENCj4+
Pj4NCj4+Pj4gICAgICBXaGF0IHRyYW5zcG9ydCBnb2VzIHdoZXJlPw0KPj4+DQo+Pj4gSSB0aGlu
ayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFi
b3ZlIGlzDQo+Pj4gbW92aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRvIGFub3Ro
ZXIsIGFuZCBtaXhpbmcgdGhlIEJVTkRMRQ0KPj4+IGdyb3VwcyB1cCwgYW5kIEkgZG9uoa90IHRo
aW5rIHRoYXShr3MgYSBnb29kIGlkZWEuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hy
aXN0ZXINCj4+DQo+PiAgICAgSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkgdGhpcyBhcyBhIGJhZCBp
ZGVhLCB3ZSBuZWVkIG5vcm1hdGl2ZQ0KPj5sYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5z
dGFuY2UsIGEgcnVsZSB0aGF0IG9uY2UgYSBtaWQgaXMgcGxhY2VkDQo+PmluIGEgYnVuZGxlLCB0
aGUgb25seSB3YXkgdG8gcmVtb3ZlIGl0IGlzIHRvIGRpc2FibGUgaXQsIGFzIHdlbGwgYXMgYQ0K
Pj5ydWxlIHRvIGhhbmRsZSB0aGUgZm9sbG93aW5nOg0KPj4NCj4+YT1ncm91cDpCVU5ETEUgbWlk
MiBtaWQzDQo+PmE9bWlkOiBtaWQxIDwtLS0gbm90IGJ1bmRsZWQNCj4+Li4uDQo+PmE9bWlkOiBt
aWQyDQo+Pi4uLg0KPj5hPW1pZDogbWlkMw0KPj4NCj4+YW5kIGluIGEgcmVvZmZlcg0KPj4NCj4+
YT1ncm91cCBtaWQxIG1pZDIgbWlkMw0KPj4NCj4+ICAgICBXZSB3b3VsZCBuZWVkIHRvIGRlZmlu
ZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEncywgb3IgdGhlDQo+PmJ1bmRsZSdz
LiBPciBwZXJoYXBzIGEgcnVsZSBmb3JiaWRkaW5nIHByZXZpb3VzbHkgdW5idW5kbGVkIG1pZHMg
dG8gYmUNCj4+YWRkZWQgdG8gYSBidW5kbGUuDQo+DQo+SSB0aGluayB0aGlzIGlzIGNvdmVyZWQg
aW4gc2VjdGlvbiA4LjUuMiAoQWRkaW5nIGEgbWVkaWEgZGVzY3JpcHRpb24gdG8gYQ0KPkJVTkRM
RSBncm91cCkgb2YgQlVORExFLg0KPg0KPkFzc3VtaW5nIHlvdSBhcmUgY2hhbmdpbmcgdGhlIHRy
YW5zcG9ydCBvZiB0aGUgbWlkMSBtLWxpbmUsIHlvdSBhcmUNCj5zdWdnZXN0aW5nIGEgbmV3IHRy
YW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluIHNlY3Rpb24NCj44
LjUuMikuDQo+DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPg0KPj4+PiBP
biA4LzMwLzE3IDU6MTggQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+Pj4gSGksDQo+
Pj4+Pg0KPj4+Pj4gTWF5YmUgSan2bSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEkgZmFpbCB0byBz
ZWUgd2hhdCB0aGUgcHJvYmxlbSBpcy4NCj4+Pj4+DQo+Pj4+PiBJZiB0aGUgQlVORExFLXRhZyBz
ZWN0aW9uIGlzIGNoYW5nZWQgKGUuZy4sIGJlY2F1c2UgdGhlIGN1cnJlbnQNCj4+Pj4+IEJVTkRM
RS10YWcNCj4+Pj4+IHNlY3Rpb24gbS0gbGluZSBpcyByZWplY3RlZCkgeW91IHNpbXBseSBpbmNs
dWRlIHRoZQ0KPj4+Pj5UUkFOU1BPUlQvSURFTlRJQ0FMDQo+Pj4+PiBjYXRlZ29yeSBhdHRyaWJ1
dGVzIGluIHRoZSBuZXcgQlVORExFLXRhZyBzZWN0aW9uIG0tIGxpbmUuDQo+Pj4+Pg0KPj4+Pj4g
UmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+
Pj4NCj4+Pj4+DQo+Pj4+PiBPbiAyOS8wOC8xNyAxOTo0NSwgInJ0Y3dlYiBvbiBiZWhhbGYgb2Yg
Qnlyb24gQ2FtcGVuIg0KPj4+Pj4gPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv
ZiBiY2FtcGVuQG1vemlsbGEuY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gT24gOC8yOS8xNyAx
MTozNSBBTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToNCj4+Pj4+Pj4gU29tZSBpZGVhcyBm
b3IgaG93IHRvIHJlc29sdmUgaXQ6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IDEuIFJlcXVpcmUgdWZyYWdz
IHRvIGJlIHVuaXF1ZSBmb3IgZGlmZmVyZW50IElDRSBzZXNzaW9ucyAoSlNFUA0KPj4+Pj4+PiBh
bHJlYWR5IHJlcXVpcmVzIHRoaXMpLCBhbmQgdXNlIHRoZSB1ZnJhZyBhcyB0aGUgdW5pcXVlIGlk
ZW50aWZpZXIuDQo+Pj4+Pj4+IFRoZW4gdGhlIEJVTkRMRSBzZW1hbnRpY3MgY291bGQgYmUgdXNl
ZCBhcy1pcywgd2l0aCAidW5pcXVlL3NoYXJlZA0KPj4+Pj4+PiB1ZnJhZyIgcmVwbGFjaW5nICJ1
bmlxdWUvc2hhcmVkIGFkZHJlc3MiLg0KPj4+Pj4+ICAgICAgIEkgdGhpbmsgdGhpcyBpcyBvdXIg
YmVzdCBvcHRpb24uIEl0IHNob3VsZCBhbGxvdyB0cmlja2xlIElDRQ0KPj4+Pj4+dG8NCj4+Pj4+
PiB3b3JrIGFzIHdlbGwgYXMgYW55dGhpbmcgZWxzZS4gV2UgbWlnaHQgc3RpbGwgd2FudCB0byBk
byBzb21lIG9mIHRoZQ0KPj4+Pj4+IGJlbG93IGluIGFkZGl0aW9uLg0KPj4+Pj4+DQo+Pj4+Pj4+
IDIuIEZvciBJQ0UsIGluc3RlYWQgb2YgdXNpbmcgYSAic2hhcmVkIGFkZHJlc3MiIHRvIG1lYW4g
Imd1YXJhbnRlZWQNCj4+Pj4+Pj50bw0KPj4+Pj4+PiB1c2UgdGhlIGV4aXN0aW5nIEJVTkRMRSB0
cmFuc3BvcnQiLCB1c2UgImE9YnVuZGxlLW9ubHkiIGluDQo+Pj4+Pj4+c3Vic2VxdWVudA0KPj4+
Pj4+PiBvZmZlcnMuIElmIHdlIHdlcmUgdG8gZG8gdGhpcywgd2UgbWF5IGFsc28gbmVlZCB0byBh
bGxvdyB0aGUNCj4+Pj4+Pj5vZmZlcmVyDQo+Pj4+Pj4+IEJVTkRMRS10YWcgc2VjdGlvbiB0byBi
ZSByZWplY3RlZDsgdGhhdCdzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkDQo+Pj4+Pj4+IChodHRw
czovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9pc3N1ZXMvMjIpLg0KPj4+Pj4+
ICAgICAgIFRoaXMgZG9lcyBub3QgaGVscCBjbGFyaWZ5IHRoaW5ncyB3aGVuIHRoZSBvZmZlcmVy
IGNoYW5nZXMgdGhlDQo+Pj4+Pj4gQlVORExFIHRhZyAoZGlzYWJsZSwgcmVtb3ZlIGZyb20gQlVO
RExFLCBtYWtlIHNvbWV0aGluZyBlbHNlIHRoZQ0KPj4+Pj4+IEJVTkRMRS10YWcsIGV0YykuDQo+
Pj4+Pj4NCj4+Pj4+Pj4gMy4gU2luY2UgdGhlICJzaGFyZWQgYWRkcmVzcyIgcnVsZXMgc2F5ICJk
b24ndCBhc3NvY2lhdGUNCj4+Pj4+Pj4gVFJBTlNQT1JUL0lERU5USUNBTCBjYXRlZ29yeSBhdHRy
aWJ1dGVzIHdpdGggbT0gc2VjdGlvbnMgb3RoZXIgdGhhbg0KPj4+Pj4+PiB0aGUgb2ZmZXJlciBC
VU5ETEUtdGFnIHNlY3Rpb24iLCB3ZSBjb3VsZCBpbnRlcnByZXQgIm09IHNlY3Rpb24gaGFzDQo+
Pj4+Pj4+bm8NCj4+Pj4+Pj4gdHJhbnNwb3J0IGF0dHJpYnV0ZXMgb2YgaXRzIG93biIgYXMgInVz
aW5nIHNoYXJlZCBhZGRyZXNzIi4NCj4+Pj4+PiAgICAgICBJIGRvbid0IHRoaW5rIHRoaXMgaGVs
cHMgd2hlbiB0aGUgb2ZmZXJlciBjaGFuZ2VzIHRoZQ0KPj4+Pj4+QlVORExFLXRhZw0KPj4+Pj4+
IGVpdGhlci4NCj4+Pj4+Pg0KPj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+PiBCeXJvbiBDYW1w
ZW4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+Pj4+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHJ0Y3dlYkBpZXRm
Lm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi
DQo+Pj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlzdA0KPnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg==


From nobody Thu Aug 31 06:24:13 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 D507A132DF4 for ; Thu, 31 Aug 2017 06:23:58 -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=mozilla.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 6-lrZ3u7LF_L for ; Thu, 31 Aug 2017 06:23:55 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 22F96132D8F for ; Thu, 31 Aug 2017 06:23:53 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id r203so5361597oih.0 for ; Thu, 31 Aug 2017 06:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wheQFQ5kSPWF6NgZFGC5m6ffsFhWZUiUIpUT2Jykm/A=; b=btFmDSGQ3uuD9r7/A6AdJq3QW9+Ofs2LOuKWYP4Q7WiBQY1m55Df1tmEaB1qB9lnyM IDvUfs6g9VAsAU/q46eojyjenXJpQ5lKvUoJAe2NtCA8maev3gN1EWXeoES3KlL5jDCs d6hOdcHvJDhshWokP/PLLVqCQj1ha1W+jYF0c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wheQFQ5kSPWF6NgZFGC5m6ffsFhWZUiUIpUT2Jykm/A=; b=YqIele75O8VrQ2jcN+eyCJXJgoDK/6FydPFtn/wvHBqVUPSlB9R6Owy7LbXGJAKB5p 81mm7afuQpygvTn/2elM+4nEXfMRtX3IJCxkxmWvhmuaD3kYb8Rrt+WdXPpFJ/rcjKMH iDhh31lxYMzl2lgB5M/1OlSj5Z5Xul4mDn3cpVV/DBg4gYlgyT/Shh0sTImB3dJb5+t4 hVqnTWldn1VHQPNJ7IWou9vRYZaiTVcW5fBaXfmgXBCYFHnBf5goctRckjoQ4s2+i56L FNPbW8S3TCnb3CUh+F3tcPOH+cav8N2+GNKUYIExSP0qamLfkxLvQ9cteS9PHnlKqEh4 8tyg==
X-Gm-Message-State: AHPjjUjdsA9GnqHMTrp06CF/ffPOLA+y36xneIxLjXZ9LyRKhypQ1beF m1FVxKhgwXc6oFPCKDkUgQ==
X-Google-Smtp-Source: ADKCNb4qbodmyftpVuehYhEnoHUCFrOFAGDbXlRJ8SAj1vrRo7LkAZPxpr92+Y5li7+BXPbDDmQdXw==
X-Received: by 10.202.104.132 with SMTP id o4mr2349219oik.183.1504185832018; Thu, 31 Aug 2017 06:23:52 -0700 (PDT)
Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id g12sm8146027oib.6.2017.08.31.06.23.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 06:23:51 -0700 (PDT)
To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> 
From: Byron Campen 
Message-ID: <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com>
Date: Thu, 31 Aug 2017 08:23:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 13:23:59 -0000

On 8/31/17 8:03 AM, Christer Holmberg wrote:
> Hi,
>
>>>>       Alright, if we want to write a rule that the transport follows the
>>>> bundle, what about this?
>>>>
>>>> a=group:BUNDLE mid1 mid2
>>>> a=group:BUNDLE mid3 mid4
>>>>
>>>> and in a reoffer
>>>>
>>>> a=group:BUNDLE mid2 mid3
>>>> a=group:BUNDLE mid4 mid1
>>>>
>>>>       What transport goes where?
>>> I think Taylor raised this issue earlier. What you are doing above is
>>> moving streams from one BUNDLE group to another, and mixing the BUNDLE
>>> groups up, and I don’t think that’s a good idea.
>>>
>>> Regards,
>>>
>>> Christer
>>      If you want to classify this as a bad idea, we need normative
>> language forbidding it. For instance, a rule that once a mid is placed
>> in a bundle, the only way to remove it is to disable it, as well as a
>> rule to handle the following:
>>
>> a=group:BUNDLE mid2 mid3
>> a=mid: mid1 <--- not bundled
>> ...
>> a=mid: mid2
>> ...
>> a=mid: mid3
>>
>> and in a reoffer
>>
>> a=group mid1 mid2 mid3
>>
>>      We would need to define which transport is retained; mid1's, or the
>> bundle's. Or perhaps a rule forbidding previously unbundled mids to be
>> added to a bundle.
> I think this is covered in section 8.5.2 (Adding a media description to a
> BUNDLE group) of BUNDLE.
>
> Assuming you are changing the transport of the mid1 m-line, you are
> suggesting a new transport for the BUNDLE group (first bullet in section
> 8.5.2).

     Right, the offerer has the choice of retaining mid1's transport, or 
keeping the old bundle transport, according to 8.5.2. If we don't do 
something like adding ufrag to the transport comparison rules, 8.5.2 
would have to be tightened significantly. Again, our two choices here:

1. Find a way to allow an ICE offerer to indicate what transports it is 
retaining (eg; ufrag).

or

2. Tighten the rules so that there is no ambiguity in the first place.

     The point I'm trying to make is option 2 would entail lots of 
changes to the spec, and it might be tricky to cover all of the 
corner-cases. I think option 1 is more viable.

Best regards,
Byron Campen


From nobody Thu Aug 31 06:35:18 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 9BE57132DF0 for ; Thu, 31 Aug 2017 06:35:17 -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 WFtacXleUb9M for ; Thu, 31 Aug 2017 06:35:15 -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 D0A33132DF9 for ; Thu, 31 Aug 2017 06:35:08 -0700 (PDT)
X-AuditID: c1b4fb30-96f7a9c000005897-29-59a8108ab3d9
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 37.8A.22679.A8018A95; Thu, 31 Aug 2017 15:35:07 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 15:34:23 +0200
From: Christer Holmberg 
To: Byron Campen , Taylor Brandstetter , RTCWeb IETF 
Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE?
Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqIA=
Date: Thu, 31 Aug 2017 13:34:22 +0000
Message-ID: 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>  <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com>
In-Reply-To: <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <346603C89D5EE3499E84535C698D27D9@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7pW63wIpIg7UL2C0W3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGtpmXmQrWi1fMWevRwLhO qIuRk0NCwETi1bEdzF2MXBxCAkcYJR7/PsIE4SxhlJh/9AdLFyMHB5uAhUT3P22QBhGBIokz x7YwgdjCAo4Sx07MYwcpERFwkvjVEA1RkiSxY+0KNhCbRUBV4srHBnYQm1fAWuJi72xWiPG7 mCXW9G4CS3AK2EssfvUdzGYUEJP4fmoN2HxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sIHtF BfQk3u33BDElBJQkpm1Ng+jUk7gxdQobhG0tMWn7RHYIW1ti2cLXzBDnCEqcnPmEZQKj2Cwk y2YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMsYNbfhvsYHz5 3PEQowAHoxIP77FfyyOFWBPLiitzDzFKcDArifA+4FkRKcSbklhZlVqUH19UmpNafIhRmoNF SZzXcd+FCCGB9MSS1OzU1ILUIpgsEwenVAOjcQwnz8JJvrWh/7+f4gz9mXBfprCBkbulPmIi e1JpkGOG4hGpZzzxV7Y43L4w8SPrw4MJTTvOTD7AJDdpWZO9UO3nwp6V6xP4vjTcv1fBeXGP aLbQFunwGStnL7sWJhQ3eyvHbUGW44aVlXHVJw13hYppLry85NcxDg33gMfONzqvZPCkGZkr sRRnJBpqMRcVJwIA5McHVa0CAAA=
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 13:35:17 -0000

Hi,


>>>>>       Alright, if we want to write a rule that the transport follows
>>>>>the
>>>>> bundle, what about this?
>>>>>
>>>>> a=3Dgroup:BUNDLE mid1 mid2
>>>>> a=3Dgroup:BUNDLE mid3 mid4
>>>>>
>>>>> and in a reoffer
>>>>>
>>>>> a=3Dgroup:BUNDLE mid2 mid3
>>>>> a=3Dgroup:BUNDLE mid4 mid1
>>>>>
>>>>>       What transport goes where?
>>>> I think Taylor raised this issue earlier. What you are doing above is
>>>> moving streams from one BUNDLE group to another, and mixing the BUNDLE
>>>> groups up, and I don=B9t think that=B9s a good idea.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>      If you want to classify this as a bad idea, we need normative
>>> language forbidding it. For instance, a rule that once a mid is placed
>>> in a bundle, the only way to remove it is to disable it, as well as a
>>> rule to handle the following:
>>>
>>> a=3Dgroup:BUNDLE mid2 mid3
>>> a=3Dmid: mid1 <--- not bundled
>>> ...
>>> a=3Dmid: mid2
>>> ...
>>> a=3Dmid: mid3
>>>
>>> and in a reoffer
>>>
>>> a=3Dgroup mid1 mid2 mid3
>>>
>>>      We would need to define which transport is retained; mid1's, or
>>>the
>>> bundle's. Or perhaps a rule forbidding previously unbundled mids to be
>>> added to a bundle.
>> I think this is covered in section 8.5.2 (Adding a media description to
>>a
>> BUNDLE group) of BUNDLE.
>>
>> Assuming you are not changing the transport of the mid1 m-line, you are
>> suggesting a new transport for the BUNDLE group (first bullet in section
>> 8.5.2).
>
>     Right, the offerer has the choice of retaining mid1's transport, or
>keeping the old bundle transport, according to 8.5.2. If we don't do
>something like adding ufrag to the transport comparison rules, 8.5.2
>would have to be tightened significantly. Again, our two choices here:
>
>1. Find a way to allow an ICE offerer to indicate what transports it is
>retaining (eg; ufrag).

You do that using the a=3Dgroup attribute.

a=3Dgroup:BUNDLE mid1 mid2 mid3 means that you want to use the transport of
mid1 (read: you are suggesting a new transport for the BUNDLE group)

a=3Dgroup:BUNELE mid2 mid3 mie1 means that you want to use the transport of
mid2 (read: keep the existing BUNDLE group transport).

Now, if you IN ADDITION to that wants to indicate something ICE specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don=B9t think that is BUNDLE specific, is it?

>or
>
>2. Tighten the rules so that there is no ambiguity in the first place.
>
>     The point I'm trying to make is option 2 would entail lots of
>changes to the spec, and it might be tricky to cover all of the
>corner-cases. I think option 1 is more viable.

I think what we should do is to forbid some of the ambiguous use-cases you
presented earlier (and can also be found in Taylor=B9s GitHub issue). I
think those are mostly related to =B3mixing=B2 mids between different BUNDL=
E
groups.

Regards,

Christer


From nobody Thu Aug 31 08:58:21 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 CA2C013236D for ; Thu, 31 Aug 2017 08:58:19 -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=mozilla.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 E-KIYP1aaoZH for ; Thu, 31 Aug 2017 08:58:17 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 2B50213219E for ; Thu, 31 Aug 2017 08:58:17 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id k77so417841oib.2 for ; Thu, 31 Aug 2017 08:58:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=bA6ch3F0IEUrL2hzri6LLvKAwOmLgw2JupUO5cYw1og=; b=D37hqPad7Pqdr7R38lM4EaRxwGfyhua3HWN3TWexBuANyamUTzuqdbLerT4E0XOSG6 nzxUyA58/ZLKl3jxIOy4sI8b9CSllUaIDXbAOW0yKlM/ctvvzltLWH09rrSsqgfuQzF2 5ZQeqvVvcHZIWlOEYL36rAyTMfatEQuQNSqg8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bA6ch3F0IEUrL2hzri6LLvKAwOmLgw2JupUO5cYw1og=; b=DC21N28ePlTrpSRpXuTa83WXDigGiCTyZHpnBwjvMRApun4f0zUYvT36RVHuLn8PEG 0unRGFFsRy4OrQ2ctBhRzfEP3jzDu3osiKxt9xaKZth8QIBC0cbzcgVa/nvXu2AnXFc5 OucnHqJgRva6tay+bMK30gVKv3lv3fXL4cjeZMplvfHzTkzZpd2qoBDsCgFD/uisdaE8 Xl+50ns2YiNBXRSAb7cm0t8RX1wBfRHpN7MqvfFeqXz3aWdCnhxyG1l2dSHMRvOWa7tZ Wkwt7jDdJOecONKt+lUMB4T7C6oEEnD7R6VxfZrZNsimzAdwtEwuqUPh9BxRIpa4uJdS vO4g==
X-Gm-Message-State: AHYfb5gDIZaGhT7nm0eRQrAodiTfZvgyVY0gM0OKbg/MJKCE4d/7yYsq Ov4zFVO6S00kz3oLSeBGqw==
X-Google-Smtp-Source: ADKCNb6bceBxtdfAOBCkYZAagvVkjxQWkuKk5RRnpHkPk++7IuSBp1W1Dxuw53WHv0qJvek6o++54Q==
X-Received: by 10.202.245.129 with SMTP id t123mr5363196oih.80.1504195095991;  Thu, 31 Aug 2017 08:58:15 -0700 (PDT)
Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id v127sm79178oie.16.2017.08.31.08.58.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 08:58:15 -0700 (PDT)
To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF 
References:  <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com>  <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com>  <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com>  <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> 
From: Byron Campen 
Message-ID: 
Date: Thu, 31 Aug 2017 10:58:06 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?
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, 31 Aug 2017 15:58:20 -0000

On 8/31/17 8:34 AM, Christer Holmberg wrote:
> Hi,
>
>
>>>>>>        Alright, if we want to write a rule that the transport follows
>>>>>> the
>>>>>> bundle, what about this?
>>>>>>
>>>>>> a=group:BUNDLE mid1 mid2
>>>>>> a=group:BUNDLE mid3 mid4
>>>>>>
>>>>>> and in a reoffer
>>>>>>
>>>>>> a=group:BUNDLE mid2 mid3
>>>>>> a=group:BUNDLE mid4 mid1
>>>>>>
>>>>>>        What transport goes where?
>>>>> I think Taylor raised this issue earlier. What you are doing above is
>>>>> moving streams from one BUNDLE group to another, and mixing the BUNDLE
>>>>> groups up, and I don¹t think that¹s a good idea.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>       If you want to classify this as a bad idea, we need normative
>>>> language forbidding it. For instance, a rule that once a mid is placed
>>>> in a bundle, the only way to remove it is to disable it, as well as a
>>>> rule to handle the following:
>>>>
>>>> a=group:BUNDLE mid2 mid3
>>>> a=mid: mid1 <--- not bundled
>>>> ...
>>>> a=mid: mid2
>>>> ...
>>>> a=mid: mid3
>>>>
>>>> and in a reoffer
>>>>
>>>> a=group mid1 mid2 mid3
>>>>
>>>>       We would need to define which transport is retained; mid1's, or
>>>> the
>>>> bundle's. Or perhaps a rule forbidding previously unbundled mids to be
>>>> added to a bundle.
>>> I think this is covered in section 8.5.2 (Adding a media description to
>>> a
>>> BUNDLE group) of BUNDLE.
>>>
>>> Assuming you are not changing the transport of the mid1 m-line, you are
>>> suggesting a new transport for the BUNDLE group (first bullet in section
>>> 8.5.2).
>>      Right, the offerer has the choice of retaining mid1's transport, or
>> keeping the old bundle transport, according to 8.5.2. If we don't do
>> something like adding ufrag to the transport comparison rules, 8.5.2
>> would have to be tightened significantly. Again, our two choices here:
>>
>> 1. Find a way to allow an ICE offerer to indicate what transports it is
>> retaining (eg; ufrag).
> You do that using the a=group attribute.
>
> a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport of
> mid1 (read: you are suggesting a new transport for the BUNDLE group)
>
> a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport of
> mid2 (read: keep the existing BUNDLE group transport).
>
> Now, if you IN ADDITION to that wants to indicate something ICE specific,
> e.g, whether to do an ICE restart, I guess you could use ufrag for that.
> But, I don¹t think that is BUNDLE specific, is it?

     Ok, so what you are describing is "transport follows m-section". 
But the bundle spec doesn't _quite_ guarantee this right now, and it 
probably shouldn't try to guarantee it either. For instance, 8.5.1 
describes how the offerer can suggest a new transport for the bundle, 
any time it wants (and it could potentially be a pre-existing transport 
"stolen" from some other bundle/m-section!); without taking something 
like ufrag into account, this is impossible to detect in the ICE case. 
However, you would be completely right in saying "Well, duh, that is 
true for non-BUNDLE also!", which is why I like the idea of fixing this 
with ufrag, since that's how we make this work in the non-BUNDLE case.

Best regards,
Byron Campen