From nobody Mon Oct 1 13:28:16 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884BF130E0A for ; Mon, 1 Oct 2018 13:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 kZRXbGhkZ8S0 for ; Mon, 1 Oct 2018 13:28:04 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 8658C1252B7 for ; Mon, 1 Oct 2018 13:28:04 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id i76-v6so173281ita.3 for ; Mon, 01 Oct 2018 13:28:04 -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=a12CoQJJgwlBES8h6U10wourkTosGA/q2YOqfyKmOC8=; b=o1HpctyDkRVuWXNt0SdK96+urJfALR45mVsHMYHX92Y8huY2vhL9MYAPRhheWzSCyI 16mEjmqsmr2y9dWzjoMjp9eJnxUGKPPvJx5e9FLjSHUWicVKlqeRARiwFV135yXj4HDh xURxDJq7bUGYRJdjCLHkIK5Kp+fghrwIgvmh8FfR0D8G9r8Dj+wnPXBluA2DV+sEI+FD HSUZAXQP7nQuX0Q6QvMqpga/5VRf9lvdEbQeg4kljH8qxsZ29lpCJGuJnlY99FWM3MGr V7NWj/oZTspthvNe/LRCdYWUoUdULkSPD0NTZRoS1IyjY5urTfvvgA0esHQNgvaw73M9 oJfw== 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=a12CoQJJgwlBES8h6U10wourkTosGA/q2YOqfyKmOC8=; b=pnVsW9h9asf06MUveis1v4Cy46m0RzaKNXNCyD4cMkuGN8pDWtgCAz5AOFeoCfgpsw uMzXli92fZzX0fqS7MQCYkFss0xfiRPmriPCiCPw1Eg/mpv60KWWfq4dBduxOParZrac o3h1kXLxN4vBz0kr2T9YMf/s7phM44/2eu/lHp/U8gfQm6jQY9WK3gcQN4UOT9x/hwud TxNQ/xKF1J9hnWpfdXIyOpDysjOP/rD43X3WGUNuud5TJos3y1+8Ts86NgU5r3cQ0V/6 HvUbpTp0Ckr72ou0+BiU4A29OhtwGqyqxyr/5jNrCdrvDg14NC+ppq9XZ9TmvlDWwine RaxA== X-Gm-Message-State: ABuFfogC3HAWmK3w81XAhXote6TCm9Mwj/D0z3CTJXkD0vLFKmMlogsr hjQjdUyqfr7N3MOlTkm1IjnPUBTOIvEZ3Mj4UD+wc3U7TQA= X-Google-Smtp-Source: ACcGV61tZ1EgFuh/Xch5KiOSloGikFrz6e8EeOHXGNpCYJp4F8ziJgd/Azx2CajRenX3oLwWsh3iuHcZ7Wf+OYfDN3Q= X-Received: by 2002:a24:d1c5:: with SMTP id w188-v6mr10488896itg.99.1538425683533; Mon, 01 Oct 2018 13:28:03 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: From: Justin Uberti Date: Mon, 1 Oct 2018 13:27:50 -0700 Message-ID: To: Adam Roach Cc: Peter Thatcher , RTCWeb IETF , Cullen Jennings , Christer Holmberg , "Heather Flanagan (RFC Series Editor)" , ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000061e47e057730a41d" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 01 Oct 2018 20:28:08 -0000 --00000000000061e47e057730a41d Content-Type: text/plain; charset="UTF-8" [dropping some DLs] I think this is probably a day of work, but will probably take 2 weeks to author and get approval for. If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples. https://github.com/rtcweb-wg/jsep/pull/849 https://github.com/rtcweb-wg/jsep/pull/850 On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti wrote: > I think this is probably a day of work, but will probably take 2 weeks to > author and get approval for. > > If we go down this path, I would also suggest taking the two pending PRs > in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > On Mon, Oct 1, 2018 at 12:17 PM Adam Roach wrote: > >> On 9/27/18 6:20 PM, Justin Uberti wrote: >> > I agree with Peter. Chrome's implementation is already closer to 8445 >> > than 5245, so I don't see any issues associated with snapping this >> > cluster to 8445 (aside from the work involved). >> > >> > On that topic, note that JSEP will need a few more changes than just >> > the addition of the 8445 reference and note; the examples will have to >> > be updated, as will the logic regarding generation of offers and >> > answers and their parsing (to deal with the new ice-option). These >> > changes will be modest but probably will need to be done by the authors. >> >> >> If I read what you're saying correctly, it sounds like you're talking >> about changes that are significant enough that we'll have to put JSEP >> through IETF last call and through the IESG again. That being the case, >> and the rest of the cluster being so close to done, I'd really prefer to >> see this done very soon, if such changes are required. When do you >> believe such an update could be available? >> >> I've copied the RFC Series Editor on this note for her awareness. >> >> /a >> >> --00000000000061e47e057730a41d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[dropping some DLs]

I think this = is probably a day of work, but will probably take 2 weeks to author and get= approval for.

If we go down this path, I would also sug= gest taking the two pending PRs in JSEP, which will also impact the example= s.
http= s://github.com/rtcweb-wg/jsep/pull/850
<= br class=3D"gmail-Apple-interchange-newline">

On Mon, Oct 1, 2018 at 1:23 PM Justin U= berti <juberti@google.com> = wrote:
I think this is probably a day of w= ork, but will probably take 2 weeks to author and get approval for.
If we go down this path, I would also suggest taking the two pe= nding PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <= adam@nostrum.com&= gt; wrote:
On 9/27/18 6:20 PM, Just= in Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

--00000000000061e47e057730a41d-- From nobody Mon Oct 1 14:11:19 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD99130E92; Mon, 1 Oct 2018 12:17:42 -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=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 sSpEDjv9_5CL; Mon, 1 Oct 2018 12:17:41 -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 30841130DE8; Mon, 1 Oct 2018 12:17:41 -0700 (PDT) Received: from Svantevit.roach.at (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 w91JHUjh039495 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Oct 2018 14:17: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 Svantevit.roach.at To: Justin Uberti , pthatcher=40google.com@dmarc.ietf.org Cc: mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg , "Heather Flanagan (RFC Series Editor)" References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> From: Adam Roach Message-ID: <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> Date: Mon, 1 Oct 2018 14:17:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.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: X-Mailman-Approved-At: Mon, 01 Oct 2018 14:11:18 -0700 Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 01 Oct 2018 19:17:43 -0000 On 9/27/18 6:20 PM, Justin Uberti wrote: > I agree with Peter. Chrome's implementation is already closer to 8445 > than 5245, so I don't see any issues associated with snapping this > cluster to 8445 (aside from the work involved). > > On that topic, note that JSEP will need a few more changes than just > the addition of the 8445 reference and note; the examples will have to > be updated, as will the logic regarding generation of offers and > answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the authors. If I read what you're saying correctly, it sounds like you're talking about changes that are significant enough that we'll have to put JSEP through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer to see this done very soon, if such changes are required. When do you believe such an update could be available? I've copied the RFC Series Editor on this note for her awareness. /a From nobody Tue Oct 2 09:46:56 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3912785F; Tue, 2 Oct 2018 09:46:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OYNMxXTJmmoE; Tue, 2 Oct 2018 09:46:45 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A83128D68; Tue, 2 Oct 2018 09:46:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E3BC11D06E0; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diQf7_ynoKzC; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [108.177.128.150]) by c8a.amsl.com (Postfix) with ESMTPSA id 693D71D06DD; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) To: Justin Uberti , Adam Roach Cc: Peter Thatcher , RTCWeb IETF , Cullen Jennings , Christer Holmberg , ice@ietf.org References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> From: Heather Flanagan Message-ID: <35975d78-76b7-b317-c43a-2a57e33198e7@rfc-editor.org> Date: Tue, 2 Oct 2018 09:47:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------682A0A1FF2E5BA1B6425480C" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 02 Oct 2018 16:46:55 -0000 This is a multi-part message in MIME format. --------------682A0A1FF2E5BA1B6425480C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for copying me in, Adam. I definitely agree that this level of change is significant enough that it can't be handled in AUTH48. But, better it be right than fast! -Heather On 10/1/18 1:27 PM, Justin Uberti wrote: > [dropping some DLs] > > I think this is probably a day of work, but will probably take 2 weeks > to author and get approval for. > > If we go down this path, I would also suggest taking the two pending > PRs in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > > On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti > wrote: > > I think this is probably a day of work, but will probably take 2 > weeks to author and get approval for. > > If we go down this path, I would also suggest taking the two > pending PRs in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > On Mon, Oct 1, 2018 at 12:17 PM Adam Roach > wrote: > > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already > closer to 8445 > > than 5245, so I don't see any issues associated with > snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes > than just > > the addition of the 8445 reference and note; the examples > will have to > > be updated, as will the logic regarding generation of offers > and > > answers and their parsing (to deal with the new ice-option). > These > > changes will be modest but probably will need to be done by > the authors. > > > If I read what you're saying correctly, it sounds like you're > talking > about changes that are significant enough that we'll have to > put JSEP > through IETF last call and through the IESG again. That being > the case, > and the rest of the cluster being so close to done, I'd really > prefer to > see this done very soon, if such changes are required. When do > you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > --------------682A0A1FF2E5BA1B6425480C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Thanks for copying me in, Adam. I definitely agree that this level of change is significant enough that it can't be handled in AUTH48. But, better it be right than fast!


-Heather

On 10/1/18 1:27 PM, Justin Uberti wrote:
[dropping some DLs]

I think this is probably a day of work, but will probably take 2 weeks to author and get approval for.

If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti <juberti@google.com> wrote:
I think this is probably a day of work, but will probably take 2 weeks to author and get approval for.

If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <adam@nostrum.com> wrote:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8445
> than 5245, so I don't see any issues associated with snapping this
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just
> the addition of the 8445 reference and note; the examples will have to
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These
> changes will be modest but probably will need to be done by the authors.


If I read what you're saying correctly, it sounds like you're talking
about changes that are significant enough that we'll have to put JSEP
through IETF last call and through the IESG again. That being the case,
and the rest of the cluster being so close to done, I'd really prefer to
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

--------------682A0A1FF2E5BA1B6425480C-- From nobody Wed Oct 3 15:15:01 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F60712F295 for ; Wed, 3 Oct 2018 15:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 pLTi1DD36deJ for ; Wed, 3 Oct 2018 15:14:55 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-oln040092011086.outbound.protection.outlook.com [40.92.11.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43364130DC7 for ; Wed, 3 Oct 2018 15:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TZn9Yri57Hi1jjjvYfj2d8vnu6LoFr0+ifDGzjQUDkA=; b=RG8CueSTkNDKPImPFWAkqyrhyijqwR24RHfEqYWPom3vLD2qAlac7OiXhP9M6SklanEkCOZW5LVf0bEFcZ7+5uNsIVrWWuliwJ0Oct+VH0IbdRyVmMj0gOEpbWDN2r3SuMwkRFN7JjVf5toFXzExaxq7uslsZCUDCye/fb4M2SdTbfP96zSUuxxSg1x2gLYBHvhTb6zTESultCcbth17g8xPdipKr1WONLDcOuV00vMNc+hUpL341afulQKFLqopsU3RCWz/THMevlM5f8wJWpsaLoxaDUsiK1qdE0/phl4ptHFFB2/Z13zkFfleUPKYS1Inp2TVcIMh1xNrn5H3hw== Received: from SN1NAM04FT043.eop-NAM04.prod.protection.outlook.com (10.152.88.54) by SN1NAM04HT114.eop-NAM04.prod.protection.outlook.com (10.152.88.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1185.13; Wed, 3 Oct 2018 22:14:51 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com (10.152.88.51) by SN1NAM04FT043.mail.protection.outlook.com (10.152.89.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1185.13 via Frontend Transport; Wed, 3 Oct 2018 22:14:51 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb]) by CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb%4]) with mapi id 15.20.1207.021; Wed, 3 Oct 2018 22:14:51 +0000 From: Adam Sobieski To: Bernard Aboba , "ted.ietf@gmail.com" CC: RTCWeb IETF Thread-Topic: [rtcweb] WebRTC and Real-time Translation Thread-Index: AQHUVe1M2MPUNlozpUmfS3sPuCqXG6UDkYIAgAE+1yWACUt9Kg== Date: Wed, 3 Oct 2018 22:14:51 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:E2CEEF4D332B571220F9BDDD5E2CFDD3BA9DA662242CEF78D2A474BDB29B2A25; UpperCasedChecksum:95961258FC94EBE78793883ABB5BDC14AF5BB0F2F11355640B00028CAED3E34C; SizeAsReceived:7309; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [sA5kPmbODwk6iyxI+g91miFUniJRR8tf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT114; 6:ZNqg6fIKmLxZdS6de4OYXGmqObb5gW6znEyIxZX1Cw/l6EOKzlEFKJSpeo/2cGmNq8r7zWLEH2fLPvBP9Z04V8K09d8oChG8Arop57AIomLWORUK816X4cH1TfB6phwFHBVanparDBmRiwBJWhr9NkRz74uW+cVCi6DakaU1QndZxeawGTdmOrLkCOKIOR07Q0sLr3r+rkEozJ409u0+PPOCkz2m7HDWNxsJgSHnHeEPUB3VpnwPIW1FPsGLIsINqXJYpE9KOM8xiz4Puepp5WuWeH/CMmMg3RVKtLmEvl5IYFlY4pQXz33lrs3s9i+mp8aq2tiGOaFBOtbNjdMBWBKVT705jFq4hj7hs276QPsYMg41e4DEnHPV33B1Gx4knaGt7bpOTe/WQTfd7Zugfz+PeFA/yVjTLbrQdSug8TfE+PgzOGxjdkz/9qUYNKwyTBk9icX1cUljRGemVNWMng==; 5:e/S3k2v8PWL1Bdu0WglctTVHkLJT8ODOaOM/crXa0DQt7Mcp80p80mUwMPq3mZl2IZKpTBWYw6G64iAYaGW34ZufscG5Y9ZOjQNwrqIN4iV89kt2kGkV82ddKadNhM/Uy3gN51ruzI3FdmPvBTGySOLKnkNVVypmemg2CQYXgas=; 7:ub1Lb+34YXj4VX9WNQIBmP3dy/y56YBbD/qr0djtubvTyZivie7qb5O3qKTu/rvn+fj2stQqHjksgoxuLKgj5st1KVPbL9aYutJLFhJozENm4ArRhXSZ7aLlx/1ZLbNSkcEprFpHVqKbno9Z2SdcMVDgLKM/ePu+Lsm4FOABR+25MqkQWsPRlkqkaIKUsPk7EqdvNMhPctDAmnRg8o4Y8CUm6/VsE/hLJBBWLmovUl2swEYZsWPNU+JccV8DcSEK x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM04HT114; x-ms-traffictypediagnostic: SN1NAM04HT114: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM04HT114; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT114; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(575784001)(54896002)(97736004)(236005)(345774005)(4326008)(20460500001)(26005)(606006)(7696005)(71200400001)(6506007)(87572001)(53546011)(5660300001)(86362001)(99286004)(71190400001)(9686003)(45080400002)(25786009)(6246003)(76176011)(14444005)(2900100001)(966005)(81156014)(74316002)(5250100002)(102836004)(6346003)(83332001)(256004)(11346002)(39060400002)(6436002)(476003)(105586002)(2501003)(56003)(104016004)(55016002)(82202002)(446003)(6306002)(106356001)(73972006)(486006)(110136005)(68736007)(33656002)(53946003)(14454004)(8936002)(8676002)(229853002)(4744004)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT114; H:CY4PR0101MB3095.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=adamsobieski@hotmail.com; x-microsoft-antispam-message-info: pqXWKuOeYgReHJ+KjSuBfin9vrBAFFQhyqiDNUkjLLmSPo7yWTUbt7GEcKCp2dmgTHmzKhhhIAr7TwbPmTTRH4jlVnTLw9OF2SB5z0kb90bwZrSmUc/UE4Y21KpfyffgvP6Yv2cfQFxPrImmmN6wRzhm6aeYURPsC2t5spG5J8mfZaFqmXOLtHWiTBp6jSsU/EOingSpJHu8I8H3Ve1Kcpx5Rqt9k8U3/X+UMylAfg8= Content-Type: multipart/alternative; boundary="_000_CY4PR0101MB3095D308D294CCC2EF9026A2C5E90CY4PR0101MB3095_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: a84d17ca-db10-4fd6-fc0e-08d6297da3ac X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 22:14:51.2240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT114 Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Oct 2018 22:15:00 -0000 --_000_CY4PR0101MB3095D308D294CCC2EF9026A2C5E90CY4PR0101MB3095_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RTP Media API https://www.w3.org/TR/webrtc/#rtp-media-api =93The RTP media API lets a web application send and receive MediaStreamTra= cks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnect= ion, result in signaling; when this signaling is forwarded to a remote peer= , it causes corresponding tracks to be created on the remote side.=94 =93The actual encoding and transmission of MediaStreamTracks is managed thr= ough objects called RTCRtpSenders. Similarly, the reception and decoding of= MediaStreamTracks is managed through objects called RTCRtpReceivers. Each = RTCRtpSender is associated with at most one track, and each track to be rec= eived is associated with exactly one RTCRtpReceiver.=94 Envisioned for real-time translation scenarios is that audio tracks =96 or = copies of audio tracks =96 can be routed through one or more local componen= ts and remote services such that resultant output can be either sent to a r= emote side or multicast to multiple other peers. In particular for scenario= s which utilize remote services, audio tracks to be translated may travel o= utside of the envelopes for other tracks. Translated content should rejoin = other tracks on the remote side for synchronized presentation or processing= . Real-time audio-to-audio translation is one scenario. Another scenario is r= eal-time audio-to-subtitles translation where the results of real-time tran= slation are desired to arrive as a subtitles track. A third scenario is whe= re translation results are desired to arrive as data, for example to appear= on-screen per the formatting and layout of a web application. The output f= rom one or more interconnected components and services which perform real-t= ime translation could then include: (1) audio, (2) subtitles, (3) data. Use Case: Funny Hats https://w3c.github.io/webrtc-nv-use-cases/#funnyhats* The capability of routing one or more tracks through one or more local comp= onents and remote services also facilitates scenarios resembling those disc= ussed in the use case: Funny Hats. Differences include: (1) funny hats scenarios utilize video tracks and (2) = real-time translation scenarios, while possible to present as singular serv= ices, may include a daisy-chaining or a pipelining of a number of local com= ponents or remote services: speech recognition, translation and speech synt= hesis. As with real-time translation, we can envision free as well as priced video= processing services. Best regards, Adam Sobieski ________________________________ From: rtcweb on behalf of Adam Sobieski Sent: Thursday, September 27, 2018 8:50:02 PM To: Bernard Aboba; ted.ietf@gmail.com Cc: RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation Bernard Aboba, Ted Hardie, Client-side Transcription and Translation With respect to client-side speech recognition, transcription, translation = and speech synthesis scenarios, we can consider GPGPU approaches. HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognition engine that le= verages modern GPU-based parallel computing architectures to realize accura= te real-time recognition with extremely large models.=94 In 2012, Professor= Ian Lane indicated that HYDRA performs 20x faster than other approaches [3= ]. Deep Speech [4][5][6] is a deep-learning-based approach to speech recogniti= on which =93outperforms previously published results on the widely studied = Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93h= andles challenging noisy environments better than widely used, state-of-the= -art commercial speech systems..=94 Articulatory synthesis can be accelerated by graphics cards [7]. WaveNet [8][9] is a deep generative model of raw audio waveforms including = speech audio. Facebook AI Research recently advanced machine translation [10], advancing = performance metrics by 10 BLEU points. With respect to desktop-based translation, vendors such as SYSTRAN [11] off= er desktop-based, server-based and cloud-based solutions. There are some desktop-based transcription and machine translation solution= s [12] and it is expected that real-time client-side solutions for transcri= ption and translation, processing speech audio, will exist in the upcoming = years, at least for desktop computing if not mobile computing. On-premises Transcription and Translation In addition to client-side solutions, on-premises solutions can deliver low= ered latency and enhanced privacy. Server-side and Cloud-based Transcription and Translation For a number of scenarios including mobile computing, server-side and cloud= -based transcription and translation services make sense. Major software vendors such as Amazon, Facebook, Google, IBM and Microsoft = offer priced cloud-based services which include speech recognition, machine= translation and speech synthesis. Post-text Speech Technology I am an advocate of post-text speech technologies. Speech-to-text is too lo= ssy. Information pertaining to prosody, intonation, emphases and pauses are= discarded in text output. Such information can be useful, for example info= rming machine translation components and services. In addition to speech-to= -SSML speech recognition and SSML-to-SSML machine translation scenarios, we= can envision new, intermediate data formats beyond SSML. The inputs and outputs of speech recognition, translation and speech synthe= sis components and services could be multiple formats =96 formats other tha= n text. API Sketch: Dataflow Graphs Sketches with respect to APIs include the declarative construction of dataf= low graphs which interconnect abstract components. Such APIs can abstract a= way whether the interconnectable components are client-side, on-prem, serve= r-side, third-party or cloud-based. Such APIs can abstract away whether the= interconnectable components are for free or priced to end-users. Considera= tions to such API include the data formats and stream specifications of com= ponents=92 various inputs and outputs to be interconnected. Dataflow graphs can be an intuitive abstraction layer, one which provides i= ntuitive and convenient programming while interconnecting arbitrary numbers= of components and services. Dataflow graphs can interconnect client-side a= nd remote speech recognition, translation and speech synthesis components a= s well as any other components which could reasonably be interconnected or = pipelined. When such dataflow graphs are prepared for activation, it is envisioned tha= t users will be provided with notifications, requests for permissions and o= ptions for payment. Potential IETF Work Items When such dataflow graphs are activated, it is envisioned that computer net= working protocols will be utilized to notify remote components or services = of proper data routings, e.g. daisy-chain or pipeline configurations, in a = secure manner. That is, there may be new protocols and computer networking topics with reg= ard to implementing the APIs for interconnecting WebRTC peers with speech r= ecognition, translation and speech synthesis components and services. Conclusion Tight WebRTC integration is important for envisioned efficient, low-latency= , high-performance, scalable real-time translation scenarios. While there exist some ad hoc approaches to providing real-time translation= with WebRTC, standardizing new APIs and protocols can convenience develope= rs, convenience end users, and create new markets with respect to real-time= translation scenarios. Thank you for considering adding real-time translation to the use cases for= a next version of WebRTC. I look forward to any discussion on these topics= . References [1] http://www.cs.cmu.edu/~ianlane/hydra/ [2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY [3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg [4] https://arxiv.org/abs/1412.5567 [5] https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu= -accelerated-deep-learning/ [6] https://github.com/mozilla/DeepSpeech [7] https://open.library.ubc.ca/media/stream/pdf/24/1.0348751/3 [8] https://deepmind.com/blog/wavenet-generative-model-raw-audio/ [9] https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/ [10] https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just= -set-a-new-record-in-translation-and-why-it-matters/#205b9e5b3124 [11] https://store.systran.us/lp/storeSystran?Langue=3Den_US [12] https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applic= ations From: Bernard Aboba Sent: Thursday, September 27, 2018 12:58 AM Subject: Re: [rtcweb] WebRTC and Real-time Translation One of the key questions for "Next Version Use Cases" is what WebRTC-defici= encies are preventing these use cases from being satisfactorily implemented= today. For example, speech transcription cloud services have been implemented over= Websockets, where a snippet of speech is uploaded, and a transcription is = provided in reply. The latency is satisfactory for some uses cases. Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API. What seems to differentiate *next version* scenarios are situations where t= he processing is best done on the device, in order to lower latency or enha= nce privacy. On-device processing brings in discussion of workers/worklets= , access to raw audio/video, etc. However, so far I'm not aware of on-devi= ce implementations of transcription or translation. On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski > wrote: IETF RTCWEB Working Group, Greetings. I opened an issue on WebRTC and Real-time Translation at the Git= Hub repository for WebRTC version next use cases (https://github.com/w3c/we= brtc-nv-use-cases/issues/2). Introduction Real-time translation is both an interesting and important use case for a n= ext version of WebRTC. Speech Recognition, Translation and Speech Synthesis Approaches to real-time speech-to-speech machine translation include those = which interconnect speech recognition, translation and speech synthesis com= ponents and services. In that regard, we can consider client-side, on-prem,= server-side, third-party and cloud-based components and services. In that = regard, we can also consider both free and priced components and services. We can envision post-text speech technology and machine translation compone= nts and services. Speech recognition need not output to text; we can consid= er speech-to-SSML. Machine translation need not input from nor output to te= xt; we can consider SSML-to-SSML machine translation. Components and servic= es may provide various options with respect to their input and output data = formats. Connecting Components and Services by Constructing Graphs We can consider APIs which facilitate the construction of graphs which repr= esent the flow of data between components and services. As these graphs are= constructed, users could be apprised of relevant notifications, requests f= or permissions and options for payments. As these constructed graphs are ac= tivated, a number of protocols could be utilized to interconnect the compon= ents and services which, together, provide users with real-time translation= . Hyperlinks WebRTC Translator Demo Real Time Translation in WebRTC Best regards, Adam Sobieski http://www.phoster.com/contents/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CY4PR0101MB3095D308D294CCC2EF9026A2C5E90CY4PR0101MB3095_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

RTP Media API

https://www.w3.org/TR/webrtc/#rtp-media-api

=93The RTP media API lets a web application send and receive MediaStre= amTracks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnection, result in signaling; when this signali= ng is forwarded to a remote peer, it causes corresponding tracks to be crea= ted on the remote side.=94

=93The actual encoding and transmission of MediaStreamTracks is manage= d through objects called RTCRtpSenders. Similarly, the reception and decoding of MediaStreamTracks is managed through objects= called RTCRtpReceivers. Each RTCRtpSender is associated with at most one t= rack, and each track to be received is associated with exactly one RTCRtpRe= ceiver.=94

Envisioned for real-time translation scenarios is that audi= o tracks =96 or copies of audio tracks =96 can be routed through one or mor= e local components and remote services such that resultant output can be either sent to a remote side or multicast to multi= ple other peers. In particular for scenarios which utilize remote services,= audio tracks to be translated may travel outside of the envelopes for othe= r tracks. Translated content should rejoin other tracks on the remote side for synchronized presentation or pr= ocessing.

Real-time audio-to-audio translation is one scenario. Anoth= er scenario is real-time audio-to-subtitles translation where the results o= f real-time translation are desired to arrive as a subtitles track. A third scenario is where translation results are de= sired to arrive as data, for example to appear on-screen per the formatting= and layout of a web application. The output from one or more interconnecte= d components and services which perform real-time translation could then include: (1) audio, (2) = ;subtitles, (3) data.

Use Case: Funny Hats

https://w3c.github.io/webrtc-nv-use-ca= ses/#funnyhats*

The capability of routing one or more tracks through one or= more local components and remote services also facilitates scenarios resem= bling those discussed in the use case: Funny Hats.

Differences include: (1) funny hats scenarios utilize video= tracks and (2) real-time translation scenarios, while possible to present = as singular services, may include a daisy-chaining or a pipelining of a number of local components or remote services: speech= recognition, translation and speech synthesis.

As with real-t= ime translation, we can envision free as well as priced video processing se= rvices.

 

 

Best regards,

Adam Sobieski

 

From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Adam Sobieski <adamsobieski@hotmail.com&g= t;
Sent: Thursday, September 27, 2018 8:50:02 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation
 

Bernard = Aboba,
Ted Hardie,

Client-side Transcription and Translation=

With respect to client-side speech recognition, transcripti= on, translation and speech synthesis scenarios, we can consider GPGPU appro= aches.

HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognitio= n engine that leverages modern GPU-based parallel computing architectures t= o realize accurate real-time recognition with extremely large models.=94 In 2012, Professor Ian Lane indicated that HYDR= A performs 20x faster than other approaches [3].

Deep Speech [4][5][6] is a deep-learning-based approach to = speech recognition which =93outperforms previously published results on the= widely studied Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93handles challenging noisy envir= onments better than widely used, state-of-the-art commercial speech systems= ..=94

Articulatory synthesis can be accelerated by graphics cards= [7].

WaveNet [8][9] is a deep generative model of raw audio wave= forms including speech audio.

Facebook AI Research recently advanced machine translation = [10], advancing performance metrics by 10 BLEU points.

With respect to desktop-based translation, vendors such as = SYSTRAN [11] offer desktop-based, server-based and cloud-based solutions.

There are some desktop-based transcription and machine tran= slation solutions [12] and it is expected that real-time client-side soluti= ons for transcription and translation, processing speech audio, will exist in the upcoming years, at least for desktop compu= ting if not mobile computing.

On-premises Transcription and Translation=

In addition to client-side solutions, on-premises solutions= can deliver lowered latency and enhanced privacy.

Server-side and Cloud-based Transcription and Translation

For a number of scenarios including mobile computing, serve= r-side and cloud-based transcription and translation services make sense.

Major software vendors such as Amazon, Facebook, Google, IB= M and Microsoft offer priced cloud-based services which include speech reco= gnition, machine translation and speech synthesis.

Post-text Speech Technology

I am an advocate of post-text speech technologies. Speech-t= o-text is too lossy. Information pertaining to prosody, intonation, emphase= s and pauses are discarded in text output. Such information can be useful, for example informing machine translation compo= nents and services. In addition to speech-to-SSML speech recognition and SS= ML-to-SSML machine translation scenarios, we can envision new, intermediate= data formats beyond SSML.

The inputs and outputs of speech recognition, translation a= nd speech synthesis components and services could be multiple formats =96 f= ormats other than text.

API Sketch: Dataflow Graphs

Sketches with respect to APIs include the declarative const= ruction of dataflow graphs which interconnect abstract components. Such API= s can abstract away whether the interconnectable components are client-side, on-prem, server-side, third-party or cloud-bas= ed. Such APIs can abstract away whether the interconnectable components are= for free or priced to end-users. Considerations to such API include the da= ta formats and stream specifications of components=92 various inputs and outputs to be interconnected.

Dataflow graphs can be an intuitive abstraction layer, one = which provides intuitive and convenient programming while interconnecting a= rbitrary numbers of components and services. Dataflow graphs can interconnect client-side and remote speech recognition= , translation and speech synthesis components as well as any other componen= ts which could reasonably be interconnected or pipelined.=

When such dataflow graphs are prepared for activation, it i= s envisioned that users will be provided with notifications, requests for p= ermissions and options for payment.

Potential IETF Work Items

When such dataflow graphs are activated, it is envisioned t= hat computer networking protocols will be utilized to notify remote compone= nts or services of proper data routings, e.g. daisy-chain or pipeline configurations, in a secure manner.

That is, there may be new protocols and computer networking= topics with regard to implementing the APIs for interconnecting WebRTC pee= rs with speech recognition, translation and speech synthesis components and services.

Conclusion

Tight WebRTC integration is important for envisioned effici= ent, low-latency, high-performance, scalable real-time translation scenario= s.

While there exist some ad hoc approaches to providing real-= time translation with WebRTC, standardizing new APIs and protocols can conv= enience developers, convenience end users, and create new markets with respect to real-time translation scenarios.

Thank you for considering adding real-time translation to t= he use cases for a next version of WebRTC. I look forward to any discussion= on these topics.

References

[1] = http://www.cs.cmu.edu/~ianlane/hydra/<= /a>
[2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY<= /a>
[3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg<= /a>
[4] https://arxiv.org/abs/1412.5567
[5] = https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu-acc= elerated-deep-learning/
[6] https://github.com/mozilla/DeepSpeech
[7] https://open.library.ubc.ca/media/strea= m/pdf/24/1.0348751/3
[8] https://deepmind.com/blog/wavenet-gen= erative-model-raw-audio/
[9] https://devblogs.nvidia.com/nv-wavenet= -gpu-speech-synthesis/
[10] https://www.forbes.com/sites/williamf= alcon/2018/09/01/facebook-ai-just-set-a-new-record-in-translation-and-why-i= t-matters/#205b9e5b3124
[11] https://store.systran.us/lp/storeSystran?L= angue=3Den_US
[12] https://en.wikipedia.= org/wiki/Comparison_of_machine_translation_applications

 

 

From: Bernard Aboba
Sent: Thursday, September 27, 2018 12:58 AM
Subject: Re: [rtcweb] WebRTC and Real-time Translation

 

One of the key questions for "Next Version Use = Cases" is what WebRTC-deficiencies are preventing these use cases from= being satisfactorily implemented today. 

 

For example, speech transcription cloud services hav= e been implemented over Websockets, where a snippet of speech is uploaded, = and a transcription is provided in reply.  The latency is satisfactory= for some uses cases. 

Improvements can perhaps be made by sending an audio= stream and receiving a transcription via the data channel, but this is als= o within the capabilities of the existing RTCWEB protocols and WebRTC-PC AP= I. 

 

What seems to differentiate *next version* scenarios= are situations where the processing is best done on the device, in order t= o lower latency or enhance privacy.  On-device processing brings in di= scussion of workers/worklets, access to raw audio/video, etc.  However, so far I'm not aware of on-device imp= lementations of transcription or translation.

 

On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> = wrote:

IETF RTCWEB Working Group,

 

Greetings. I opened an issue on WebRTC and Real-time Translation at the GitHub repository for WebRTC= version next use cases (https://github.com/w3c/webrtc-nv-use-cases/= issues/2).

 

Introdu= ction

Real-tim= e translation is both an interesting and important use case for a next vers= ion of WebRTC.

Speech = Recognition, Translation and Speech Synthesis

Approach= es to real-time speech-to-speech machine translation include those which in= terconnect speech recognition, translation and speech synthesis components and services. In that regard, we can consider = client-side, on-prem, server-side, third-party and cloud-based components a= nd services. In that regard, we can also consider both free and priced comp= onents and services.

We can e= nvision Connect= ing Components and Services by Constructing Graphs

We can c= onsider APIs which facilitate the construction of graphs which represent th= e flow of data between components and services. As these graphs are constructed, users could be apprised of relevant notif= ications, requests for permissions and options for payments. As these const= ructed graphs are activated, a number of protocols could be utilized to int= erconnect the components and services which, together, provide users with real-time translation.

Hyperli= nks

WebRTC Translator Demo
Real Time Translation in WebRTC

 

 

Best regards,

Adam Sobieski

htt= p://www.phoster.com/contents/

 

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

 

--_000_CY4PR0101MB3095D308D294CCC2EF9026A2C5E90CY4PR0101MB3095_-- From nobody Thu Oct 4 10:25:15 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0154130D7A for ; Thu, 4 Oct 2018 10:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 Rzxbot2mfFaZ for ; Thu, 4 Oct 2018 10:25:02 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0086.outbound.protection.outlook.com [216.32.180.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E3B130EC0 for ; Thu, 4 Oct 2018 10:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eselsHwu0u2Asxxjo1sQ549RDRpXO2LoKXP1VhWmwfI=; b=t+9Kt1gnzPhTEO14b2drbibJJSKC7cCkduW7WHdrVHBjKWlQt0DqhCjpA7NOKN3Ocb0Vp2uuw+8B3K9n79FbCd/oxeHUODfEf0qTSSdFfIpzPVn3RH+S12cMpT2SSe1z+nJwx0fiI6sEjEurh/5mBj6HuXPPygyYCHQDdTuTCEKSoVhFKHIiKi8C6svrGWrZ/ouZvvCeyp7dDZnb/laU9ZU26VDbZeiLCbmrPUGEj2iV9rUgWvWaYVxQ35orNSD4aD0LIRdEHzNwmMSBzJlj/uQSqTRPpZxrhKNZp9mUdgSbDwPCJa9wDdHzRCmqSXy5Ng1E5+5UBx50ZGys08l/Hw== Received: from CO1NAM04FT045.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT100.eop-NAM04.prod.protection.outlook.com (10.152.91.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1207.19; Thu, 4 Oct 2018 17:25:00 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com (10.152.90.56) by CO1NAM04FT045.mail.protection.outlook.com (10.152.91.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1207.19 via Frontend Transport; Thu, 4 Oct 2018 17:25:00 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb]) by CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb%4]) with mapi id 15.20.1207.022; Thu, 4 Oct 2018 17:25:00 +0000 From: Adam Sobieski To: Bernard Aboba , "ted.ietf@gmail.com" CC: RTCWeb IETF Thread-Topic: [rtcweb] WebRTC and Real-time Translation Thread-Index: AQHUVe1M2MPUNlozpUmfS3sPuCqXG6UDkYIAgAE+1yWACUt9KoABRHMw Date: Thu, 4 Oct 2018 17:25:00 +0000 Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:6BC1732E1E06C59EFF80301F35AB7720457C6A51296A3119C67E97D218613A0F; UpperCasedChecksum:D0187F53B2F07F43AB3C620E4E3CB51BD20D6C17B38403C0193BD9E65BEA2CDF; SizeAsReceived:7416; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [dzSuZ4cRUfB9yXUILS0UYDjC7ddL0vc9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT100; 6:yMU4yPjGfKLchciL4fn2bD1OgvUVXIro33aUJWv7i4yRtDYmkFCumrQ9xEHLFHQyYh3NQol9lXQ+VJR6MFBLVr+Xo5V3ngK8U9ZssC4sHj0FsnvhlwLClXLbWJ3vnbv+LzgdS5If42SOA5F2Sj2pd12UMLif+cYcX2Y6Km+xbb1GSG2yTr1LgUaAZ/UyxFsSXXJTAttnNJ9OpBF6kkLXxVlaurFbw29M1vgOCKQW24GgsGl5n+kHGlLiDMorD3AV2SupexDl7DuyHVBltvZ14WkbJYZ0Y2U+DnjJ9AlomoheGzz59WnyWar27scHjSug1xe9R0quHRGSJMowTjwNsBF3+83a3SJvJGFytHayOdw0s+E/bGYY++jmfT/fCh+EK6MDJ1fWcWYGt4WvB+I8dJyj4t3lZhORNzBPpgKygPMq/fQTQ0YmkEKJixWj4rHlnzlmRqOa+D0r3QdCYS/+pw==; 5:h72AdGgE3hiPBtrzWbIk0uqoj4T8TP8YDOetwVFl/oKRuvESq5fLLOsTjz5VTSfnPZ2vd8vOZfrFTDz0ybNcFOxmPLpN8lRHw+8kpj3ILmwwxvxWS9Uw2PUv33QjTqxUlPxAh+JF5tZeyfc8JmOlGz9RsMkrWKVvBI/UC6FDGL8=; 7:SZlNlmDYtNRfpylIq31wAGlq2MO6cr/uJgV55T1AOoDtvjQq2pu6JXETY2M18UaGrGyXQziBh8GUetk9sujzn6dOz1a8yX5geWJCUD6FY9JiPUTvw2caPxhpVxvJxCTcKX7Tnp96TjfQF1CiHkdKBMM7zT64faCC3CDAW6XRLs5rCTVtNjsYYo2M95UdWAASSovTzZKUWO8s6Rq48Vf+y7kw2M3KE4FUY5+39FdLYkYzGpzUwUXGCoDmmMcQHNuI x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:CO1NAM04HT100; x-ms-traffictypediagnostic: CO1NAM04HT100: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM04HT100; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT100; x-microsoft-antispam-message-info: WbyUikJgIVv1PtNg1RvKB2Z7/gr/9B3mt8FGCFc/9OyrscmfvxEGxBRuyq4gMv4J Content-Type: multipart/alternative; boundary="_000_CY4PR0101MB3095CD494BF85133BBE9C51DC5EA0CY4PR0101MB3095_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: 401c1a4a-9fde-4348-a643-08d62a1e5072 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 17:25:00.5642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT100 Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Oct 2018 17:25:08 -0000 --_000_CY4PR0101MB3095CD494BF85133BBE9C51DC5EA0CY4PR0101MB3095_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A New Transport Protocol? The QUIC API [1] shows how to extend the WebRTC specification to enable the= use of a new transport protocol. =93This specification extends the WebRTC specification [WEBRTC] to enable t= he use of QUIC [QUIC-TRANSPORT] to exchange arbitrary data with remote peer= s using NAT-traversal technologies such as ICE, STUN, and TURN. Since QUIC = can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, this= specification is compatible with all the functionality defined in [WEBRTC]= , including communication using audio/video media and SCTP data channels.= =94 It could be that, for both real-time translation and video processing scena= rios utilizing combinations of local components and remote services, that a= new transport protocol or a new version of an existing transport protocol = is needed. Such a transport protocol could facilitate transmitting and rout= ing certain streams (or copies of certain streams) outside of envelopes bet= ween two or more peers such that such streams rejoin other streams in envel= opes on remote peers. With such a transport protocol, one could specify, prepare and activate pro= cessing graphs for one or more audio, video or data streams. A processing g= raph could be such that a stream passes through speech recognition, transla= tion and speech synthesis components or services between two or more peers.= A processing graph could be such that a stream passes through a video proc= essing component or service between two or more peers. Hopefully, I=92ve indicated how tractable it is to add real-time translatio= n and video processing to a next version of WebRTC. I=92m confident that we= can solve any remaining technical details in the upcoming years. What do you think about this approach, a solution including a new transport= protocol or version of a transport protocol to provide real-time translati= on and real-time video processing utilizing interconnected local components= and remote services? References [1] https://w3c.github.io/webrtc-quic/ Best regards, Adam Sobieski ________________________________ From: rtcweb on behalf of Adam Sobieski Sent: Wednesday, October 3, 2018 6:14:51 PM To: Bernard Aboba; ted.ietf@gmail.com Cc: RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation RTP Media API https://www.w3.org/TR/webrtc/#rtp-media-api =93The RTP media API lets a web application send and receive MediaStreamTra= cks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnect= ion, result in signaling; when this signaling is forwarded to a remote peer= , it causes corresponding tracks to be created on the remote side.=94 =93The actual encoding and transmission of MediaStreamTracks is managed thr= ough objects called RTCRtpSenders. Similarly, the reception and decoding of= MediaStreamTracks is managed through objects called RTCRtpReceivers. Each = RTCRtpSender is associated with at most one track, and each track to be rec= eived is associated with exactly one RTCRtpReceiver.=94 Envisioned for real-time translation scenarios is that audio tracks =96 or = copies of audio tracks =96 can be routed through one or more local componen= ts and remote services such that resultant output can be either sent to a r= emote side or multicast to multiple other peers. In particular for scenario= s which utilize remote services, audio tracks to be translated may travel o= utside of the envelopes for other tracks. Translated content should rejoin = other tracks on the remote side for synchronized presentation or processing= . Real-time audio-to-audio translation is one scenario. Another scenario is r= eal-time audio-to-subtitles translation where the results of real-time tran= slation are desired to arrive as a subtitles track. A third scenario is whe= re translation results are desired to arrive as data, for example to appear= on-screen per the formatting and layout of a web application. The output f= rom one or more interconnected components and services which perform real-t= ime translation could then include: (1) audio, (2) subtitles, (3) data. Use Case: Funny Hats https://w3c.github.io/webrtc-nv-use-cases/#funnyhats* The capability of routing one or more tracks through one or more local comp= onents and remote services also facilitates scenarios resembling those disc= ussed in the use case: Funny Hats. Differences include: (1) funny hats scenarios utilize video tracks and (2) = real-time translation scenarios, while possible to present as singular serv= ices, may include a daisy-chaining or a pipelining of a number of local com= ponents or remote services: speech recognition, translation and speech synt= hesis. As with real-time translation, we can envision free as well as priced video= processing services. Best regards, Adam Sobieski ________________________________ From: rtcweb on behalf of Adam Sobieski Sent: Thursday, September 27, 2018 8:50:02 PM To: Bernard Aboba; ted.ietf@gmail.com Cc: RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation Bernard Aboba, Ted Hardie, Client-side Transcription and Translation With respect to client-side speech recognition, transcription, translation = and speech synthesis scenarios, we can consider GPGPU approaches. HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognition engine that le= verages modern GPU-based parallel computing architectures to realize accura= te real-time recognition with extremely large models.=94 In 2012, Professor= Ian Lane indicated that HYDRA performs 20x faster than other approaches [3= ]. Deep Speech [4][5][6] is a deep-learning-based approach to speech recogniti= on which =93outperforms previously published results on the widely studied = Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93h= andles challenging noisy environments better than widely used, state-of-the= -art commercial speech systems...=94 Articulatory synthesis can be accelerated by graphics cards [7]. WaveNet [8][9] is a deep generative model of raw audio waveforms including = speech audio. Facebook AI Research recently advanced machine translation [10], advancing = performance metrics by 10 BLEU points. With respect to desktop-based translation, vendors such as SYSTRAN [11] off= er desktop-based, server-based and cloud-based solutions. There are some desktop-based transcription and machine translation solution= s [12] and it is expected that real-time client-side solutions for transcri= ption and translation, processing speech audio, will exist in the upcoming = years, at least for desktop computing if not mobile computing. On-premises Transcription and Translation In addition to client-side solutions, on-premises solutions can deliver low= ered latency and enhanced privacy. Server-side and Cloud-based Transcription and Translation For a number of scenarios including mobile computing, server-side and cloud= -based transcription and translation services make sense. Major software vendors such as Amazon, Facebook, Google, IBM and Microsoft = offer priced cloud-based services which include speech recognition, machine= translation and speech synthesis. Post-text Speech Technology I am an advocate of post-text speech technologies. Speech-to-text is too lo= ssy. Information pertaining to prosody, intonation, emphases and pauses are= discarded in text output. Such information can be useful, for example info= rming machine translation components and services. In addition to speech-to= -SSML speech recognition and SSML-to-SSML machine translation scenarios, we= can envision new, intermediate data formats beyond SSML. The inputs and outputs of speech recognition, translation and speech synthe= sis components and services could be multiple formats =96 formats other tha= n text. API Sketch: Dataflow Graphs Sketches with respect to APIs include the declarative construction of dataf= low graphs which interconnect abstract components. Such APIs can abstract a= way whether the interconnectable components are client-side, on-prem, serve= r-side, third-party or cloud-based. Such APIs can abstract away whether the= interconnectable components are for free or priced to end-users. Considera= tions to such API include the data formats and stream specifications of com= ponents=92 various inputs and outputs to be interconnected. Dataflow graphs can be an intuitive abstraction layer, one which provides i= ntuitive and convenient programming while interconnecting arbitrary numbers= of components and services. Dataflow graphs can interconnect client-side a= nd remote speech recognition, translation and speech synthesis components a= s well as any other components which could reasonably be interconnected or = pipelined. When such dataflow graphs are prepared for activation, it is envisioned tha= t users will be provided with notifications, requests for permissions and o= ptions for payment. Potential IETF Work Items When such dataflow graphs are activated, it is envisioned that computer net= working protocols will be utilized to notify remote components or services = of proper data routings, e.g. daisy-chain or pipeline configurations, in a = secure manner. That is, there may be new protocols and computer networking topics with reg= ard to implementing the APIs for interconnecting WebRTC peers with speech r= ecognition, translation and speech synthesis components and services. Conclusion Tight WebRTC integration is important for envisioned efficient, low-latency= , high-performance, scalable real-time translation scenarios. While there exist some ad hoc approaches to providing real-time translation= with WebRTC, standardizing new APIs and protocols can convenience develope= rs, convenience end users, and create new markets with respect to real-time= translation scenarios. Thank you for considering adding real-time translation to the use cases for= a next version of WebRTC. I look forward to any discussion on these topics= . References [1] http://www.cs.cmu.edu/~ianlane/hydra/ [2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY [3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg [4] https://arxiv.org/abs/1412.5567 [5] https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu= -accelerated-deep-learning/ [6] https://github.com/mozilla/DeepSpeech [7] https://open.library.ubc.ca/media/stream/pdf/24/1.0348751/3 [8] https://deepmind.com/blog/wavenet-generative-model-raw-audio/ [9] https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/ [10] https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just= -set-a-new-record-in-translation-and-why-it-matters/#205b9e5b3124 [11] https://store.systran.us/lp/storeSystran?Langue=3Den_US [12] https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applic= ations From: Bernard Aboba Sent: Thursday, September 27, 2018 12:58 AM Subject: Re: [rtcweb] WebRTC and Real-time Translation One of the key questions for "Next Version Use Cases" is what WebRTC-defici= encies are preventing these use cases from being satisfactorily implemented= today. For example, speech transcription cloud services have been implemented over= Websockets, where a snippet of speech is uploaded, and a transcription is = provided in reply. The latency is satisfactory for some uses cases. Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API. What seems to differentiate *next version* scenarios are situations where t= he processing is best done on the device, in order to lower latency or enha= nce privacy. On-device processing brings in discussion of workers/worklets= , access to raw audio/video, etc. However, so far I'm not aware of on-devi= ce implementations of transcription or translation. On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski > wrote: IETF RTCWEB Working Group, Greetings. I opened an issue on WebRTC and Real-time Translation at the Git= Hub repository for WebRTC version next use cases (https://github.com/w3c/we= brtc-nv-use-cases/issues/2). Introduction Real-time translation is both an interesting and important use case for a n= ext version of WebRTC. Speech Recognition, Translation and Speech Synthesis Approaches to real-time speech-to-speech machine translation include those = which interconnect speech recognition, translation and speech synthesis com= ponents and services. In that regard, we can consider client-side, on-prem,= server-side, third-party and cloud-based components and services. In that = regard, we can also consider both free and priced components and services. We can envision post-text speech technology and machine translation compone= nts and services. Speech recognition need not output to text; we can consid= er speech-to-SSML. Machine translation need not input from nor output to te= xt; we can consider SSML-to-SSML machine translation. Components and servic= es may provide various options with respect to their input and output data = formats. Connecting Components and Services by Constructing Graphs We can consider APIs which facilitate the construction of graphs which repr= esent the flow of data between components and services. As these graphs are= constructed, users could be apprised of relevant notifications, requests f= or permissions and options for payments. As these constructed graphs are ac= tivated, a number of protocols could be utilized to interconnect the compon= ents and services which, together, provide users with real-time translation= . Hyperlinks WebRTC Translator Demo Real Time Translation in WebRTC Best regards, Adam Sobieski http://www.phoster.com/contents/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CY4PR0101MB3095CD494BF85133BBE9C51DC5EA0CY4PR0101MB3095_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

A New Transport Protocol?

The QUIC API [1] shows how to extend the WebRTC specificati= on to enable the use of a new transport protocol.

=93This specification extends the WebRTC specification [WEB= RTC] to enable the use of QUIC [QUIC-TRANSPORT] to exchange arbitrary data = with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. Since QUIC can be multiplexed on the same por= t as RTP, RTCP, DTLS, STUN and TURN, this specification is compatible with = all the functionality defined in [WEBRTC], including communication using au= dio/video media and SCTP data channels.=94

It could be that, for both real-time translation and video = processing scenarios utilizing combinations of local components and remote = services, that a new transport protocol or a new version of an existing transport protocol is needed. Such a transport = protocol could facilitate transmitting and routing certain streams (or copi= es of certain streams) outside of envelopes between two or more peers such = that such streams rejoin other streams in envelopes on remote peers.

With such a transport protocol, one could specify, prepare = and activate processing graphs for one or more audio, video or data streams. A processing graph could be such that a stream passes thr= ough speech recognition, translation and speech synthesis components or ser= vices between two or more peers. A processing graph could be such that a st= ream passes through a video processing component or service between two or more peers.

Hopefully, I=92ve indicated how tractable it is to add real= -time translation and video processing to a next version of WebRTC. I=92m c= onfident that we can solve any remaining technical details in the upcoming years.

What do you think about this approach, a solution including= a new transport protocol or version of a transport protocol to provide rea= l-time translation and real-time video processing utilizing interconnected local components and remote services?<= /span>

References

[1] https://w3c.github.io/webrt= c-quic/

 

 

Best regards,

Adam Sobieski

 

 

From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Adam Sobieski <adamsobieski@hotmail.com&g= t;
Sent: Wednesday, October 3, 2018 6:14:51 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation
 

RTP Media API

https://www.w3.org/TR/webrtc/#rtp-media-api

=93The RTP media API lets a web application send and receive MediaStre= amTracks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnection, result in signaling; when this signali= ng is forwarded to a remote peer, it causes corresponding tracks to be crea= ted on the remote side.=94

=93The actual encoding and transmission of MediaStreamTracks is manage= d through objects called RTCRtpSenders. Similarly, the reception and decoding of MediaStreamTracks is managed through objects= called RTCRtpReceivers. Each RTCRtpSender is associated with at most one t= rack, and each track to be received is associated with exactly one RTCRtpRe= ceiver.=94

Envisioned for real-time translation scenarios is that audi= o tracks =96 or copies of audio tracks =96 can be routed through one or mor= e local components and remote services such that resultant output can be either sent to a remote side or multicast to multi= ple other peers. In particular for scenarios which utilize remote services,= audio tracks to be translated may travel outside of the envelopes for othe= r tracks. Translated content should rejoin other tracks on the remote side for synchronized presentation or pr= ocessing.

Real-time audio-to-audio translation is one scenario. Anoth= er scenario is real-time audio-to-subtitles translation where the results o= f real-time translation are desired to arrive as a subtitles track. A third scenario is where translation results are de= sired to arrive as data, for example to appear on-screen per the formatting= and layout of a web application. The output from one or more interconnecte= d components and services which perform real-time translation could then include: (1) audio, (2) = ;subtitles, (3) data.

Use Case: Funny Hats

https://w3c.github.io/webrtc-nv-use-ca= ses/#funnyhats*

The capability of routing one or more tracks through one or= more local components and remote services also facilitates scenarios resem= bling those discussed in the use case: Funny Hats.

Differences include: (1) funny hats scenarios utilize video= tracks and (2) real-time translation scenarios, while possible to present = as singular services, may include a daisy-chaining or a pipelining of a number of local components or remote services: speech= recognition, translation and speech synthesis.

As with real-t= ime translation, we can envision free as well as priced video processing se= rvices.

 

 

Best regards,

Adam Sobieski

 

From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Adam Sobieski <adamsobieski@hotmail.com&g= t;
Sent: Thursday, September 27, 2018 8:50:02 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation
 

Bernard = Aboba,
Ted Hardie,

Client-side Transcription and Translation=

With respect to client-side speech recognition, transcripti= on, translation and speech synthesis scenarios, we can consider GPGPU appro= aches.

HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognitio= n engine that leverages modern GPU-based parallel computing architectures t= o realize accurate real-time recognition with extremely large models.=94 In 2012, Professor Ian Lane indicated that HYDR= A performs 20x faster than other approaches [3].

Deep Speech [4][5][6] is a deep-learning-based approach to = speech recognition which =93outperforms previously published results on the= widely studied Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93handles challenging noisy envir= onments better than widely used, state-of-the-art commercial speech systems= ...=94

Articulatory synthesis can be accelerated by graphics cards= [7].

WaveNet [8][9] is a deep generative model of raw audio wave= forms including speech audio.

Facebook AI Research recently advanced machine translation = [10], advancing performance metrics by 10 BLEU points.

With respect to desktop-based translation, vendors such as = SYSTRAN [11] offer desktop-based, server-based and cloud-based solutions.

There are some desktop-based transcription and machine tran= slation solutions [12] and it is expected that real-time client-side soluti= ons for transcription and translation, processing speech audio, will exist in the upcoming years, at least for desktop compu= ting if not mobile computing.

On-premises Transcription and Translation=

In addition to client-side solutions, on-premises solutions= can deliver lowered latency and enhanced privacy.

Server-side and Cloud-based Transcription and Translation

For a number of scenarios including mobile computing, serve= r-side and cloud-based transcription and translation services make sense.

Major software vendors such as Amazon, Facebook, Google, IB= M and Microsoft offer priced cloud-based services which include speech reco= gnition, machine translation and speech synthesis.

Post-text Speech Technology

I am an advocate of post-text speech technologies. Speech-t= o-text is too lossy. Information pertaining to prosody, intonation, emphase= s and pauses are discarded in text output. Such information can be useful, for example informing machine translation compo= nents and services. In addition to speech-to-SSML speech recognition and SS= ML-to-SSML machine translation scenarios, we can envision new, intermediate= data formats beyond SSML.

The inputs and outputs of speech recognition, translation a= nd speech synthesis components and services could be multiple formats =96 f= ormats other than text.

API Sketch: Dataflow Graphs

Sketches with respect to APIs include the declarative const= ruction of dataflow graphs which interconnect abstract components. Such API= s can abstract away whether the interconnectable components are client-side, on-prem, server-side, third-party or cloud-bas= ed. Such APIs can abstract away whether the interconnectable components are= for free or priced to end-users. Considerations to such API include the da= ta formats and stream specifications of components=92 various inputs and outputs to be interconnected.

Dataflow graphs can be an intuitive abstraction layer, one = which provides intuitive and convenient programming while interconnecting a= rbitrary numbers of components and services. Dataflow graphs can interconnect client-side and remote speech recognition= , translation and speech synthesis components as well as any other componen= ts which could reasonably be interconnected or pipelined.=

When such dataflow graphs are prepared for activation, it i= s envisioned that users will be provided with notifications, requests for p= ermissions and options for payment.

Potential IETF Work Items

When such dataflow graphs are activated, it is envisioned t= hat computer networking protocols will be utilized to notify remote compone= nts or services of proper data routings, e.g. daisy-chain or pipeline configurations, in a secure manner.

That is, there may be new protocols and computer networking= topics with regard to implementing the APIs for interconnecting WebRTC pee= rs with speech recognition, translation and speech synthesis components and services.

Conclusion

Tight WebRTC integration is important for envisioned effici= ent, low-latency, high-performance, scalable real-time translation scenario= s.

While there exist some ad hoc approaches to providing real-= time translation with WebRTC, standardizing new APIs and protocols can conv= enience developers, convenience end users, and create new markets with respect to real-time translation scenarios.

Thank you for considering adding real-time translation to t= he use cases for a next version of WebRTC. I look forward to any discussion= on these topics.

References

[1] = http://www.cs.cmu.edu/~ianlane/hydra/<= /a>
[2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY<= /a>
[3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg<= /a>
[4] https://arxiv.org/abs/1412.5567
[5] = https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu-acc= elerated-deep-learning/
[6] https://github.com/mozilla/DeepSpeech
[7] https://open.library.ubc.ca/media/strea= m/pdf/24/1.0348751/3
[8] https://deepmind.com/blog/wavenet-gen= erative-model-raw-audio/
[9] https://devblogs.nvidia.com/nv-wavenet= -gpu-speech-synthesis/
[10] https://www.forbes.com/sites/williamf= alcon/2018/09/01/facebook-ai-just-set-a-new-record-in-translation-and-why-i= t-matters/#205b9e5b3124
[11] https://store.systran.us/lp/storeSystran?L= angue=3Den_US
[12] https://en.wikipedia.= org/wiki/Comparison_of_machine_translation_applications

 

 

From: Bernard Aboba
Sent: Thursday, September 27, 2018 12:58 AM
Subject: Re: [rtcweb] WebRTC and Real-time Translation

 

One of the key questions for "Next Version Use = Cases" is what WebRTC-deficiencies are preventing these use cases from= being satisfactorily implemented today. 

 

For example, speech transcription cloud services hav= e been implemented over Websockets, where a snippet of speech is uploaded, = and a transcription is provided in reply.  The latency is satisfactory= for some uses cases. 

Improvements can perhaps be made by sending an audio= stream and receiving a transcription via the data channel, but this is als= o within the capabilities of the existing RTCWEB protocols and WebRTC-PC AP= I. 

 

What seems to differentiate *next version* scenarios= are situations where the processing is best done on the device, in order t= o lower latency or enhance privacy.  On-device processing brings in di= scussion of workers/worklets, access to raw audio/video, etc.  However, so far I'm not aware of on-device imp= lementations of transcription or translation.

 

On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> = wrote:

IETF RTCWEB Working Group,

 

Greetings. I opened an issue on WebRTC and Real-time Translation at the GitHub repository for WebRTC= version next use cases (https://github.com/w3c/webrtc-nv-use-cases/= issues/2).

 

Introdu= ction

Real-tim= e translation is both an interesting and important use case for a next vers= ion of WebRTC.

Speech = Recognition, Translation and Speech Synthesis

Approach= es to real-time speech-to-speech machine translation include those which in= terconnect speech recognition, translation and speech synthesis components and services. In that regard, we can consider = client-side, on-prem, server-side, third-party and cloud-based components a= nd services. In that regard, we can also consider both free and priced comp= onents and services.

We can e= nvision Connect= ing Components and Services by Constructing Graphs

We can c= onsider APIs which facilitate the construction of graphs which represent th= e flow of data between components and services. As these graphs are constructed, users could be apprised of relevant notif= ications, requests for permissions and options for payments. As these const= ructed graphs are activated, a number of protocols could be utilized to int= erconnect the components and services which, together, provide users with real-time translation.

Hyperli= nks

WebRTC Translator Demo
Real Time Translation in WebRTC

 

 

Best regards,

Adam Sobieski

htt= p://www.phoster.com/contents/

 

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

 

--_000_CY4PR0101MB3095CD494BF85133BBE9C51DC5EA0CY4PR0101MB3095_-- From nobody Thu Oct 4 11:50:27 2018 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 F3EBB12777C; Thu, 4 Oct 2018 11:50:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ted Hardie To: X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Ted Hardie , ted.ietf@gmail.com, iesg-secretary@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org Message-ID: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2018 11:50:24 -0700 Archived-At: Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-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, 04 Oct 2018 18:50:25 -0000 Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as Informational on behalf of the RTCWEB working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ From nobody Thu Oct 4 11:59:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334CA1277BB for ; Thu, 4 Oct 2018 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=c+Uvaj4I; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UX6u5TUT 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 oQGiwlMU0I8u for ; Thu, 4 Oct 2018 11:59:51 -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 9F4BD126BED for ; Thu, 4 Oct 2018 11:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538679587; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BaTDveqeOQmosZjbaBGalyzca+0Eb5mKJND8ex7d914=; b=c+Uvaj4IFmgyrsG3ithzYICy3zx+S+tdsyI4L8AlNreZ301P4O/rl+POYDMJPnJ3 /PgX6DdqfwOffiOSww/AytXWn6Gb9xu/ZYaelB0kVdaJpOBQelRh5gR4QlM+ZVDY KJA/Fi3uce/rBRAZFySu3kBfMVOcJhVCq1meeKDP2O8=; X-AuditID: c1b4fb30-ff9ff700000055da-0f-5bb66323bb88 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.FF.21978.32366BB5; Thu, 4 Oct 2018 20:59:47 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Oct 2018 20:59:47 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 4 Oct 2018 20:59:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BaTDveqeOQmosZjbaBGalyzca+0Eb5mKJND8ex7d914=; b=UX6u5TUTpkhAKeUlbuFJUPJSGxfZ9XHRZ4K0kEuIj4mTlcWLOA9BCxayzjTehKAODNMHpQ3v/aQjoQQNWB+7QiPKSZoYSoELDE+Chu0bC1viybH+xZOAySoRbiYb8hRoI5rnEmqDaKcBeXuTNBRxSUwnyjTANXUFPZEEbszZO0M= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB0798.eurprd07.prod.outlook.com (10.161.107.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Thu, 4 Oct 2018 18:59:46 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%5]) with mapi id 15.20.1207.018; Thu, 4 Oct 2018 18:59:46 +0000 From: Christer Holmberg To: Ted Hardie , "adam@nostrum.com" CC: "rtcweb@ietf.org" , "iesg-secretary@ietf.org" , "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 Thread-Index: AQHUXBMpmc/o3hnPw0aXMExXqquGUqUPcII3 Date: Thu, 4 Oct 2018 18:59:46 +0000 Message-ID: References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> In-Reply-To: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.33.60.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB0798; 6:JXDsPxdAAzZRNRR6EDTAYk9YGGoZCMgX6asqepKZMzVfa0nEyMwXlw+nUiCeeXBpQa5Ud4ownF2KOLdhHLWSC19drieZDEk8Rj2diBBX1X67aibwCMpD7qqhp9ZUtPT3iTUvXtGTS2qONmjkVuKNZqcH32XqabBMUm9xzhWBTHi9dBPE4LJJz0IrNlCw9pc9mT10hSn8eLSkppDFngPyPKf1rAe+PDE0FLhp/ZbYxGfXTt0urmuSMyBotvd17pHE/1GVP0sD/uFvjUHle0uZsYCXCj0h/tDsR0w5ZiZBD6ZMCXQDqhjEZrsWBjm/UxMpTiEfYIcXxTueYSCv5S4kjoi04gBMS2lHLIbki/EB9ySLObcAo6W15xXApAZef38crowjVNrQ0aJ7+zl80NzguZZJK9K/6FXs4J+F2fSCGgHHYNoxfehkMRKBbH1VeYVrMsQhwFp9hlpO8VHYSXpaLg==; 5:sgAd2jSEvWXZ/bSAY6xDa0XsuFM48BfSzHwf0Zc+VM5oTQk99JPGxinnub0iSjRKoTTSdfXqxCIVrhsGmxIVbtjNeNnSEhPcw19cImlAI7Xa68F96hg4wxRmRrxXV2y8UXvEqsn5RTM2NtQMPIrwOQeeMIzjRkaxp1VxaJtSkW8=; 7:5LUb2fBmfAcNINao8gkCkrvK8axUTcw1eXEfKK37SDYazpvVyC1kv8IoguQ36JAPV+s+8r2HDDEfrZh2wYhVWa9PJsyaBxvfsYVnv18YkhULfAnz3LTSRTfolBnpGKOIpvvDVg6KklKewnAOrwu1mH5AqKZh9iWlRnZ7GyXKxyBYn86z6CTnpeLeyBP++5zzTyMOSbjoaV0QKTk1LlFQIstA/VCHavQTn9luo7x2igjpAo6XQcHzySFiI8IvFdeB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: af9bbad0-00d4-4948-a575-08d62a2b8d56 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB0798; x-ms-traffictypediagnostic: VI1PR07MB0798: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991048); SRVR:VI1PR07MB0798; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0798; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(136003)(396003)(376002)(189003)(199004)(8676002)(4326008)(229853002)(81166006)(606006)(81156014)(66066001)(39060400002)(478600001)(19627405001)(8936002)(14454004)(33656002)(966005)(71200400001)(110136005)(71190400001)(54906003)(2906002)(5660300001)(74316002)(6346003)(236005)(2501003)(2900100001)(6246003)(14444005)(25786009)(99286004)(105586002)(26005)(68736007)(76176011)(7736002)(54896002)(6306002)(6506007)(55016002)(256004)(186003)(1015004)(7696005)(44832011)(486006)(53546011)(476003)(5250100002)(102836004)(6116002)(11346002)(3846002)(316002)(53936002)(86362001)(446003)(97736004)(106356001)(6436002)(6606003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0798; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-microsoft-antispam-message-info: Q6dhFwJjFCMU/FEF3gHCZZbnHnryeCb0MMVbg4+x6NVTXiY1JqGNYcqU4lExgJeHdkdtNxAe7RBm/GDDIwUU8wWSIT/ZYTBxPC1hoGVLOjjActmL4U0GduEzdR5/KDGpHmj4WVA2XXSixAdgG3MimlcyMMgXrGXgoM5meleZszQy7NAC3UVuL7v2wFNqXYkmmcO3fXeOJkBvumROAHHpQZEIjbkKjgfD9Z6aoHKO/WNrKMcMBtdPG13vwd0dKGBdx6Vl6WcFhgCh0WnRJ/OVf8xUF/tk8hJRJC4RhVsqonJPwx64dgBvjd5FoyV1l2VaZtnZ3UKJcJUOCKNOf7F7grd0SdLL0M5pzYewxQ+kESU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47828191ADEC3F41DF3369A393EA0VI1PR07MB4782eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: af9bbad0-00d4-4948-a575-08d62a2b8d56 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 18:59:46.2261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0798 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGObt323U4OS2Xf7QkZlEpzjmi9iFES0FNxUpDVLLpbirqtN0p GQlGH5SpaLlJvqWZzDSjmOZLii+DkvKDmCFqGE2NdGL0IROZWt7dBX45/M7zPP+XA4ciJG/5 3lS2Vk/rtOpcmUBE1if1M4F+GX0pCluZUjW82yZUVf8NU1VuzJGql3tlQtX95pBQfuRgw6Iw sr19mxfZMLhCxhPJogsaOje7iNYFhdwUZXU0bwkLNuR32iZHiFLkOGNAbhTgs2CZ6BEYkIiS 4HcI5uv/CFhDgjcRbBmCOeMZD8rNv/nshcQ1BPQ8cRCcU8uDnyNGV70NgX1iV2hAFCXAKqjY C2BbeeJosFpWnRkCP0RQXVHtnHEYX4PdqTEeF0qAdYcdcawEm6HcqZP4BAya1wiWxTgVtmem +Wx/CY6B+S9BLLrhWOg1RLAJhI/A1sduZyWBvWBhpYXHPRND+/AUwbEU1pb3+Bwfh/HuZZd+ DD61VCB2TcAjQnjz+RvijED4ZTK5QrGw/mKI4EITCOp6H7hC/vDVPOTqmgOVpk0Buxzgy/B+ p4STfaGrykZytaMEdLzq4NcgRcOBZTnOB+PknJPF+BB8qF8hOV0OcyajgOMAMD9dJzgOhMd7 VvKg3oqEXUjK0Ex6XqZSKad12RkMk6+Va2m9Be3/qPFeh2IArf0IsyJMIZm7OORGX4qEry5i ivOsCChC5inWqPel/bP4Lq3LT9MV5tKMFflQpMxLrIrrSZbgTLWezqHpAlr33+VRbt6lKHws frNuoM7rUliCdDepYGCpM5wsJ+5Jz2/3V/kp0rpP0ov2U9Np36PcLUp9SNOqsDH9tlEjqdLv 2OxHCz0WVHGdvpO22SuNNVuttsTpxeCl+rm0ixFaqc+I9qpmxl3tEbCufJ56+rVCGVra1DQq vjX7KKa25HpidFTFOQdhkpFMljrYn9Ax6n8Zq7kiTQMAAA== Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Oct 2018 18:59:53 -0000 --_000_VI1PR07MB47828191ADEC3F41DF3369A393EA0VI1PR07MB4782eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Assuming we are going to do the ICE reference update, this draft is affecte= d too. Regards, Christer ________________________________ From: rtcweb on behalf of Ted Hardie Sent: Thursday, October 4, 2018 9:50 PM To: adam@nostrum.com Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-= 10 Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as Informa= tional on behalf of the RTCWEB working group. Please verify the document's state at https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-sdp/ draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC datatracker.ietf.org Annotated Example SDP for WebRTC (Internet-Draft, 2018) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_VI1PR07MB47828191ADEC3F41DF3369A393EA0VI1PR07MB4782eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


Assuming we are going to do the I= CE reference update, this draft is affected too.


Regards,


Christer




From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Ted Hardie <ted.ietf@gmail.com>
Sent: Thursday, October 4, 2018 9:50 PM
To: adam@nostrum.com
Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org=
Subject: [rtcweb] Publication has been requested for draft-ietf-rtcw= eb-sdp-10
 
Ted Hardie has requested publication of draft-ietf= -rtcweb-sdp-10 as Informational on behalf of the RTCWEB working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/
datatracker.ietf.org
Annotated Example SDP for WebRTC (Internet-Draft, 2018)



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman= /listinfo/rtcweb
--_000_VI1PR07MB47828191ADEC3F41DF3369A393EA0VI1PR07MB4782eurp_-- From nobody Thu Oct 4 15:43:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C624B126DBF for ; Thu, 4 Oct 2018 15:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=unavailable 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 yrzuZKdwpK4b for ; Thu, 4 Oct 2018 15:43:43 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 67624130E9D for ; Thu, 4 Oct 2018 15:43:40 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id b4-v6so3809996qtc.7 for ; Thu, 04 Oct 2018 15:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QiabyKiBp2miXNECvFTW2dZBbkOpVdm6JgELFgkf2dQ=; b=UkpCD35Gh2XXcYT3aVhofkT/izq25h5oUA6f+9uiGIYW8TDWVSU9W72+xopshZqcfO kD97jevQga9Qe193a1F47+PW8KqZbJpCt7nfwnXpfCOqa1rxfcvMwaW2I0bIkqQ0cD6p JYgZqI4cIBad7/kOaG2fNjI8Wn41DDduqDQsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QiabyKiBp2miXNECvFTW2dZBbkOpVdm6JgELFgkf2dQ=; b=VagBLiihXiIgm5E06navWsGvnBmFL6Ml4BzORipF49M2svm+yKq3n/47z/PpOuKTzf yfE4xvwtF/qkC87i8cPV12+5xlvPr1Id24lO5hDQyjuBKB2cmZL3G7pnJxjMv9WpgDGN qBY7z4yJmXu8/a8OEAanHltPqwY+fH/3ukqUCwk/LKfs3+Q+YkD5Hy8ZXn0y2qpGoDhm cdVIILP7hQCOE3mN8TapZtEN2pqXUlG1Wa6cJgfoTRO0PXrRUuNqED2MZys4Qgrhvtps Tg0Tzxh9nKFxLEAiTaETWV+TyoslCNr/kfsnXeyKUmPWjZm0d00g+B3bfSQgOiI4f54Y nNjw== X-Gm-Message-State: ABuFfoiiY8VowgjPdagrHPUzj61BGbp46ud7fhjI7HDfuIJk2tgT8fnI 4p98Pp+fTc2Q/27KJZG8yFot9A== X-Google-Smtp-Source: ACcGV61enswg46mH2Dg1SZJ8Bv7SSIdSKs6SLi18ofLCNxPr/XV6d9KvYwWzfKlyLYwFXOObLkOxgg== X-Received: by 2002:aed:2722:: with SMTP id n31-v6mr7415766qtd.304.1538693019547; Thu, 04 Oct 2018 15:43:39 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id b128-v6sm3057285qkc.21.2018.10.04.15.43.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 15:43:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 4 Oct 2018 18:43:36 -0400 Cc: Ted Hardie , Adam Roach , "rtcweb@ietf.org" , IESG Secretary , "rtcweb-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Oct 2018 22:43:45 -0000 Yes and whole lot more drafts: https://www.rfc-editor.org/cluster_info.php?cid=3DC238 spt > On Oct 4, 2018, at 14:59, Christer Holmberg = wrote: >=20 > Hi, >=20 > Assuming we are going to do the ICE reference update, this draft is = affected too. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > From: rtcweb on behalf of Ted Hardie = > Sent: Thursday, October 4, 2018 9:50 PM > To: adam@nostrum.com > Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > Subject: [rtcweb] Publication has been requested for = draft-ietf-rtcweb-sdp-10 > =20 > Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as = Informational on behalf of the RTCWEB working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC > datatracker.ietf.org > Annotated Example SDP for WebRTC (Internet-Draft, 2018) >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 4 16:29:30 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4D130DC4 for ; Thu, 4 Oct 2018 16:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 serwh9fN_nS0 for ; Thu, 4 Oct 2018 16:29:20 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 52F27129385 for ; Thu, 4 Oct 2018 16:29:20 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id p64-v6so373410itp.0 for ; Thu, 04 Oct 2018 16:29:20 -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=pS1pdY6gMLhWJKsGmVVUo2PHaXcckqixEh6DtdiBIMg=; b=UiU7G65LmMmhKk49RwwqKbV6NXGl47gl4yU4Km8KAjLu907rf7LI3cGBdA7gVhvWWV 26r4O7ddu9XtY6bPiAeOtEyXqwbNoQVl4/YLqrzun+waoqDL+wAPBgoR5NzK3vWYk2qt h9J2lOxoWuXhmfby59Eu2MD/tkRXsaV1m93nswtiYQgAMCGYmrpNoplJBZiHq+Ok8+uR qAVM9Ppm6ZlUU7RW3z1OIb2il7kqu52dlvHqt5eHIv0X564rUt2vm1s48iQgarxMSTr8 ZQPbjuKPkv5jHsXrzkhAz1eoCBYRH27VY4Q4fXEeZ+SjI4zxsMphpHPyRC147R7cBW5U ruhw== 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=pS1pdY6gMLhWJKsGmVVUo2PHaXcckqixEh6DtdiBIMg=; b=apZtLSIsRG8RN+qLklUzyIq8AtXpVg7NacZQlPaCTPVuU2QpxeS1HDyy5HY6JYcPlA 09g94uh5CRcOPj1LC9LQAN7Hsp5u+I5KdFBIE9m32fYiVOkijSgHbyWCmVD+P1y6waRE TZLUfiBnZgrYIw/h1+IAdFJ8wi+h/l2WCgrBqFFdUdgsYNJERvmQUB+6ktzKnbhCnscl MhIEBZzoVHX2T6I4eUWjl1Ll7s5E5JPi4PP6caB7S6OuS7FvFvfgd0RpWCtLZ8sjq3PQ exkPPKDjYgfzJGNVpvvhnWjBiu7Be37TYRvzJf2y9be7Bc5KkHWEZDIo6Q0xk+cmRAjI LO5Q== X-Gm-Message-State: ABuFfohyyg0ivFWSnI0sPmJi5nffW7bcgGAg/QfTY3ik4vyb/tgWFlJR 33MOjISZ5ShfXtl2tgMv1Sgv8ALqWYAwnxN8RA7IoA== X-Google-Smtp-Source: ACcGV63FK0rYuHIHJ/cSKol3ib63/ygaOcrIJVNX8VRFezW6s8BQPE3sMBygt3pzlU2XP2l5XY0tkuUxuE/f0WjpHiw= X-Received: by 2002:a24:d1c5:: with SMTP id w188-v6mr5990252itg.99.1538695758940; Thu, 04 Oct 2018 16:29:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 4 Oct 2018 16:29:06 -0700 Message-ID: To: adamsobieski@hotmail.com Cc: Bernard Aboba , Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000219aaa05776f863c" Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Oct 2018 23:29:29 -0000 --000000000000219aaa05776f863c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think much of what you mention will be possible with the new APIs discussed in https://w3c.github.io/webrtc-nv-use-cases/ (and probably can already be done to some extent with Web Audio). However, I'm not sure that a new transport is needed for this particular use case - it seems mostly satisfied by on-device processing capabilities. On Thu, Oct 4, 2018 at 10:25 AM Adam Sobieski wrote: > A New Transport Protocol? > > The QUIC API [1] shows how to extend the WebRTC specification to enable > the use of a new transport protocol. > > =E2=80=9CThis specification extends the WebRTC specification [WEBRTC] to = enable > the use of QUIC [QUIC-TRANSPORT] to exchange arbitrary data with remote > peers using NAT-traversal technologies such as ICE, STUN, and TURN. Since > QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TUR= N, > this specification is compatible with all the functionality defined in > [WEBRTC], including communication using audio/video media and SCTP data > channels.=E2=80=9D > > It could be that, for both real-time translation and video processing > scenarios utilizing combinations of local components and remote services, > that a new transport protocol or a new version of an existing transport > protocol is needed. Such a transport protocol could facilitate transmitti= ng > and routing certain streams (or copies of certain streams) outside of > envelopes between two or more peers such that such streams rejoin other > streams in envelopes on remote peers. > > With such a transport protocol, one could specify, prepare and activate *= processing > graphs* for one or more audio, video or data streams. A processing graph > could be such that a stream passes through speech recognition, translatio= n > and speech synthesis components or services between two or more peers. A > processing graph could be such that a stream passes through a video > processing component or service between two or more peers. > > Hopefully, I=E2=80=99ve indicated how tractable it is to add real-time tr= anslation > and video processing to a next version of WebRTC. I=E2=80=99m confident t= hat we can > solve any remaining technical details in the upcoming years. > > What do you think about this approach, a solution including a new > transport protocol or version of a transport protocol to provide real-tim= e > translation and real-time video processing utilizing interconnected local > components and remote services? > References > > [1] https://w3c.github.io/webrtc-quic/ > > > > > > Best regards, > > Adam Sobieski > > > > > ------------------------------ > *From:* rtcweb on behalf of Adam Sobieski < > adamsobieski@hotmail.com> > *Sent:* Wednesday, October 3, 2018 6:14:51 PM > *To:* Bernard Aboba; ted.ietf@gmail.com > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] WebRTC and Real-time Translation > > RTP Media API > > https://www.w3.org/TR/webrtc/#rtp-media-api > > =E2=80=9CThe RTP media API lets a web application send and receive > MediaStreamTracks over a peer-to-peer connection. Tracks, when added to a= n > RTCPeerConnection, result in signaling; when this signaling is forwarded = to > a remote peer, it causes corresponding tracks to be created on the remote > side.=E2=80=9D > > =E2=80=9CThe actual encoding and transmission of MediaStreamTracks is man= aged > through objects called RTCRtpSenders. Similarly, the reception and decodi= ng > of MediaStreamTracks is managed through objects called RTCRtpReceivers. > Each RTCRtpSender is associated with at most one track, and each track to > be received is associated with exactly one RTCRtpReceiver.=E2=80=9D > > Envisioned for real-time translation scenarios is that audio tracks =E2= =80=93 or > copies of audio tracks =E2=80=93 can be routed through one or more local = components > and remote services such that resultant output can be either sent to a > remote side or multicast to multiple other peers. In particular for > scenarios which utilize remote services, audio tracks to be translated ma= y > travel outside of the envelopes for other tracks. Translated content shou= ld > rejoin other tracks on the remote side for synchronized presentation or > processing. > > Real-time audio-to-audio translation is one scenario. Another scenario is > real-time audio-to-subtitles translation where the results of real-time > translation are desired to arrive as a subtitles track. A third scenario = is > where translation results are desired to arrive as data, for example to > appear on-screen per the formatting and layout of a web application. The > output from one or more interconnected components and services which > perform real-time translation could then include: (1) audio, (2) subtitle= s, > (3) data. > Use Case: Funny Hats > > https://w3c.github.io/webrtc-nv-use-cases/#funnyhats* > > The capability of routing one or more tracks through one or more local > components and remote services also facilitates scenarios resembling thos= e > discussed in the use case: Funny Hats. > > Differences include: (1) funny hats scenarios utilize video tracks and (2= ) > real-time translation scenarios, while possible to present as singular > services, may include a daisy-chaining or a pipelining of a number of loc= al > components or remote services: speech recognition, translation and speech > synthesis. > > As with real-time translation, we can envision free as well as priced > video processing services. > > > > > > Best regards, > > Adam Sobieski > > > ------------------------------ > *From:* rtcweb on behalf of Adam Sobieski < > adamsobieski@hotmail.com> > *Sent:* Thursday, September 27, 2018 8:50:02 PM > *To:* Bernard Aboba; ted.ietf@gmail.com > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] WebRTC and Real-time Translation > > > Bernard Aboba, > Ted Hardie, > Client-side Transcription and Translation > > With respect to client-side speech recognition, transcription, translatio= n > and speech synthesis scenarios, we can consider GPGPU approaches. > > HYDRA [1][2] is a =E2=80=9Chybrid GPU/CPU-based speech recognition engine= that > leverages modern GPU-based parallel computing architectures to realize > accurate real-time recognition with extremely large models.=E2=80=9D In 2= 012, > Professor Ian Lane indicated that HYDRA performs 20x faster than other > approaches [3]. > > Deep Speech [4][5][6] is a deep-learning-based approach to speech > recognition which =E2=80=9Coutperforms previously published results on th= e widely > studied Switchboard Hub5'00, achieving 16.0% error on the full test set= =E2=80=9D > and =E2=80=9Chandles challenging noisy environments better than widely us= ed, > state-of-the-art commercial speech systems....=E2=80=9D > > Articulatory synthesis can be accelerated by graphics cards [7]. > > WaveNet [8][9] is a deep generative model of raw audio waveforms includin= g > speech audio. > > Facebook AI Research recently advanced machine translation [10], advancin= g > performance metrics by 10 BLEU points. > > With respect to desktop-based translation, vendors such as SYSTRAN [11] > offer desktop-based, server-based and cloud-based solutions. > > There are some desktop-based transcription and machine translation > solutions [12] and it is expected that real-time client-side solutions fo= r > transcription and translation, processing speech audio, will exist in the > upcoming years, at least for desktop computing if not mobile computing. > On-premises Transcription and Translation > > In addition to client-side solutions, on-premises solutions can deliver > lowered latency and enhanced privacy. > Server-side and Cloud-based Transcription and Translation > > For a number of scenarios including mobile computing, server-side and > cloud-based transcription and translation services make sense. > > Major software vendors such as Amazon, Facebook, Google, IBM and Microsof= t > offer priced cloud-based services which include speech recognition, machi= ne > translation and speech synthesis. > Post-text Speech Technology > > I am an advocate of post-text speech technologies. Speech-to-text is too > lossy. Information pertaining to prosody, intonation, emphases and pauses > are discarded in text output. Such information can be useful, for example > informing machine translation components and services. In addition to > speech-to-SSML speech recognition and SSML-to-SSML machine translation > scenarios, we can envision new, intermediate data formats beyond SSML. > > The inputs and outputs of speech recognition, translation and speech > synthesis components and services could be multiple formats =E2=80=93 for= mats other > than text. > API Sketch: Dataflow Graphs > > Sketches with respect to APIs include the declarative construction of > dataflow graphs which interconnect abstract components. Such APIs can > abstract away whether the interconnectable components are client-side, > on-prem, server-side, third-party or cloud-based. Such APIs can abstract > away whether the interconnectable components are for free or priced to > end-users. Considerations to such API include the data formats and stream > specifications of components=E2=80=99 various inputs and outputs to be > interconnected. > > Dataflow graphs can be an intuitive abstraction layer, one which provides > intuitive and convenient programming while interconnecting arbitrary > numbers of components and services. Dataflow graphs can interconnect > client-side and remote speech recognition, translation and speech synthes= is > components as well as any other components which could reasonably be > interconnected or pipelined. > > When such dataflow graphs are prepared for activation, it is envisioned > that users will be provided with notifications, requests for permissions > and options for payment. > Potential IETF Work Items > > When such dataflow graphs are activated, it is envisioned that computer > networking protocols will be utilized to notify remote components or > services of proper data routings, e.g. daisy-chain or pipeline > configurations, in a secure manner. > > That is, there may be new protocols and computer networking topics with > regard to implementing the APIs for interconnecting WebRTC peers with > speech recognition, translation and speech synthesis components and > services. > Conclusion > > Tight WebRTC integration is important for envisioned efficient, > low-latency, high-performance, scalable real-time translation scenarios. > > While there exist some ad hoc approaches to providing real-time > translation with WebRTC, standardizing new APIs and protocols can > convenience developers, convenience end users, and create new markets wit= h > respect to real-time translation scenarios. > > Thank you for considering adding real-time translation to the use cases > for a next version of WebRTC. I look forward to any discussion on these > topics. > References > > [1] http://www.cs.cmu.edu/~ianlane/hydra/ > [2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY > [3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg > [4] https://arxiv.org/abs/1412.5567 > [5] > https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu-a= ccelerated-deep-learning/ > [6] https://github.com/mozilla/DeepSpeech > [7] https://open.library.ubc.ca/media/stream/pdf/24/1.0348751/3 > [8] https://deepmind.com/blog/wavenet-generative-model-raw-audio/ > [9] https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/ > [10] > https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just-se= t-a-new-record-in-translation-and-why-it-matters/#205b9e5b3124 > [11] https://store.systran.us/lp/storeSystran?Langue=3Den_US > [12] > https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applicati= ons > > > > > > *From: *Bernard Aboba > *Sent: *Thursday, September 27, 2018 12:58 AM > *Subject: *Re: [rtcweb] WebRTC and Real-time Translation > > > > One of the key questions for "Next Version Use Cases" is what > WebRTC-deficiencies are preventing these use cases from being > satisfactorily implemented today. > > > > For example, speech transcription cloud services have been implemented > over Websockets, where a snippet of speech is uploaded, and a transcripti= on > is provided in reply. The latency is satisfactory for some uses cases. > > Improvements can perhaps be made by sending an audio stream and receiving > a transcription via the data channel, but this is also within the > capabilities of the existing RTCWEB protocols and WebRTC-PC API. > > > > What seems to differentiate *next version* scenarios are situations where > the processing is best done on the device, in order to lower latency or > enhance privacy. On-device processing brings in discussion of > workers/worklets, access to raw audio/video, etc. However, so far I'm no= t > aware of on-device implementations of transcription or translation. > > > > On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski > wrote: > > IETF RTCWEB Working Group, > > > > Greetings. I opened an issue on *WebRTC and Real-time Translation* at the > GitHub repository for WebRTC version next use cases ( > https://github.com/w3c/webrtc-nv-use-cases/issues/2). > > > Introduction > > Real-time translation is both an interesting and important use case for a > next version of WebRTC. > Speech Recognition, Translation and Speech Synthesis > > Approaches to real-time speech-to-speech machine translation include thos= e > which interconnect speech recognition, translation and speech synthesis > components and services. In that regard, we can consider client-side, > on-prem, server-side, third-party and cloud-based components and services= . > In that regard, we can also consider both free and priced components and > services. > > We can envision *post-text* speech technology and machine translation > components and services. Speech recognition need not output to text; we c= an > consider speech-to-SSML. Machine translation need not input from nor outp= ut > to text; we can consider SSML-to-SSML machine translation. Components and > services may provide various options with respect to their input and outp= ut > data formats. > Connecting Components and Services by Constructing Graphs > > We can consider APIs which facilitate the construction of graphs which > represent the flow of data between components and services. As these grap= hs > are constructed, users could be apprised of relevant notifications, > requests for permissions and options for payments. As these constructed > graphs are activated, a number of protocols could be utilized to > interconnect the components and services which, together, provide users > with real-time translation. > Hyperlinks > > WebRTC Translator Demo > Real Time Translation in WebRTC > > > > > > > Best regards, > > Adam Sobieski > > http://www.phoster.com/contents/ > > > > _______________________________________________ > 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 > --000000000000219aaa05776f863c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think much of what you mention will be = possible with the new APIs discussed in=C2=A0https://w3c.github.io/webrtc-nv-use-cases/ (an= d probably can already be done to some extent with Web Audio).

However, I'm not sure that a new transport is = needed for this particular use case - it seems mostly satisfied by on-devic= e processing capabilities.

On Thu, Oct 4, 2018 at 10:25 AM Adam Sobieski <adamsobieski@hotmail.com> wrote:

A New Transport Protocol?

The QUIC API [1] shows how to extend the WebRTC specificati= on to enable the use of a new transport protocol.

=E2=80=9CThis specification extends the WebRTC specificatio= n [WEBRTC] to enable the use of QUIC [QUIC-TRANSPORT] to exchange arbitrary= data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. Since QUIC can be multiplexed on the same por= t as RTP, RTCP, DTLS, STUN and TURN, this specification is compatible with = all the functionality defined in [WEBRTC], including communication using au= dio/video media and SCTP data channels.=E2=80=9D

It could be that, for both real-time translation and video = processing scenarios utilizing combinations of local components and remote = services, that a new transport protocol or a new version of an existing transport protocol is needed. Such a transport = protocol could facilitate transmitting and routing certain streams (or copi= es of certain streams) outside of envelopes between two or more peers such = that such streams rejoin other streams in envelopes on remote peers.

With such a transport protocol, one could specify, prepare = and activate=C2=A0processing graphs=C2=A0for one or more audio, video or data streams. A processing graph could be such that a stream passes thr= ough speech recognition, translation and speech synthesis components or ser= vices between two or more peers. A processing graph could be such that a st= ream passes through a video processing component or service between two or more peers.

Hopefully, I=E2=80=99ve indicated how tractable it is to ad= d real-time translation and video processing to a next version of WebRTC. I= =E2=80=99m confident that we can solve any remaining technical details in the upcoming years.

What do you think about this approach, a solution including= a new transport protocol or version of a transport protocol to provide rea= l-time translation and real-time video processing utilizing interconnected local components and remote services?

References

[1]=C2=A0https://w= 3c.github.io/webrtc-quic/

=C2=A0

=C2=A0

Best regards,

Adam Sobieski

=C2=A0

=C2=A0

From:= rtcweb <rt= cweb-bounces@ietf.org> on behalf of Adam Sobieski <adamsobieski@hotmail.com>
Sent: Wednesday, October 3, 2018 6:14:51 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation
=C2=A0

RTP Media API

https://www.w3.org/TR/webrtc/#= rtp-media-api

=E2=80=9CThe RTP media API lets a web application send and receive Med= iaStreamTracks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnection, result in signaling; when this signali= ng is forwarded to a remote peer, it causes corresponding tracks to be crea= ted on the remote side.=E2=80=9D

=E2=80=9CThe actual encoding and transmission of MediaStreamTracks is = managed through objects called RTCRtpSenders. Similarly, the reception and decoding of MediaStreamTracks is managed through objects= called RTCRtpReceivers. Each RTCRtpSender is associated with at most one t= rack, and each track to be received is associated with exactly one RTCRtpRe= ceiver.=E2=80=9D

Envisioned for real-time translation scenarios is that audi= o tracks =E2=80=93 or copies of audio tracks =E2=80=93 can be routed throug= h one or more local components and remote services such that resultant output can be either sent to a remote side or multicast to multi= ple other peers. In particular for scenarios which utilize remote services,= audio tracks to be translated may travel outside of the envelopes for othe= r tracks. Translated content should rejoin other tracks on the remote side for synchronized presentation or pr= ocessing.

Real-time audio-to-audio translation is one scenario. Anoth= er scenario is real-time audio-to-subtitles translation where the results o= f real-time translation are desired to arrive as a subtitles track. A third scenario is where translation results are de= sired to arrive as data, for example to appear on-screen per the formatting= and layout of a web application. The output from one or more interconnecte= d components and services which perform real-time translation could then include: (1)=C2=A0audio, (2)=C2= =A0subtitles, (3)=C2=A0data.

Use Case: Funny Hats

https://w3c.github.i= o/webrtc-nv-use-cases/#funnyhats*

The capability of routing one or more tracks through one or= more local components and remote services also facilitates scenarios resem= bling those discussed in the use case: Funny Hats.

Differences include: (1) funny hats scenarios utilize video= tracks and (2) real-time translation scenarios, while possible to present = as singular services, may include a daisy-chaining or a pipelining of a number of local components or remote services: speech= recognition, translation and speech synthesis.

As with real-t= ime translation, we can envision free as well as priced video processing se= rvices.

=C2=A0

=C2=A0

Best regards,

Adam Sobieski

=C2=A0

From:= rtcweb <rt= cweb-bounces@ietf.org> on behalf of Adam Sobieski <adamsobieski@hotmail.com>
Sent: Thursday, September 27, 2018 8:50:02 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation
=C2=A0

Bernard = Aboba,
Ted Hardie,

Client-side Transcription and Translation

With respect to client-side speech recognition, transcripti= on, translation and speech synthesis scenarios, we can consider GPGPU appro= aches.

HYDRA [1][2] is a =E2=80=9Chybrid GPU/CPU-based speech reco= gnition engine that leverages modern GPU-based parallel computing architect= ures to realize accurate real-time recognition with extremely large models.=E2=80=9D In 2012, Professor Ian Lane indicated tha= t HYDRA performs 20x faster than other approaches [3].=

Deep Speech [4][5][6] is a deep-learning-based approach to = speech recognition which =E2=80=9Coutperforms previously published results = on the widely studied Switchboard Hub5'00, achieving 16.0% error on the full test set=E2=80=9D and =E2=80=9Chandles challenging= noisy environments better than widely used, state-of-the-art commercial sp= eech systems....=E2=80=9D

Articulatory synthesis can be accelerated by graphics cards= [7].

WaveNet [8][9] is a deep generative model of raw audio wave= forms including speech audio.

Facebook AI Research recently advanced machine translation = [10], advancing performance metrics by 10 BLEU points.=

With respect to desktop-based translation, vendors such as = SYSTRAN [11] offer desktop-based, server-based and cloud-based solutions.

There are some desktop-based transcription and machine tran= slation solutions [12] and it is expected that real-time client-side soluti= ons for transcription and translation, processing speech audio, will exist in the upcoming years, at least for desktop compu= ting if not mobile computing.

On-premises Transcription and Translation

In addition to client-side solutions, on-premises solutions= can deliver lowered latency and enhanced privacy.

Server-side and Cloud-based Transcription and Translation

For a number of scenarios including mobile computing, serve= r-side and cloud-based transcription and translation services make sense.

Major software vendors such as Amazon, Facebook, Google, IB= M and Microsoft offer priced cloud-based services which include speech reco= gnition, machine translation and speech synthesis.

Post-text Speech Technology

I am an advocate of post-text speech technologies. Speech-t= o-text is too lossy. Information pertaining to prosody, intonation, emphase= s and pauses are discarded in text output. Such information can be useful, for example informing machine translation compo= nents and services. In addition to speech-to-SSML speech recognition and SS= ML-to-SSML machine translation scenarios, we can envision new, intermediate= data formats beyond SSML.

The inputs and outputs of speech recognition, translation a= nd speech synthesis components and services could be multiple formats =E2= =80=93 formats other than text.

API Sketch: Dataflow Graphs

Sketches with respect to APIs include the declarative const= ruction of dataflow graphs which interconnect abstract components. Such API= s can abstract away whether the interconnectable components are client-side, on-prem, server-side, third-party or cloud-bas= ed. Such APIs can abstract away whether the interconnectable components are= for free or priced to end-users. Considerations to such API include the da= ta formats and stream specifications of components=E2=80=99 various inputs and outputs to be interconnected.=

Dataflow graphs can be an intuitive abstraction layer, one = which provides intuitive and convenient programming while interconnecting a= rbitrary numbers of components and services. Dataflow graphs can interconnect client-side and remote speech recognition= , translation and speech synthesis components as well as any other componen= ts which could reasonably be interconnected or pipelined.

When such dataflow graphs are prepared for activation, it i= s envisioned that users will be provided with notifications, requests for p= ermissions and options for payment.

Potential IETF Work Items

When such dataflow graphs are activated, it is envisioned t= hat computer networking protocols will be utilized to notify remote compone= nts or services of proper data routings, e.g. daisy-chain or pipeline configurations, in a secure manner.<= /span>

That is, there may be new protocols and computer networking= topics with regard to implementing the APIs for interconnecting WebRTC pee= rs with speech recognition, translation and speech synthesis components and services.

Conclusion

Tight WebRTC integration is important for envisioned effici= ent, low-latency, high-performance, scalable real-time translation scenario= s.

While there exist some ad hoc approaches to providing real-= time translation with WebRTC, standardizing new APIs and protocols can conv= enience developers, convenience end users, and create new markets with respect to real-time translation scenarios.=

Thank you for considering adding real-time translation to t= he use cases for a next version of WebRTC. I look forward to any discussion= on these topics.

References

[1]=C2=A0http://www.cs.cmu.edu/~ianl= ane/hydra/
[2]=C2=A0https://www.youtube.com/watch?v= =3D73rQ0lRx2aY
[3]=C2=A0https://www.youtube.com/watch?v= =3DY7Jlj7QYrcg
[4]=C2=A0https://arxiv.org/abs/1412.5567
[5]=C2=A0https://devblogs.nvidia.com/deep-speech-accurate-speech-= recognition-gpu-accelerated-deep-learning/
[6]=C2=A0https://github.com/mozilla/DeepSpeech
[7]=C2=A0https://open.library.= ubc.ca/media/stream/pdf/24/1.0348751/3
[8]=C2=A0https://deepmind.co= m/blog/wavenet-generative-model-raw-audio/
[9]=C2=A0https://devblogs.nvi= dia.com/nv-wavenet-gpu-speech-synthesis/
[10]=C2=A0https://www.forbes.= com/sites/williamfalcon/2018/09/01/facebook-ai-just-set-a-new-record-in-tra= nslation-and-why-it-matters/#205b9e5b3124
[11]=C2=A0https://store.systran.us= /lp/storeSystran?Langue=3Den_US
[12]=C2=A0htt= ps://en.wikipedia.org/wiki/Comparison_of_machine_translation_applications

=C2=A0

=C2=A0

From: Bernard Aboba Sent: Thursday, September 27, 2018 12:58 AM
Subject: Re: [rtcweb] WebRTC and Real-time Translation

=C2=A0

One of the key questions for "Next Version Use = Cases" is what WebRTC-deficiencies are preventing these use cases from= being satisfactorily implemented today.=C2=A0

=C2=A0

For example, speech transcription cloud services hav= e been implemented over Websockets, where a snippet of speech is uploaded, = and a transcription is provided in reply.=C2=A0 The latency is satisfactory= for some uses cases.=C2=A0

Improvements can perhaps be made by sending an audio= stream and receiving a transcription via the data channel, but this is als= o within the capabilities of the existing RTCWEB protocols and WebRTC-PC AP= I.=C2=A0

=C2=A0

What seems to differentiate *next version* scenarios= are situations where the processing is best done on the device, in order t= o lower latency or enhance privacy.=C2=A0 On-device processing brings in di= scussion of workers/worklets, access to raw audio/video, etc.=C2=A0 However, so far I'm not aware of on-device= implementations of transcription or translation.

=C2=A0

On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@ho= tmail.com> wrote:

IETF RTCWEB Working Group,

=C2=A0

Greetings. I opened an issue on WebRTC and Real-time Translation at the GitHub repository for WebRTC= version next use cases (https://github.com/w3c/webrtc-nv-use-cases/= issues/2).

=C2=A0

Introdu= ction

Real-tim= e translation is both an interesting and important use case for a next vers= ion of WebRTC.

Speech = Recognition, Translation and Speech Synthesis

Approach= es to real-time speech-to-speech machine translation include those which in= terconnect speech recognition, translation and speech synthesis components and services. In that regard, we can consider = client-side, on-prem, server-side, third-party and cloud-based components a= nd services. In that regard, we can also consider both free and priced comp= onents and services.

We can e= nvision=C2=A0Connect= ing Components and Services by Constructing Graphs

We can c= onsider APIs which facilitate the construction of graphs which represent th= e flow of data between components and services. As these graphs are constructed, users could be apprised of relevant notif= ications, requests for permissions and options for payments. As these const= ructed graphs are activated, a number of protocols could be utilized to int= erconnect the components and services which, together, provide users with real-time translation.

Hyperli= nks

WebRTC Translator Demo
Real Time Translation in WebRTC

=C2=A0

=C2=A0

Best regards,

Adam Sobieski

http://www.phoster.com/contents/

=C2=A0

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

=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000219aaa05776f863c-- From nobody Thu Oct 4 16:39:26 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3D130E9D for ; Thu, 4 Oct 2018 16:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=unavailable 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 ZhI29ZjpscFi for ; Thu, 4 Oct 2018 16:39:23 -0700 (PDT) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 72479130E85 for ; Thu, 4 Oct 2018 16:39:21 -0700 (PDT) Received: by mail-it1-x142.google.com with SMTP id q70-v6so358070itb.3 for ; Thu, 04 Oct 2018 16:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GSVVfDmLkH35lE8aL1lJzZRyl4UBnC5GJmSUiMZq1/s=; b=ErEcjb1DIvxjsR2xd1Y5OU53Sy1EhmlT4Rst4QV5lfhc+8E7JMvIo3Fs5WamzH07tl 933NcNYRuX3sRwacWm/JKnBJMhMSEbnoeulXwvczEUlpBc7GenqYSsQWSqQsXhJcical WCylo7lv2DD3tDxlWBpiyB/0qUy4TJyWuATJc= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GSVVfDmLkH35lE8aL1lJzZRyl4UBnC5GJmSUiMZq1/s=; b=Ts2w0mhvchZ8Wvyv+kuVHQGZp7IPFFFLxPzdXU7Hzi+DroeI05TSgKEkZ8giBdQbvD Ahnt4OcUVvpVY4UoDUnMHAwbXB4kOP8N1k5kCISHDPG65ODm2A4+eXBklQvhSUeOBeKH 0ZEbjDeWxi8RnzNxs4epwGDUkoBdibPMPiiQs2iH1q2s/DWX42sgU6fm2xmfxlrZMNM1 dMgHX265BfNv58tu363S+uV72+zCu2HCOzNtWNONwt4jm4uJFQr0zD0mS/mhFHI+ziOt 2P3/4RUxECs3S+jqN/QuJO6ssV2un4bRp0nswZ9owJj3yWPBx1awP3p+45UCXyyjNm8Z pwDA== X-Gm-Message-State: ABuFfojau9LRHQj2fwRqZzuCr+WO7djRR2mlXzWVV3k4AbRsyf6pAFJH qJS9YA1d8M6P8p2qouc+56P/4Q== X-Google-Smtp-Source: ACcGV61qNr3vllKQhXJcEflqrFemSWekrcCz1BGeoeZiXwxugMho0yjbeAK5hjfreALtBQ6t5LlYTw== X-Received: by 2002:a24:6b4d:: with SMTP id v74-v6mr6884638itc.26.1538696360789; Thu, 04 Oct 2018 16:39:20 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id q123-v6sm2028585iod.23.2018.10.04.16.39.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 16:39:19 -0700 (PDT) To: Sean Turner , Christer Holmberg Cc: "rtcweb@ietf.org" , IESG Secretary , "rtcweb-chairs@ietf.org" References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <8d98683e-3738-6726-dd1b-64f75f96d765@mozilla.com> Date: Thu, 4 Oct 2018 17:39:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Oct 2018 23:39:25 -0000 Has someone printed "Cluster 238" T-shirts yet? On 10/4/18 4:43 PM, Sean Turner wrote: > Yes and whole lot more drafts: > https://www.rfc-editor.org/cluster_info.php?cid=C238 > > spt > >> On Oct 4, 2018, at 14:59, Christer Holmberg wrote: >> >> Hi, >> >> Assuming we are going to do the ICE reference update, this draft is affected too. >> >> Regards, >> >> Christer >> >> >> >> From: rtcweb on behalf of Ted Hardie >> Sent: Thursday, October 4, 2018 9:50 PM >> To: adam@nostrum.com >> Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org >> Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 >> >> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as Informational on behalf of the RTCWEB working group. >> >> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ >> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC >> datatracker.ietf.org >> Annotated Example SDP for WebRTC (Internet-Draft, 2018) >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Oct 4 17:08:30 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77361129385; Thu, 4 Oct 2018 17:08:28 -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 S5gzkmFa0gP4; Thu, 4 Oct 2018 17:08:24 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 E783E126F72; Thu, 4 Oct 2018 17:08:23 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id v18-v6so6482289vsl.11; Thu, 04 Oct 2018 17:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hwUwrFsWSVHs3h4OpNPBis0FsoL5nCmLw0TgCbcjV8I=; b=ZmkugUSf8v05Ps2Di8RsLMqjXw/yH94z4aMYtg1UdFDi3kbSGexefh01Ef6NKX9Tg6 FAjpAfB6pkga939I2FF9aw3bzTKW/aIUMxd1hv4IwdeF5g7PZceBb8POJEwjAqObXX5I 7pgMbt99EwHY+RvcMSiCCBLtvExoFvUCb3qy48g7iXTAEaWOcr7tQ6E05QZ9Qan3861T GKeomOZA6IFdHnDM3qkc683wIOl78ErjfhjfsqK6rdziOKqETiaZ34U0kLjVIgDXnzk+ FPiLrbqxXeNWk5ZM9+rbEziiiGs3PHEJSSUYP4ompTEz+Ez3FSHzEXBXLU9hNf8ShnQ/ /Hkg== 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=hwUwrFsWSVHs3h4OpNPBis0FsoL5nCmLw0TgCbcjV8I=; b=PXbPlhP63jdu1zAmHxgTAWOE9tBFQKTVAERUyinmxlj205YVP5uC3cHmYEuS8KwJYZ bzlKmTHoeMEqkW+RDwRk+z7ajHaOuBepKDGrHGtPIWW0aEvxpoNALOfHVQabwFK078Og ZDo5QIlN/oX7zZU0BGONRDdCRAZM5i2UySPeNWtchpKIucoZAmjP3eyNXS9/td6lkMep 2KmtgTqZQZmHeJLU2bqniSwelC5YZqXBSr26rWjxmtaptF5kwqC+hBwGlfsg1szz16Gq Ac6H6r/Hj5DaCzkLbLdTJ4dfKD2wL9FXZAH1kAE+HAzWXx0FD7gQY264O3a4bSsWEeBI iYQg== X-Gm-Message-State: ABuFfoiSTnrRufEvwqyM+g1OKqqm2e0wR+Uc9+m7MhmcTuncWb5y8rkM GTld3kEMKqcTjx6QkbTjYRUaVSUw1OesRzOXEjc= X-Google-Smtp-Source: ACcGV60bpn8O19q9fRMoXe2M3FJ1ddTxNvpxmliTs8ZGo8hrmYHcmIJASUF0I3lvXRYD8+i61RCA3h5XCNokTpgi5UY= X-Received: by 2002:a67:6441:: with SMTP id y62-v6mr1924746vsb.156.1538698102913; Thu, 04 Oct 2018 17:08:22 -0700 (PDT) MIME-Version: 1.0 References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> <8d98683e-3738-6726-dd1b-64f75f96d765@mozilla.com> In-Reply-To: <8d98683e-3738-6726-dd1b-64f75f96d765@mozilla.com> From: Suhas Nandakumar Date: Thu, 4 Oct 2018 17:08:12 -0700 Message-ID: To: Peter Saint-Andre Cc: Christer Holmberg , IESG Secretary , Sean Turner , "rtcweb-chairs@ietf.org" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d73f0505777011ec" Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 05 Oct 2018 00:08:29 -0000 --000000000000d73f0505777011ec Content-Type: text/plain; charset="UTF-8" I would like that too :) On Thu, Oct 4, 2018 at 4:39 PM Peter Saint-Andre wrote: > Has someone printed "Cluster 238" T-shirts yet? > > On 10/4/18 4:43 PM, Sean Turner wrote: > > Yes and whole lot more drafts: > > https://www.rfc-editor.org/cluster_info.php?cid=C238 > > > > spt > > > >> On Oct 4, 2018, at 14:59, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> > >> Hi, > >> > >> Assuming we are going to do the ICE reference update, this draft is > affected too. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> From: rtcweb on behalf of Ted Hardie < > ted.ietf@gmail.com> > >> Sent: Thursday, October 4, 2018 9:50 PM > >> To: adam@nostrum.com > >> Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > >> Subject: [rtcweb] Publication has been requested for > draft-ietf-rtcweb-sdp-10 > >> > >> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as > Informational on behalf of the RTCWEB working group. > >> > >> Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > >> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC > >> datatracker.ietf.org > >> Annotated Example SDP for WebRTC (Internet-Draft, 2018) > >> > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000d73f0505777011ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like that too :)

On Thu, Oct 4, 2018 at 4:39 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
Has someone printed "Cluster 238"= T-shirts yet?

On 10/4/18 4:43 PM, Sean Turner wrote:
> Yes and whole lot more drafts:
> https://www.rfc-editor.org/cluster_info.p= hp?cid=3DC238
>
> spt
>
>> On Oct 4, 2018, at 14:59, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:
>>
>> Hi,
>>
>> Assuming we are going to do the ICE reference update, this draft i= s affected too.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Ted Hardie <ted.ietf@gmail.com= >
>> Sent: Thursday, October 4, 2018 9:50 PM
>> To: adam@nos= trum.com
>> Cc: rtcweb@ie= tf.org; ie= sg-secretary@ietf.org; rtcweb-chairs@ietf.org
>> Subject: [rtcweb] Publication has been requested for draft-ietf-rt= cweb-sdp-10
>>=C2=A0
>> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 a= s Informational on behalf of the RTCWEB working group.
>>
>> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/
>> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC
>> datatracker.ietf.org
>> Annotated Example SDP for WebRTC (Internet-Draft, 2018)
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000d73f0505777011ec-- From nobody Thu Oct 4 19:05:50 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257AC130DC7 for ; Thu, 4 Oct 2018 19:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 NnwGWM7GEv0l for ; Thu, 4 Oct 2018 19:05:46 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04lp0048.outbound.protection.outlook.com [216.32.181.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69581292F1 for ; Thu, 4 Oct 2018 19:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ldsLSx7RjtRye7NaDao85NnnWNtNvWwikJ+Z3YlvY2s=; b=Aebt2edNKYNkwoCX6BklWp2YFC5JPlBNK1S4x+ME14KTNx62RABlRdI5ln7JfjVYx41JhS5WhdygQYocamqWG76pjtAe/SOwjIgNeL0kjclxHfLf/cxfoBIBjpNbw02Ct1WhqJ5g26T78LdA6SZvIQkhEE+4nEv0AHbp3JDH7oeH/HX8TAPAwsjaokYTFFSrKO1+09J9yAB3p3T9YK92AiizNiXqFhByx1gUNDy7lop6/MAPtu/UdbOk+Q9ghtnmfumYcueCNgJiURQHzAzw1VzG4MT4Ms6LS57wHf9JSbAda/uDpMPDV65JUi7EWj52OyuiN0weOdNI8b4rVCDHTg== Received: from BN3NAM04FT026.eop-NAM04.prod.protection.outlook.com (10.152.92.56) by BN3NAM04HT214.eop-NAM04.prod.protection.outlook.com (10.152.93.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1207.19; Fri, 5 Oct 2018 02:05:43 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com (10.152.92.60) by BN3NAM04FT026.mail.protection.outlook.com (10.152.92.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1207.19 via Frontend Transport; Fri, 5 Oct 2018 02:05:43 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb]) by CY4PR0101MB3095.prod.exchangelabs.com ([fe80::7d65:cdc7:bca7:9cb%4]) with mapi id 15.20.1207.022; Fri, 5 Oct 2018 02:05:43 +0000 From: Adam Sobieski To: Justin Uberti CC: Bernard Aboba , Ted Hardie , RTCWeb IETF Thread-Topic: [rtcweb] WebRTC and Real-time Translation Thread-Index: AQHUVe1M2MPUNlozpUmfS3sPuCqXG6UDkYIAgAE+1yWACUt9KoABRHMwgABn8gCAABoKpQ== Date: Fri, 5 Oct 2018 02:05:42 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:AD9BEE701E5B771D195F988F4BA9B3D438C05E28AC156BBDE1DD8B4A962DAE9D; UpperCasedChecksum:69B2F346BE09087BE30E9277AD580D86798919186D8ABDCC91A5B14294B60CB7; SizeAsReceived:7578; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tOXdF5Yj7jd88bPDBAMxChsi7XxmDZ2G] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM04HT214; 6:zQMhqVVxy/q9weHnSKtHPvQ+tSITlrcBr8RO93td+Bpwu7bPLevTfp1DRC9XlRR1vEcy1+xYqqXBEfdh1Xx3ldH/1vQ4q5PC1/800OPoUY0t7IW/5R06+eV0DQDyHBDO6RRNsF0oqoHLzSb1OFhDUZ+mZjxshv1RmEHaAQmIYtLkQzegsxE2SG3l8wZy/4+cQVH/SHKAkPL1reLim/QWs2X4FzNYars+kD6+jcglUlC6azxPNZbGG6aiwuudjEn0fkc8kNbCE1Q/KQQizIu8KHjtBUoU8JwKDHRNLKeJBMU8YJwIbr7Z9mdnvYbf7Um4waZXstOydatii3hqT/JgZFRtatX5IA6kyO02n53es8tif1EecNWsERjXsgWu8CjFO+/hZd1entjKxx7XOYaRoorq5EixTBIfDn3pkAd8WPpFCZqlwIW2yx4T1TUueISLee/HxMJL6kvSEPfTTfdssw==; 5:zCIdH5eH4JT4G6H6KX0IoWLoYHMkwVKe413hqlYS9h6KSHspH459Oh5sTrkwuIZfr5rZU7XN2JMFrTXxDOYxeVKLmYMAunhNqKEowszCtLJfjeeuxRjad+dqqYk7Gd5QfBxJ4J+pN08O2R+zZNg/8KvKjSmew4cPm88MhvSWyZo=; 7:yhSeesb4BtgDhNrDM5RlByijUrRPpwsa84jZlJX9CnIgTlSGFwtpiBhjfgDyFDpHU9ujML4Lr8yAoYZGEOcp/r7HhvqDQ0n7rz4cTAgzHpkfGJ0jkt9o7AE50JmSO/RXKr2VtaFAFgXVMOdC1GBc43Rtc70p+60A8ADfAmTv1A6i23lqHzys0DUlbIVLybHNNDZm/GOdHmAaD75ZCGN120o5IPAaGZQLN2eInc1HJInpGU6KJ3vQHFRLbtKVWO9G x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:BN3NAM04HT214; x-ms-traffictypediagnostic: BN3NAM04HT214: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(102415395)(82015058); SRVR:BN3NAM04HT214; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM04HT214; x-microsoft-antispam-message-info: EmoHHn4P0iepBslSRdgrk3V07wbpoOygelF8FJ7JcQMpjMwxECBICPdp3C3dIajk Content-Type: multipart/related; boundary="_004_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: 3f17a01b-8a33-44b5-49ba-08d62a670e56 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2018 02:05:42.9725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT214 Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 05 Oct 2018 02:05:49 -0000 --_004_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_ Content-Type: multipart/alternative; boundary="_000_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_" --_000_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you. I will take a closer look at the WebRTC next version use cases d= ocument. While the Web Audio API does include a pro= cessing graph model, a key difference is that real-time translation and vid= eo processing are envisioned as requiring, at least for some users, the use= of and interconnection of remote services instead of only local components= . It could be that the latency difference between considered techniques: (1) = accessing remote services via websockets or data channels prior to sending = or after receiving, and (2) daisy-chain routing through services between pe= ers, is only a fraction of a second. In my opinion, we should add the use case of real-time translation to a nex= t version use cases document. I also think that it would be advantageous to= discuss use cases more often. I worry that the WebRTC use cases are only d= iscussed every seven or eight years. From: Justin Uberti Sent: Thursday, October 4, 2018 7:29 PM To: adamsobieski@hotmail.com Cc: Bernard Aboba; Ted Hardie; RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation I think much of what you mention will be possible with the new APIs discuss= ed in https://w3c.github.io/webrtc-nv-use-cases/ (and probably can already = be done to some extent with Web Audio). However, I'm not sure that a new transport is needed for this particular us= e case - it seems mostly satisfied by on-device processing capabilities. On Thu, Oct 4, 2018 at 10:25 AM Adam Sobieski > wrote: A New Transport Protocol? The QUIC API [1] shows how to extend the WebRTC specification to enable the= use of a new transport protocol. =93This specification extends the WebRTC specification [WEBRTC] to enable t= he use of QUIC [QUIC-TRANSPORT] to exchange arbitrary data with remote peer= s using NAT-traversal technologies such as ICE, STUN, and TURN. Since QUIC = can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, this= specification is compatible with all the functionality defined in [WEBRTC]= , including communication using audio/video media and SCTP data channels.= =94 It could be that, for both real-time translation and video processing scena= rios utilizing combinations of local components and remote services, that a= new transport protocol or a new version of an existing transport protocol = is needed. Such a transport protocol could facilitate transmitting and rout= ing certain streams (or copies of certain streams) outside of envelopes bet= ween two or more peers such that such streams rejoin other streams in envel= opes on remote peers. With such a transport protocol, one could specify, prepare and activate pro= cessing graphs for one or more audio, video or data streams. A processing g= raph could be such that a stream passes through speech recognition, transla= tion and speech synthesis components or services between two or more peers.= A processing graph could be such that a stream passes through a video proc= essing component or service between two or more peers. Hopefully, I=92ve indicated how tractable it is to add real-time translatio= n and video processing to a next version of WebRTC. I=92m confident that we= can solve any remaining technical details in the upcoming years. What do you think about this approach, a solution including a new transport= protocol or version of a transport protocol to provide real-time translati= on and real-time video processing utilizing interconnected local components= and remote services? References [1] https://w3c.github.io/webrtc-quic/ Best regards, Adam Sobieski From: rtcweb > on b= ehalf of Adam Sobieski > Sent: Wednesday, October 3, 2018 6:14:51 PM To: Bernard Aboba; ted.ietf@gmail.com Cc: RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation RTP Media API https://www.w3.org/TR/webrtc/#rtp-media-api =93The RTP media API lets a web application send and receive MediaStreamTra= cks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnect= ion, result in signaling; when this signaling is forwarded to a remote peer= , it causes corresponding tracks to be created on the remote side.=94 =93The actual encoding and transmission of MediaStreamTracks is managed thr= ough objects called RTCRtpSenders. Similarly, the reception and decoding of= MediaStreamTracks is managed through objects called RTCRtpReceivers. Each = RTCRtpSender is associated with at most one track, and each track to be rec= eived is associated with exactly one RTCRtpReceiver.=94 Envisioned for real-time translation scenarios is that audio tracks =96 or = copies of audio tracks =96 can be routed through one or more local componen= ts and remote services such that resultant output can be either sent to a r= emote side or multicast to multiple other peers. In particular for scenario= s which utilize remote services, audio tracks to be translated may travel o= utside of the envelopes for other tracks. Translated content should rejoin = other tracks on the remote side for synchronized presentation or processing= . Real-time audio-to-audio translation is one scenario. Another scenario is r= eal-time audio-to-subtitles translation where the results of real-time tran= slation are desired to arrive as a subtitles track. A third scenario is whe= re translation results are desired to arrive as data, for example to appear= on-screen per the formatting and layout of a web application. The output f= rom one or more interconnected components and services which perform real-t= ime translation could then include: (1) audio, (2) subtitles, (3) data. Use Case: Funny Hats https://w3c.github.io/webrtc-nv-use-cases/#funnyhats* The capability of routing one or more tracks through one or more local comp= onents and remote services also facilitates scenarios resembling those disc= ussed in the use case: Funny Hats. Differences include: (1) funny hats scenarios utilize video tracks and (2) = real-time translation scenarios, while possible to present as singular serv= ices, may include a daisy-chaining or a pipelining of a number of local com= ponents or remote services: speech recognition, translation and speech synt= hesis. As with real-time translation, we can envision free as well as priced video= processing services. Best regards, Adam Sobieski From: rtcweb > on b= ehalf of Adam Sobieski > Sent: Thursday, September 27, 2018 8:50:02 PM To: Bernard Aboba; ted.ietf@gmail.com Cc: RTCWeb IETF Subject: Re: [rtcweb] WebRTC and Real-time Translation Bernard Aboba, Ted Hardie, Client-side Transcription and Translation With respect to client-side speech recognition, transcription, translation = and speech synthesis scenarios, we can consider GPGPU approaches. HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognition engine that le= verages modern GPU-based parallel computing architectures to realize accura= te real-time recognition with extremely large models.=94 In 2012, Professor= Ian Lane indicated that HYDRA performs 20x faster than other approaches [3= ]. Deep Speech [4][5][6] is a deep-learning-based approach to speech recogniti= on which =93outperforms previously published results on the widely studied = Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93h= andles challenging noisy environments better than widely used, state-of-the= -art commercial speech systems....=94 Articulatory synthesis can be accelerated by graphics cards [7]. WaveNet [8][9] is a deep generative model of raw audio waveforms including = speech audio. Facebook AI Research recently advanced machine translation [10], advancing = performance metrics by 10 BLEU points. With respect to desktop-based translation, vendors such as SYSTRAN [11] off= er desktop-based, server-based and cloud-based solutions. There are some desktop-based transcription and machine translation solution= s [12] and it is expected that real-time client-side solutions for transcri= ption and translation, processing speech audio, will exist in the upcoming = years, at least for desktop computing if not mobile computing. On-premises Transcription and Translation In addition to client-side solutions, on-premises solutions can deliver low= ered latency and enhanced privacy. Server-side and Cloud-based Transcription and Translation For a number of scenarios including mobile computing, server-side and cloud= -based transcription and translation services make sense. Major software vendors such as Amazon, Facebook, Google, IBM and Microsoft = offer priced cloud-based services which include speech recognition, machine= translation and speech synthesis. Post-text Speech Technology I am an advocate of post-text speech technologies. Speech-to-text is too lo= ssy. Information pertaining to prosody, intonation, emphases and pauses are= discarded in text output. Such information can be useful, for example info= rming machine translation components and services. In addition to speech-to= -SSML speech recognition and SSML-to-SSML machine translation scenarios, we= can envision new, intermediate data formats beyond SSML. The inputs and outputs of speech recognition, translation and speech synthe= sis components and services could be multiple formats =96 formats other tha= n text. API Sketch: Dataflow Graphs Sketches with respect to APIs include the declarative construction of dataf= low graphs which interconnect abstract components. Such APIs can abstract a= way whether the interconnectable components are client-side, on-prem, serve= r-side, third-party or cloud-based. Such APIs can abstract away whether the= interconnectable components are for free or priced to end-users. Considera= tions to such API include the data formats and stream specifications of com= ponents=92 various inputs and outputs to be interconnected. Dataflow graphs can be an intuitive abstraction layer, one which provides i= ntuitive and convenient programming while interconnecting arbitrary numbers= of components and services. Dataflow graphs can interconnect client-side a= nd remote speech recognition, translation and speech synthesis components a= s well as any other components which could reasonably be interconnected or = pipelined. When such dataflow graphs are prepared for activation, it is envisioned tha= t users will be provided with notifications, requests for permissions and o= ptions for payment. Potential IETF Work Items When such dataflow graphs are activated, it is envisioned that computer net= working protocols will be utilized to notify remote components or services = of proper data routings, e.g. daisy-chain or pipeline configurations, in a = secure manner. That is, there may be new protocols and computer networking topics with reg= ard to implementing the APIs for interconnecting WebRTC peers with speech r= ecognition, translation and speech synthesis components and services. Conclusion Tight WebRTC integration is important for envisioned efficient, low-latency= , high-performance, scalable real-time translation scenarios. While there exist some ad hoc approaches to providing real-time translation= with WebRTC, standardizing new APIs and protocols can convenience develope= rs, convenience end users, and create new markets with respect to real-time= translation scenarios. Thank you for considering adding real-time translation to the use cases for= a next version of WebRTC. I look forward to any discussion on these topics= . References [1] http://www.cs.cmu.edu/~ianlane/hydra/ [2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY [3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg [4] https://arxiv.org/abs/1412.5567 [5] https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu= -accelerated-deep-learning/ [6] https://github.com/mozilla/DeepSpeech [7] https://open.library.ubc.ca/media/stream/pdf/24/1.0348751/3 [8] https://deepmind.com/blog/wavenet-generative-model-raw-audio/ [9] https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/ [10] https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just= -set-a-new-record-in-translation-and-why-it-matters/#205b9e5b3124 [11] https://store.systran.us/lp/storeSystran?Langue=3Den_US [12] https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applic= ations From: Bernard Aboba Sent: Thursday, September 27, 2018 12:58 AM Subject: Re: [rtcweb] WebRTC and Real-time Translation One of the key questions for "Next Version Use Cases" is what WebRTC-defici= encies are preventing these use cases from being satisfactorily implemented= today. For example, speech transcription cloud services have been implemented over= Websockets, where a snippet of speech is uploaded, and a transcription is = provided in reply. The latency is satisfactory for some uses cases. Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API. What seems to differentiate *next version* scenarios are situations where t= he processing is best done on the device, in order to lower latency or enha= nce privacy. On-device processing brings in discussion of workers/worklets= , access to raw audio/video, etc. However, so far I'm not aware of on-devi= ce implementations of transcription or translation. On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski > wrote: IETF RTCWEB Working Group, Greetings. I opened an issue on WebRTC and Real-time Translation at the Git= Hub repository for WebRTC version next use cases (https://github.com/w3c/we= brtc-nv-use-cases/issues/2). Introduction Real-time translation is both an interesting and important use case for a n= ext version of WebRTC. Speech Recognition, Translation and Speech Synthesis Approaches to real-time speech-to-speech machine translation include those = which interconnect speech recognition, translation and speech synthesis com= ponents and services. In that regard, we can consider client-side, on-prem,= server-side, third-party and cloud-based components and services. In that = regard, we can also consider both free and priced components and services. We can envision post-text speech technology and machine translation compone= nts and services. Speech recognition need not output to text; we can consid= er speech-to-SSML. Machine translation need not input from nor output to te= xt; we can consider SSML-to-SSML machine translation. Components and servic= es may provide various options with respect to their input and output data = formats. Connecting Components and Services by Constructing Graphs We can consider APIs which facilitate the construction of graphs which repr= esent the flow of data between components and services. As these graphs are= constructed, users could be apprised of relevant notifications, requests f= or permissions and options for payments. As these constructed graphs are ac= tivated, a number of protocols could be utilized to interconnect the compon= ents and services which, together, provide users with real-time translation= . Hyperlinks WebRTC Translator Demo Real Time Translation in WebRTC Best regards, Adam Sobieski http://www.phoster.com/contents/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank yo= u. I will take a closer look at the WebRTC next version use cases document.

While the = Web Audio API does include a = processing graph model, a key difference is that real-time translation and video processing are envisioned as requiring, at least for= some users, the use of and interconnection of remote services instead of o= nly local components.

It could be that the latency difference between considered = techniques: (1) accessing remote services via websockets or data channels p= rior to sending or after receiving, and (2) daisy-chain routing through services between peers, is only a fraction of = a second.

In my opinion,= we should add the use case of real-time translation to a next version use = cases document. I also think that it would be advantageous to discuss use cases more often. I worry that the WebRTC use = cases are only discussed every seven or eight years.

 

From: Justin Uberti
Sent: Thursday, October 4, 2018 7:29 PM
To: adamsobieski@hotmail= .com
Cc: Bernard Aboba; Ted Hardie; RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation

 

I think much of what you mention will be possible wi= th the new APIs discussed in https://w3c.github.io/webrtc-nv-use-cases/ (and probably = can already be done to some extent with Web Audio).

 

However, I'm not sure that a new transport is needed= for this particular use case - it seems mostly satisfied by on-device proc= essing capabilities.

 

On Thu, Oct 4, 2018 at 10:25 AM Adam Sobieski <adamsobieski@hotmail.com> = wrote:

A New T= ransport Protocol?

The QUIC= API [1] shows how to extend the WebRTC specification to enable the use of = a new transport protocol.

=93This specification extends the WebRTC specification [WEBRTC] to ena= ble the use of QUIC [QUIC-TRANSPORT] to exchange arbitrary data with remote peers using NAT-traversal technologies such as = ICE, STUN, and TURN. Since QUIC can be multiplexed on the same port as RTP,= RTCP, DTLS, STUN and TURN, this specification is compatible with all the f= unctionality defined in [WEBRTC], including communication using audio/video media and SCTP data channels.=94=

It could= be that, for both real-time translation and video processing scenarios uti= lizing combinations of local components and remote services, that a new transport protocol or a new version of an existing tr= ansport protocol is needed. Such a transport protocol could facilitate tran= smitting and routing certain streams (or copies of certain streams) outside= of envelopes between two or more peers such that such streams rejoin other streams in envelopes on remote p= eers.

With suc= h a transport protocol, one could specify, prepare and activate processing graphs for one or more audio, video or data streams. A pr= ocessing graph could be such that a stream passes through speech recognitio= n, translation and speech synthesis components or services between two or m= ore peers. A processing graph could be such that a stream passes through a video processing component or service = between two or more peers.

Hopefull= y, I=92ve indicated how tractable it is to add real-time translation and vi= deo processing to a next version of WebRTC. I=92m confident that we can solve any remaining technical details in the upcomin= g years.

What do = you think about this approach, a solution including a new transport protoco= l or version of a transport protocol to provide real-time translation and real-time video processing utilizing interconnec= ted local components and remote services?

Referen= ces

[1] https://w3c.github.io/webrtc-quic/

 

 

Best regards,

Adam Sobieski

 

 

From: rtcweb <rtcweb-bounces@ietf= .org> on behalf of Adam Sobieski <adamsobieski@hotmail.com> Sent: Wednesday, October 3, 2018 6:14:51 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation <= /o:p>

 

RTP Med= ia API

https://w= ww.w3.org/TR/webrtc/#rtp-media-api

=93The RTP media API lets a web application send and receive MediaStre= amTracks over a peer-to-peer connection. Tracks, when added to an RTCPeerConnection, result in signaling; when this signali= ng is forwarded to a remote peer, it causes corresponding tracks to be crea= ted on the remote side.=94

=93The actual encoding and transmission of MediaStreamTracks is manage= d through objects called RTCRtpSenders. Similarly, the reception and decoding of MediaStreamTracks is managed through objects= called RTCRtpReceivers. Each RTCRtpSender is associated with at most one t= rack, and each track to be received is associated with exactly one RTCRtpRe= ceiver.=94

Envision= ed for real-time translation scenarios is that audio tracks =96 or copies o= f audio tracks =96 can be routed through one or more local components and remote services such that resultant output can be eit= her sent to a remote side or multicast to multiple other peers. In particul= ar for scenarios which utilize remote services, audio tracks to be translat= ed may travel outside of the envelopes for other tracks. Translated content should rejoin other tracks on the rem= ote side for synchronized presentation or processing.

Real-tim= e audio-to-audio translation is one scenario. Another scenario is real-time= audio-to-subtitles translation where the results of real-time translation are desired to arrive as a subtitles track. A thi= rd scenario is where translation results are desired to arrive as data, for= example to appear on-screen per the formatting and layout of a web applica= tion. The output from one or more interconnected components and services which perform real-time translation= could then include: (1) audio, (2) subtitles, (3) data.

Use Cas= e: Funny Hats

https://w3c.github.io/webrtc-nv-use-cases/#funnyhats*

The capa= bility of routing one or more tracks through one or more local components a= nd remote services also facilitates scenarios resembling those discussed in the use case: Funny Hats.

Differen= ces include: (1) funny hats scenarios utilize video tracks and (2) real-tim= e translation scenarios, while possible to present as singular services, may include a daisy-chaining or a pipelining of a nu= mber of local components or remote services: speech recognition, translatio= n and speech synthesis.

As with real-t= ime translation, we can envision free as well as priced video processing se= rvices.

 

 

Best regards,

Adam Sobieski

 

From: rtcweb <rtcweb-bounces@ietf= .org> on behalf of Adam Sobieski <adamsobieski@hotmail.com> Sent: Thursday, September 27, 2018 8:50:02 PM
To: Bernard Aboba; ted.ietf@gmail.com
Cc: RTCWeb IETF
Subject: Re: [rtcweb] WebRTC and Real-time Translation <= /o:p>

 

Bernard = Aboba,
Ted Hardie,

Client-= side Transcription and Translation

With res= pect to client-side speech recognition, transcription, translation and spee= ch synthesis scenarios, we can consider GPGPU approaches.

HYDRA [1= ][2] is a =93hybrid GPU/CPU-based speech recognition engine that leverages = modern GPU-based parallel computing architectures to realize accurate real-time recognition with extremely large models.=94 = In 2012, Professor Ian Lane indicated that HYDRA performs 20x faster than o= ther approaches [3].

Deep Spe= ech [4][5][6] is a deep-learning-based approach to speech recognition which= =93outperforms previously published results on the widely studied Switchboard Hub5'00, achieving 16.0% error on the full = test set=94 and =93handles challenging noisy environments better than widel= y used, state-of-the-art commercial speech systems....=94

Articula= tory synthesis can be accelerated by graphics cards [7].

WaveNet = [8][9] is a deep generative model of raw audio waveforms including speech a= udio.

Facebook= AI Research recently advanced machine translation [10], advancing performa= nce metrics by 10 BLEU points.

With res= pect to desktop-based translation, vendors such as SYSTRAN [11] offer deskt= op-based, server-based and cloud-based solutions.

There ar= e some desktop-based transcription and machine translation solutions [12] a= nd it is expected that real-time client-side solutions for transcription and translation, processing speech audio, will exist in = the upcoming years, at least for desktop computing if not mobile computing.=

On-prem= ises Transcription and Translation

In addit= ion to client-side solutions, on-premises solutions can deliver lowered lat= ency and enhanced privacy.

Server-= side and Cloud-based Transcription and Translation

For a nu= mber of scenarios including mobile computing, server-side and cloud-based t= ranscription and translation services make sense.

Major so= ftware vendors such as Amazon, Facebook, Google, IBM and Microsoft offer pr= iced cloud-based services which include speech recognition, machine translation and speech synthesis.

Post-te= xt Speech Technology

I am an = advocate of post-text speech technologies. Speech-to-text is too lossy. Inf= ormation pertaining to prosody, intonation, emphases and pauses are discarded in text output. Such information can be useful, f= or example informing machine translation components and services. In additi= on to speech-to-SSML speech recognition and SSML-to-SSML machine translatio= n scenarios, we can envision new, intermediate data formats beyond SSML.

The inpu= ts and outputs of speech recognition, translation and speech synthesis comp= onents and services could be multiple formats =96 formats other than text.

API Ske= tch: Dataflow Graphs

Sketches= with respect to APIs include the declarative construction of dataflow grap= hs which interconnect abstract components. Such APIs can abstract away whether the interconnectable components are client-= side, on-prem, server-side, third-party or cloud-based. Such APIs can abstr= act away whether the interconnectable components are for free or priced to = end-users. Considerations to such API include the data formats and stream specifications of components=92 va= rious inputs and outputs to be interconnected.

Dataflow= graphs can be an intuitive abstraction layer, one which provides intuitive= and convenient programming while interconnecting arbitrary numbers of components and services. Dataflow graphs can intercon= nect client-side and remote speech recognition, translation and speech synt= hesis components as well as any other components which could reasonably be = interconnected or pipelined.

When suc= h dataflow graphs are prepared for activation, it is envisioned that users = will be provided with notifications, requests for permissions and options for payment.

Potenti= al IETF Work Items

When suc= h dataflow graphs are activated, it is envisioned that computer networking = protocols will be utilized to notify remote components or services of proper data routings, e.g. daisy-chain or pipeline configur= ations, in a secure manner.

That is,= there may be new protocols and computer networking topics with regard to i= mplementing the APIs for interconnecting WebRTC peers with speech recognition, translation and speech synthesis components= and services.

Conclus= ion

Tight We= bRTC integration is important for envisioned efficient, low-latency, high-p= erformance, scalable real-time translation scenarios.

While th= ere exist some ad hoc approaches to providing real-time translation with We= bRTC, standardizing new APIs and protocols can convenience developers, convenience end users, and create new markets with= respect to real-time translation scenarios.

Thank yo= u for considering adding real-time translation to the use cases for a next = version of WebRTC. I look forward to any discussion on these topics.

Referen= ces

[1] http://www.cs.cmu.edu/~ianlane/hydra/=
[2] https://www.youtube.com/watch?v=3D73rQ0lRx= 2aY
[3] https://www.youtube.com/watch?v=3DY7Jlj7QY= rcg
[4] https://arxiv.org/abs/1412.5567https://devblogs.nvidia.com/deep-speech-accurate-speech-recognit= ion-gpu-accelerated-deep-learning/
[6] https://github.com/mozilla/DeepSpeech
[7] https://open.library.ubc.ca/= media/stream/pdf/24/1.0348751/3
[8] https://deepmind.com/blog/= wavenet-generative-model-raw-audio/
[9] https://devblogs.nvidia.com= /nv-wavenet-gpu-speech-synthesis/
[10] https://www.forbes.com/sit= es/williamfalcon/2018/09/01/facebook-ai-just-set-a-new-record-in-translatio= n-and-why-it-matters/#205b9e5b3124
[11] https://store.systran.us/lp/sto= reSystran?Langue=3Den_US
[12] https://en= .wikipedia.org/wiki/Comparison_of_machine_translation_applications

 

 

From: B= ernard Aboba
Sent: Thursday, September 27, 2018 12:58 AM
Subject: Re: [rtcweb] WebRTC and Real-time Translation

 

One of the key questions for "Next Version Use Cases" is what Web= RTC-deficiencies are preventing these use cases from being satisfactorily i= mplemented today. 

 

For example, speech transcription cloud services have been implemented over= Websockets, where a snippet of speech is uploaded, and a transcription is = provided in reply.  The latency is satisfactory for some uses cases.&n= bsp;

Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API. 

 

What seems to differentiate *next version* scenarios are situations where t= he processing is best done on the device, in order to lower latency or enha= nce privacy.  On-device processing brings in discussion of workers/wor= klets, access to raw audio/video, etc.  However, so far I'm not aware of on-device implementations of transcriptio= n or translation.

 

On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> wrote= :

IETF RTCWEB Working Group,

 

Greetings. I opened an issue on WebRTC and Real-time Translation at = the GitHub repository for WebRTC version next use cases (https://git= hub.com/w3c/webrtc-nv-use-cases/issues/2).

 

Introdu= ction

Real-tim= e translation is both an interesting and important use case for a next vers= ion of WebRTC.

Speech = Recognition, Translation and Speech Synthesis

Approach= es to real-time speech-to-speech machine translation include those which in= terconnect speech recognition, translation and speech synthesis components and services. In that regard, we can consider = client-side, on-prem, server-side, third-party and cloud-based components a= nd services. In that regard, we can also consider both free and priced comp= onents and services.

We can e= nvision Connect= ing Components and Services by Constructing Graphs

We can c= onsider APIs which facilitate the construction of graphs which represent th= e flow of data between components and services. As these graphs are constructed, users could be apprised of relevant notif= ications, requests for permissions and options for payments. As these const= ructed graphs are activated, a number of protocols could be utilized to int= erconnect the components and services which, together, provide users with real-time translation.

Hyperli= nks

WebRTC Transl= ator Demo
Real Time Translation in WebRTC

 

 

Best regards,

Adam Sobieski

http://www.p= hoster.com/contents/

 

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

 

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

 

--_000_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_-- --_004_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_ Content-Type: image/png; name="C5841DF3510B4100AB06A6D813A5C982.png" Content-Description: C5841DF3510B4100AB06A6D813A5C982.png Content-Disposition: inline; filename="C5841DF3510B4100AB06A6D813A5C982.png"; size=148; creation-date="Fri, 05 Oct 2018 02:05:41 GMT"; modification-date="Fri, 05 Oct 2018 02:05:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAsIAAAABCAYAAAGj9vh8AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAApSURBVEhL7cixDQAwCAQx9l8aMsCXUETySW6u Xs25ONkTJ/wiTgDOVQ9ppL9dmmE2gQAAAABJRU5ErkJggg== --_004_CY4PR0101MB3095E0EAE1C11C37405E633EC5EB0CY4PR0101MB3095_-- From nobody Fri Oct 5 13:25:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5491E1277BB for ; Fri, 5 Oct 2018 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=VGUKMhtX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LhdCm9dd 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 m2He7Qq0EVqO for ; Fri, 5 Oct 2018 13:24:59 -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 F3AF4126BED for ; Fri, 5 Oct 2018 13:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538771097; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1zjsIm25mzOggZ6g+OZu+V5DJ5H9IBIwCOS6h2HrcMY=; b=VGUKMhtXZdIL5ycOMdbv33CxAtwmgVsDsCZDIAnW24pNasrBWdnToJW53Z8bbXFE nZzd3UqH1+/Veh0Wo9hXilQxf02WdVHbxqrwrsdtWaIHQ1RWNRcTUvLcCKTdPPfs 41BuuR6oyJFfpVEKntW6SD5WMu7eqziVbGbKzG7mBNU=; X-AuditID: c1b4fb2d-223ff700000055ff-ca-5bb7c899b9e2 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.77.22015.998C7BB5; Fri, 5 Oct 2018 22:24:57 +0200 (CEST) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB505.ericsson.se (153.88.183.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 5 Oct 2018 22:24:56 +0200 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 5 Oct 2018 22:24:56 +0200 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 5 Oct 2018 22:24:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1zjsIm25mzOggZ6g+OZu+V5DJ5H9IBIwCOS6h2HrcMY=; b=LhdCm9ddUj+PF/Sh/gzwB9F2N0da2LQgMk9khPCxVEoTYt3mPYFKaIml0oBLNRMF3cdD/1zcMbdxnlpm2mO5KvVlfS0G8qT/VFz9fN4F+Konhp6qZ5ZpBeo1NXQE60W6ezZd9ofAIWr+DmHNSPhbbZHKj8gPuuiGmmtIjiszp2g= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB4606.eurprd07.prod.outlook.com (20.177.56.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.16; Fri, 5 Oct 2018 20:24:55 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%5]) with mapi id 15.20.1207.018; Fri, 5 Oct 2018 20:24:54 +0000 From: Christer Holmberg To: Sean Turner CC: Ted Hardie , Adam Roach , "rtcweb@ietf.org" , IESG Secretary , "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 Thread-Index: AQHUXBMpmc/o3hnPw0aXMExXqquGUqUPcII3gAA+tgCAAWtJeA== Date: Fri, 5 Oct 2018 20:24:54 +0000 Message-ID: References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> , <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> In-Reply-To: <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [87.93.7.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4606; 6:GuDcAkzZfb/7gjCIqL4VWIvpL4VbyAb34bTPgHPnvdMFf4JHBWmQBnQ5Hoh6Qq8ciqQjLiiT46M2PtHLtyyrw+MKXX8UWCMTdHNDuBANRurabv5jZE64wrj/iD5EYZCgf32aTNifLbtC+6Bke0MJHNbH5w/GENzCEvzuINznqlGuR75v5xCUnAmbYnR3FGyW7sgaPTFrwFnOxf0pa6jWexzhvOwddUS48WOhHy0287hiOBUs+o70m6gWpvV8jNGzRtbeOdN2r7W/w6mkWwb9QbYt+HP6AXeWcBS6YAdO6xuHSXPlihzwnylMnQT/SkOy9ZM2z42adaYrXlamgnZLJgnqJowuO3lMfXqaQpKM7Ei/g+xFZpwj7E47hyy/7wjlHc8YLAtM70CzruSgsmI6GZOuouWdB0U3aEMsjntz+Wj7RBmLckupHQNIcP7sLa/sd8dfUk/39oifLibjzLTL1w==; 5:VO/9r9NAhfgJbiUQ+EavRq4Lxzy0rYTDhZWvn8LrBNhOmKKVt8IZWCqeECWcxGY9T0BVDEYe1sHhHRFSucJVFlrM60YvL47FoCFuXAtdjUCg6Y14PCdMgDzCGM3CuSNM3A2MNqPZGKkLitVcuQLl0Le8KKX8BSYsh+Vh6s2tZqg=; 7:gP76okqi3ZMmvU3tF36WdrwnIxCR+Py0nu1CsdoGbOySu7JuSABEJu5N10mgoJaqTTqJrT8BSuJO25OqLrbWgcPW0jVNbuNuECtKl2x0Pytn0RcCtdamOfVmR3vfCPNE2Sa6Lv0oSZJ65C5+RnjKEqLzAkWUdpKlsHaQIHHZXEbGp0uaMJPGeSsCOrIsh9c9Gb6wI+nnFarew0za0rbP0eKKZm/15Y1ODizak/mnTSi4dabiYW6zdbdq2QSFKa9U x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b85b439c-4eb7-4b40-55f2-08d62b009cc7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4606; x-ms-traffictypediagnostic: VI1PR07MB4606: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248295561703944)(37575265505322)(85827821059158)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:VI1PR07MB4606; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4606; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39860400002)(346002)(376002)(396003)(189003)(199004)(14454004)(19627405001)(39060400002)(86362001)(66066001)(486006)(106356001)(74316002)(68736007)(71190400001)(11346002)(71200400001)(476003)(966005)(446003)(256004)(14444005)(6606003)(44832011)(7736002)(5660300001)(6916009)(15974865002)(4326008)(53936002)(25786009)(6246003)(606006)(1015004)(2900100001)(3846002)(6506007)(33656002)(53546011)(6116002)(6436002)(316002)(7696005)(55016002)(99286004)(4001150100001)(236005)(9686003)(6306002)(54896002)(478600001)(8936002)(76176011)(81156014)(8676002)(81166006)(186003)(102836004)(97736004)(105586002)(26005)(229853002)(54906003)(16799955002)(2906002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4606; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 95RJ5tnA7rp0qRinrW8qaPe6mpk9kcj42ec5wyWxZJw4FCGTKxECxI3j30l2yh623iIJBX3QVPegLH8am/KgyK6fz7jBaICDaUrTV+VJZFlKdtV6bnd2/8aqIhdq+LvTl9AdIZAtoLsblB+5oolbhFtvpTTkwXoeMwubOSFPgs9L6t9Gsdbn6S5ilCL6qfMAnd3cw7V5WpCSRA93mSCohA0EmeOwl4cGcg1t1l9V18IaXxM0Fajk6Wg0ZIGOoKfvXAXOHC6sUsUEnRBedoJzA3D/LN+iWDkbdWiuVTd/SprC3pK8FfkvTkA7Uu6FAQ4xGbx4PJirBsQTvAros1+B8fnQ0kNUtWqVPPzRqB7OtU8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47826B03104E806C2055DD7593EB0VI1PR07MB4782eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b85b439c-4eb7-4b40-55f2-08d62b009cc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2018 20:24:54.9338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4606 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObvX3etqcFpOf1imzuihaFqWC9Q0CkYk2otChRp5caJO3V2S JakRWWpk6irNMh8IrSwza4ojdTh8FClSZGqkaYENKTExWWpuZ4H/fc73+/294LCUxOzkziap tZxGrUyRCUV0+SlDpn95jyEusNUskBsXaxj5zeVIedH0EC1vWMpn5O/1eZQ87354hFDRWvGZ UdTVLQgUFa2TtKKzE8XQsaLQBC4lKZPT7Ag/I1Ll/zUI06/tO99g/EnnInNIAXJmAQfDjK4Z FSARK8FmBB2WQdpmSPAcgoHRGGKscEftVYY8agXwfXlaaEvRuJiCAWsYMUoE0Gddpkj5OILh 50EFiGWFWA6FS3422QV7wWXzmJMtT+EeBJ8axxmbsR4fg8X+DgEJHQeL9QcivB9qbr2jyLDN MNm4YGcxjofK8W7H3gMInhpa7Y2ccRg0ddXYQwi7wnzfE3tTCrvB8GSVgByNoc7YTxGWwtTE khPJK6FdP+bQPaHww22GsAcMVhXahwF+zUDulytCYvjDL53OURAF9c13HKFuBKVtvxExfOF2 9Q1HKBnmChYdW6SArrCULkZBFasWJJwGj3qMdhbjddBbPkkTPQCGdGVCwn5QX22hCPvD3SUT vVp/iBg9kvIcz6cm7twVwGmSzvJ8mjpAzWmb0Mrn6my2+regx5ZIE8Iskq0Vi9oNcRInZSaf lWpCwFIyF/HMxRVJnKDMusBp0k5rzqVwvAltYGmZmzhAb4yV4ESllkvmuHRO898VsM7uuciz L+9txERWduDWIK/46ISwA2ObtmQ8C86ZPfjANPXtUltRj1UdGr7GJWSsJUT24uQrS5Ti42EP pitENSKVor3Z9zy5oxnp1zNeniiLeaPazho2GkXSSpVrVPOosv9Pjljblazd7XOEKY9PkzX4 RNN5h/bMfvXWlcx79+pTR7YNyGhepQzypTS88h+TUpb4WAMAAA== Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 05 Oct 2018 20:25:02 -0000 --_000_VI1PR07MB47826B03104E806C2055DD7593EB0VI1PR07MB4782eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am just wondering why we are making publication request when we know chan= ges are still needed. Regards, Christer ________________________________ From: Sean Turner Sent: Friday, October 5, 2018 1:43 AM To: Christer Holmberg Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; rtcweb-chairs@= ietf.org Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-= sdp-10 Yes and whole lot more drafts: https://www.rfc-editor.org/cluster_info.php?cid=3DC238 [C238] =BB RFC Editor www.rfc-editor.org 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) REF . = draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio PUB; draft= -ietf-rtcweb ... spt > On Oct 4, 2018, at 14:59, Christer Holmberg wrote: > > Hi, > > Assuming we are going to do the ICE reference update, this draft is affec= ted too. > > Regards, > > Christer > > > > From: rtcweb on behalf of Ted Hardie > Sent: Thursday, October 4, 2018 9:50 PM > To: adam@nostrum.com > Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sd= p-10 > > Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as Infor= mational on behalf of the RTCWEB working group. > > Please verify the document's state at https://datatracker.ietf.org/doc/dr= aft-ietf-rtcweb-sdp/ > draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC > datatracker.ietf.org > Annotated Example SDP for WebRTC (Internet-Draft, 2018) > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_VI1PR07MB47826B03104E806C2055DD7593EB0VI1PR07MB4782eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


I am just wondering why we are ma= king publication request when we know changes are still needed.


Regards,


Christer



From: Sean Turner <sean@= sn3rd.com>
Sent: Friday, October 5, 2018 1:43 AM
To: Christer Holmberg
Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; rtcweb-= chairs@ietf.org
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-= rtcweb-sdp-10
 
Yes and whole lot more drafts:
https://www.rfc-ed= itor.org/cluster_info.php?cid=3DC238
www.rfc-editor.org
2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) REF . = draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio PUB; draft= -ietf-rtcweb ...



spt

> On Oct 4, 2018, at 14:59, Christer Holmberg <christer.holmberg@eric= sson.com> wrote:
>
> Hi,
>
> Assuming we are going to do the ICE reference update, this draft is af= fected too.
>
> Regards,
>
> Christer
>
>
>
> From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Ted Hardie &= lt;ted.ietf@gmail.com>
> Sent: Thursday, October 4, 2018 9:50 PM
> To: adam@nostrum.com
> Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb= -sdp-10
> 
> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as In= formational on behalf of the RTCWEB working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/
> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC
> datatracker.ietf.org
> Annotated Example SDP for WebRTC (Internet-Draft, 2018)
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--_000_VI1PR07MB47826B03104E806C2055DD7593EB0VI1PR07MB4782eurp_-- From nobody Fri Oct 5 18:00:21 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330CE130E74 for ; Fri, 5 Oct 2018 18:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=unavailable 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 s_2mWNUXEfoH for ; Fri, 5 Oct 2018 18:00:17 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 92C30130E79 for ; Fri, 5 Oct 2018 18:00:15 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id 12-v6so2190248qkj.10 for ; Fri, 05 Oct 2018 18:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FLRYWc68Nkx1QwFJdEPgGnFY4yhsBJ414k0CC5ZNYuQ=; b=N4z1fNTxGVXJ469c6k6HGN8c4b7kuKUSZHROIROCV8Y44xJ3gy0MYBvvrF0PhbWEJ3 ccMKsi8+h429xbOKytRkmEjSiPioSlNHyms9kw7Cu0xLgmTE/ryQ6bXDi1tE9H7GYCVs 7XcPEiKaTOVCEEX2/LTOugwyPQ1qm5DWUzfls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FLRYWc68Nkx1QwFJdEPgGnFY4yhsBJ414k0CC5ZNYuQ=; b=nJOIgt7sF+twuUzwO+ZuoFhrc0/rYniHmI+Z+Y5XdY64/mdclNE3ApPWBT+X0s3R80 bMjY3sgI/0DMV87z6UZP5HSAoT9xy+S9ph6War4vj50zCCh+TNIiDgM+hH1GSxD6IoFK VGLa1Kv4O7E0zZso/vwKrlUKN7K30Pq5UeCcLkgXoPTESWIX5rN6n2zk4wMUZt6xRlLg QNAfJ0cKX784/m90f6fC2cgJN7NRcHUjKKm7iiki0a5uFHsUdxsEQgVDHLpxps9yBmEp cTwrLuwm7GswtsPTa4M3MWlSWFOKgjMaV/IwkcWhA3/vib8jXbljZdIwv3QyQsVxElP7 gsCw== X-Gm-Message-State: ABuFfoh6SOqXl0pqriB9i/i3zUxSDuOOJcNuA9raBEN/PkxxeMPOzEzh eB/h5vaQTaawl+UTzADzP4AEa5y4/Ww= X-Google-Smtp-Source: ACcGV62/W73me6NxXl66EHSjiFIewqFQSHDrSfM3ZxJGroDqZx30sFcj0aQjFusga1OAsTEm2ALBRA== X-Received: by 2002:a37:895:: with SMTP id 143-v6mr10602577qki.99.1538787614714; Fri, 05 Oct 2018 18:00:14 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id v5-v6sm4266307qkf.26.2018.10.05.18.00.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 18:00:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Fri, 5 Oct 2018 21:00:12 -0400 Cc: Ted Hardie , Adam Roach , "rtcweb@ietf.org" , IESG Secretary , "rtcweb-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com> References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 06 Oct 2018 01:00:19 -0000 We can as long as we identify that we have outstanding issues in the = Shepherd write-up (it does) and the AD is willing (I believe he is or we = will shortly find out that he is not). Note that I also asked Magnus if = he was okay with us dealing with his comments along with the other IETF = LC comments and he was. spt > On Oct 5, 2018, at 16:24, Christer Holmberg = wrote: >=20 > Hi, >=20 > I am just wondering why we are making publication request when we know = changes are still needed. >=20 > Regards, >=20 > Christer >=20 >=20 > From: Sean Turner > Sent: Friday, October 5, 2018 1:43 AM > To: Christer Holmberg > Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; = rtcweb-chairs@ietf.org > Subject: Re: [rtcweb] Publication has been requested for = draft-ietf-rtcweb-sdp-10 > =20 > Yes and whole lot more drafts: > https://www.rfc-editor.org/cluster_info.php?cid=3DC238 > [C238] =C2=BB RFC Editor > www.rfc-editor.org > 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) = REF . draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio = PUB; draft-ietf-rtcweb ... >=20 >=20 >=20 > spt >=20 > > On Oct 4, 2018, at 14:59, Christer Holmberg = wrote: > >=20 > > Hi, > >=20 > > Assuming we are going to do the ICE reference update, this draft is = affected too. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > From: rtcweb on behalf of Ted Hardie = > > Sent: Thursday, October 4, 2018 9:50 PM > > To: adam@nostrum.com > > Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > > Subject: [rtcweb] Publication has been requested for = draft-ietf-rtcweb-sdp-10 > > =20 > > Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as = Informational on behalf of the RTCWEB working group. > >=20 > > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC > > datatracker.ietf.org > > Annotated Example SDP for WebRTC (Internet-Draft, 2018) > >=20 > >=20 > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 5 18:43:45 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3F129385 for ; Fri, 5 Oct 2018 18:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rpAF9IdyfT_f for ; Fri, 5 Oct 2018 18:43:40 -0700 (PDT) Received: from smtp105.ord1d.emailsrvr.com (smtp105.ord1d.emailsrvr.com [184.106.54.105]) (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 24524130DC3 for ; Fri, 5 Oct 2018 18:43:40 -0700 (PDT) Received: from smtp6.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 29245E012E; Fri, 5 Oct 2018 21:43:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A4AB7E012B; Fri, 5 Oct 2018 21:43:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 05 Oct 2018 21:43:39 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Cullen Jennings In-Reply-To: <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com> Date: Fri, 5 Oct 2018 19:43:37 -0600 Cc: Ted Hardie , Adam Roach , RTCWeb IETF , IESG Secretary , "rtcweb-chairs@ietf.org" , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 06 Oct 2018 01:43:43 -0000 Christer,=20 Just as FYI =E2=80=A6 Suhas and I are working on a PR for sdp draft that = moves the examples to be consistent with ice2. Cullen > On Oct 5, 2018, at 7:00 PM, Sean Turner wrote: >=20 > We can as long as we identify that we have outstanding issues in the = Shepherd write-up (it does) and the AD is willing (I believe he is or we = will shortly find out that he is not). Note that I also asked Magnus if = he was okay with us dealing with his comments along with the other IETF = LC comments and he was. >=20 > spt >=20 >> On Oct 5, 2018, at 16:24, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> I am just wondering why we are making publication request when we = know changes are still needed. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> From: Sean Turner >> Sent: Friday, October 5, 2018 1:43 AM >> To: Christer Holmberg >> Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; = rtcweb-chairs@ietf.org >> Subject: Re: [rtcweb] Publication has been requested for = draft-ietf-rtcweb-sdp-10 >>=20 >> Yes and whole lot more drafts: >> https://www.rfc-editor.org/cluster_info.php?cid=3DC238 >> [C238] =C2=BB RFC Editor >> www.rfc-editor.org >> 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) = REF . draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio = PUB; draft-ietf-rtcweb ... >>=20 >>=20 >>=20 >> spt >>=20 >>> On Oct 4, 2018, at 14:59, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>> Assuming we are going to do the ICE reference update, this draft is = affected too. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> From: rtcweb on behalf of Ted Hardie = >>> Sent: Thursday, October 4, 2018 9:50 PM >>> To: adam@nostrum.com >>> Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org >>> Subject: [rtcweb] Publication has been requested for = draft-ietf-rtcweb-sdp-10 >>>=20 >>> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as = Informational on behalf of the RTCWEB working group. >>>=20 >>> Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ >>> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC >>> datatracker.ietf.org >>> Annotated Example SDP for WebRTC (Internet-Draft, 2018) >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sat Oct 6 12:14:54 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55BC130E18 for ; Sat, 6 Oct 2018 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=cfma0m0o; dkim=pass (1024-bit key) header.d=ericsson.com header.b=bSf4YEnH 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 TtIpmWxP8DX9 for ; Sat, 6 Oct 2018 12:14:49 -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 2E2461292AD for ; Sat, 6 Oct 2018 12:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538853286; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pzgauKwHbUjd+CuD6ouvJwkzKA3PBcuHa4WBNyufBnU=; b=cfma0m0ohEcLXoRGzGJKoCeXdv7JHT9gcgo/V2sco3W1AGViDXtNrUqgPVg+OZz8 xuyzNJQf0BwbLmMPvoa0C2CeKlqR5NGUsXmRzX832EO7BwyUIUH7otX2QzOjKAA0 vmGDHWdAP17irQGsDOtVvOe7dYts54V1H7+Km8js4pY=; X-AuditID: c1b4fb25-8ffff700000013ad-e6-5bb909a6c06a Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.6E.05037.6A909BB5; Sat, 6 Oct 2018 21:14:46 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 6 Oct 2018 21:14:46 +0200 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 6 Oct 2018 21:14:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pzgauKwHbUjd+CuD6ouvJwkzKA3PBcuHa4WBNyufBnU=; b=bSf4YEnHfmb3Wp1pYsOTcLA/iYM6sMvJ932Xundpihk1EBgpsyCQHGj+Ph2YTjchpqQKcfZkEIgGpOcdN2S7p+96blAZnVAQ6rBQidVnOq5VO+MA16etnN6rMzR2gEBYGSjHfPp/37BDDVFB0lgdUZW06F06I0afjwdkA+WNywY= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB1328.eurprd07.prod.outlook.com (10.164.92.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Sat, 6 Oct 2018 19:14:45 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.011; Sat, 6 Oct 2018 19:14:45 +0000 From: Christer Holmberg To: Cullen Jennings CC: Ted Hardie , Adam Roach , "RTCWeb IETF" , IESG Secretary , "rtcweb-chairs@ietf.org" , Sean Turner Thread-Topic: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 Thread-Index: AQHUXBMpmc/o3hnPw0aXMExXqquGUqUPcII3gAA+tgCAAWtJeIAATTcAgAAMIYCAASWWng== Date: Sat, 6 Oct 2018 19:14:44 +0000 Message-ID: References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.87.137] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1328; 6:JguAkSFFnXj1jQTKylTPmq82kNo6PBuU0dvv324CGtn1czoDAIX9WN3Q6A8PyJinc6Tf2bAvX+onwHZMj7kEjtF1LZFd53UHeWY1AaGdlvOwqEGIGhYVC+55stfO9C5y/0sr3D5y3acf02lT0JC62bDEFaezIjhdWOM+mUt3wo/2dSAXvpGflAPCaUTshBF68uSp0nnuXMOK+tamIoKMfHLfmkP3DpkCU3GVAVQ0fsk8QotHhvXl23N9aoEPQZo6vXmYMt1HmQYvInThadTB+naZmVwpCSnZi8awOCxwE94/b5yNo/7BIy74/W47/6OSMA9mp/70jfQJ/6YDCojU34KdHRTZ8N0w47gQlNDFlyz0Tq9RPhsVehBovvsmCf09ZxQZbbI+zygoIGPeeOCJZysVRSfFFcfLWO0jVPV5r5aCwNNONzFGLa1eIlJPY8MUp4sfy4eMRUP9/cAhe/WAoQ==; 5:JKVZvpn2G5bELfAjOcunW3cHBpk5NuVH9yZ+QL9cH3MsRJeQB/oA/qUSMYDwar9AQX9oNVcPrXnQ5v2hZuw0kmrmbOPOshiz0fQEc4JBjkDpTw3wFJpMw3L/heHrulszacJaw1GkHfhASRRI+GF95u3PN9DM6g2OH1rba9N0djE=; 7:qoTpd1yAdFnRl7ga5akC2jlHbM6T8yqdmkYfEgbS1aMAax6lz9EOx7QZqiK7atE9cF8Rcaw25hMfpVNZxsyncW0qNwaNd++EHsd4zQPJQl4rT9AgNCI2AcH8wir9pbM3lUP9UInLJ4RZdo15psmrb32t+31qYHTx/0CIhE/KP2V5Z6WvLV6JDou9L0pudTAeGd5jlojA5cQr8FoRJavI5ay60cEBuZTIAKWcJH/ddloUM8KLZBs7lsIaF9BKNpfc x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 10b6a997-b050-42c6-5ec2-08d62bbff9dc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB1328; x-ms-traffictypediagnostic: VI1PR07MB1328: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944)(85827821059158)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051); SRVR:VI1PR07MB1328; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1328; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(376002)(39860400002)(346002)(69234005)(199004)(189003)(256004)(4326008)(2900100001)(14444005)(71200400001)(71190400001)(39060400002)(1015004)(6246003)(66066001)(68736007)(53386004)(74316002)(14454004)(106356001)(7736002)(105586002)(5660300001)(6606003)(478600001)(19627405001)(966005)(93886005)(316002)(8676002)(81156014)(81166006)(6916009)(2906002)(606006)(8936002)(16799955002)(229853002)(53936002)(97736004)(54906003)(4001150100001)(55016002)(44832011)(6306002)(54896002)(236005)(6436002)(6116002)(3846002)(26005)(15974865002)(86362001)(486006)(5250100002)(9686003)(102836004)(25786009)(33656002)(11346002)(446003)(6506007)(7696005)(76176011)(186003)(53546011)(99286004)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1328; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AZfavYd7IvCdNwgCgEHEQI3PgIBsTBV1txDeaLYbQmMQnG7gFuXctr3CAEFUpIgsu802CW1kqRl30LpF+CHwmbOANIK+mV/0HdrV/jBdKe7bkG0TpsE6Dg0rAW5vd7xSPidtHLrDHKpWYHkCKZV//fEQx7gLh69Y+bTROPy/a1fBvveZeXY3Y7fbXVMHZxyhijc0gXDIRrHVysSOwsEoVxyZiljlpOAGSCOUlYmX5wLAcEU4Ro862qpQuxRgDZzbSJO6sJKTqP3OREHIVWaHiuTiCEU4/yWJRN3LuqrNCjV/PZO/4Vnh+925Q1jJeimcDMVRmmONKOou33Rfji81/qsYCRh4fm+Kfu2+AOg4lcs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4782A232B401755AE40EA3C993E40VI1PR07MB4782eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 10b6a997-b050-42c6-5ec2-08d62bbff9dc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2018 19:14:44.8709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1328 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjuO+ds52w4+lra3oqCVlFZU7vRCLOMiAUF3Yhyia08qEyn7NiV QiUqaNVcuR+ui13WbZorS3LeSql00rJ0WRZC1spVVhpIirja/Bb473mfy/u9D3wcLX8umsJl GHJ5o0GXqRRLmeLtDw+pbkhc2jhnRYy6duQqq+5zDiK1+W+i+tSPt4z6TuAEq/Y6Cmh1wcWE VazGZetiNXb7EKVpb+1HGpvLx2gaGtBGUZI0PpXPzNjHG2MTdknT3zW0iXMGhQOVAy1UPvLn nEQSDvAS8Pab0Ukk5eT4KQLLuWKaDAMICgKdFBmuUeAru4VCEQYX0lDzJooIZynwd5pFZOgO 5o//DuY5TozVYArMDwUi8Ux4UdU1upbGPgS+20VUSJiIt8BI62OKmLbC9+FviOBt4PbUiEN7 GDwLTJ/yQrQM74SbV1xi8tZxGnzPekQhQYKXQ76VXIfwJPjTUja6k8YKeOcroUhRDPbaVprg KPj6KSAifh08cnwI8zPA6q0O+6dBW4kJEVzPQkVvMsEq6LNaw/4NYDnqHS0PuAlBx517YSEa zvs8LMF6KLd4qVAZwJlQWDuZ0NPBcbqbKURxtjGnEpwNlT0dItto5wngLvYxtmCaxvPAWR1L LDOgyNTNEjwXjl24yI7lLyPWgaIEXtidlbZocQxvzNgjCNmGGAOfW4GCf6zhwfDsKtTem9iI MIeUEbK6cS6tXKTbJxzMakTA0cpIWXNJlVYuS9UdPMQbs1OMezN5oRFN5RilQta97H6SHKfp cnk9z+fwxv8qxUmm5CN9vFfb+qJOtaLDcGROmmqZ0/7YNpKitSa9N39PVzw6vVjf436S3Cy7 4t/8JNdlMVoGLq2KV9RXetDQV+V91d2XpUqx8/Pv19/+Xn+7I6L0/Zq1ie6PX6p/lHfGN623 5PXt/3Wza7xn3R7xcOylwVcLhlb/PBMp8S/tOlzetFK3yX5DyQjpuoXRtFHQ/QPs98YIXwMA AA== Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 06 Oct 2018 19:14:53 -0000 --_000_VI1PR07MB4782A232B401755AE40EA3C993E40VI1PR07MB4782eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzISDwn5iKDQoNCg0KUmVnYXJkcywNCg0KDQpDaHJpc3Rlcg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWku Y2E+DQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA2LCAyMDE4IDQ6NDMgQU0NClRvOiBDaHJpc3Rl ciBIb2xtYmVyZw0KQ2M6IFRlZCBIYXJkaWU7IEFkYW0gUm9hY2g7IFJUQ1dlYiBJRVRGOyBJRVNH IFNlY3JldGFyeTsgcnRjd2ViLWNoYWlyc0BpZXRmLm9yZzsgU2VhbiBUdXJuZXINClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWll dGYtcnRjd2ViLXNkcC0xMA0KDQoNCkNocmlzdGVyLA0KDQpKdXN0IGFzIEZZSSDigKYgU3VoYXMg YW5kIEkgYXJlIHdvcmtpbmcgb24gYSBQUiBmb3Igc2RwIGRyYWZ0IHRoYXQgbW92ZXMgdGhlIGV4 YW1wbGVzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBpY2UyLg0KDQpDdWxsZW4NCg0KDQoNCj4gT24g T2N0IDUsIDIwMTgsIGF0IDc6MDAgUE0sIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3Jv dGU6DQo+DQo+IFdlIGNhbiBhcyBsb25nIGFzIHdlIGlkZW50aWZ5IHRoYXQgd2UgaGF2ZSBvdXRz dGFuZGluZyBpc3N1ZXMgaW4gdGhlIFNoZXBoZXJkIHdyaXRlLXVwIChpdCBkb2VzKSBhbmQgdGhl IEFEIGlzIHdpbGxpbmcgKEkgYmVsaWV2ZSBoZSBpcyBvciB3ZSB3aWxsIHNob3J0bHkgZmluZCBv dXQgdGhhdCBoZSBpcyBub3QpLiAgTm90ZSB0aGF0IEkgYWxzbyBhc2tlZCBNYWdudXMgaWYgaGUg d2FzIG9rYXkgd2l0aCB1cyBkZWFsaW5nIHdpdGggaGlzIGNvbW1lbnRzIGFsb25nIHdpdGggdGhl IG90aGVyIElFVEYgTEMgY29tbWVudHMgYW5kIGhlIHdhcy4NCj4NCj4gc3B0DQo+DQo+PiBPbiBP Y3QgNSwgMjAxOCwgYXQgMTY6MjQsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4NCj4+IEhpLA0KPj4NCj4+IEkgYW0ganVzdCB3b25k ZXJpbmcgd2h5IHdlIGFyZSBtYWtpbmcgcHVibGljYXRpb24gcmVxdWVzdCB3aGVuIHdlIGtub3cg Y2hhbmdlcyBhcmUgc3RpbGwgbmVlZGVkLg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0 ZXINCj4+DQo+Pg0KPj4gRnJvbTogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KPj4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDUsIDIwMTggMTo0MyBBTQ0KPj4gVG86IENocmlzdGVyIEhvbG1i ZXJnDQo+PiBDYzogVGVkIEhhcmRpZTsgQWRhbSBSb2FjaDsgcnRjd2ViQGlldGYub3JnOyBJRVNH IFNlY3JldGFyeTsgcnRjd2ViLWNoYWlyc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtydGN3 ZWJdIFB1YmxpY2F0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWIt c2RwLTEwDQo+Pg0KPj4gWWVzIGFuZCB3aG9sZSBsb3QgbW9yZSBkcmFmdHM6DQo+PiBodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVzdGVyX2luZm8ucGhwP2NpZD1DMjM4DQpbQzIzOF0gwrsg UkZDIEVkaXRvcjxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVzdGVyX2luZm8ucGhwP2Np ZD1DMjM4Pg0Kd3d3LnJmYy1lZGl0b3Iub3JnDQoyMDE0LTEyLTEyIHwgZHJhZnQtaWV0Zi1ybWNh dC1jYy1yZXF1aXJlbWVudHMtMDkudHh0IHwgTUlTU1JFRipSKDFHKSBSRUYgLiBkcmFmdC1pZXRm LXJ0Y3dlYi1vdmVydmlldyBNSVNTUkVGKlIoMUcpIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvIFBV QjsgZHJhZnQtaWV0Zi1ydGN3ZWIgLi4uDQoNCg0KDQo+PiBbQzIzOF0gwrsgUkZDIEVkaXRvcg0K Pj4gd3d3LnJmYy1lZGl0b3Iub3JnPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmc+DQo+PiAyMDE0 LTEyLTEyIHwgZHJhZnQtaWV0Zi1ybWNhdC1jYy1yZXF1aXJlbWVudHMtMDkudHh0IHwgTUlTU1JF RipSKDFHKSBSRUYgLiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBNSVNTUkVGKlIoMUcpIGRy YWZ0LWlldGYtcnRjd2ViLWF1ZGlvIFBVQjsgZHJhZnQtaWV0Zi1ydGN3ZWIgLi4uDQo+Pg0KPj4N Cj4+DQo+PiBzcHQNCj4+DQo+Pj4gT24gT2N0IDQsIDIwMTgsIGF0IDE0OjU5LCBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pg0KPj4+ IEhpLA0KPj4+DQo+Pj4gQXNzdW1pbmcgd2UgYXJlIGdvaW5nIHRvIGRvIHRoZSBJQ0UgcmVmZXJl bmNlIHVwZGF0ZSwgdGhpcyBkcmFmdCBpcyBhZmZlY3RlZCB0b28uDQo+Pj4NCj4+PiBSZWdhcmRz LA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4+DQo+Pj4NCj4+PiBGcm9tOiBydGN3ZWIgPHJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVGVkIEhhcmRpZSA8dGVkLmlldGZA Z21haWwuY29tPg0KPj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDQsIDIwMTggOTo1MCBQTQ0K Pj4+IFRvOiBhZGFtQG5vc3RydW0uY29tDQo+Pj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgaWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBb cnRjd2ViXSBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtcnRj d2ViLXNkcC0xMA0KPj4+DQo+Pj4gVGVkIEhhcmRpZSBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9u IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXNkcC0xMCBhcyBJbmZvcm1hdGlvbmFsIG9uIGJlaGFsZiBv ZiB0aGUgUlRDV0VCIHdvcmtpbmcgZ3JvdXAuDQo+Pj4NCj4+PiBQbGVhc2UgdmVyaWZ5IHRoZSBk b2N1bWVudCdzIHN0YXRlIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcnRjd2ViLXNkcC8NCj4+PiBkcmFmdC1pZXRmLXJ0Y3dlYi1zZHAtMTAgLSBBbm5vdGF0 ZWQgRXhhbXBsZSBTRFAgZm9yIFdlYlJUQw0KPj4+IGRhdGF0cmFja2VyLmlldGYub3JnDQo+Pj4g QW5ub3RhdGVkIEV4YW1wbGUgU0RQIGZvciBXZWJSVEMgKEludGVybmV0LURyYWZ0LCAyMDE4KQ0K Pj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+IHJ0Y3dlYkBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+DQoNCg== --_000_VI1PR07MB4782A232B401755AE40EA3C993E40VI1PR07MB4782eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5UaGFua3MhIDxzcGFuPvCfmIo8L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5SZWdhcmRzLDwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48YnI+DQo8L3A+DQo8cCBzdHlsZT0i bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+Q2hyaXN0ZXI8L3A+DQo8YnI+DQo8YnI+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHls ZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7d2lkdGg6OTglIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RN c2ciIGRpcj0ibHRyIj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iQ2FsaWJyaSwgc2Fucy1z ZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gQ3VsbGVuIEplbm5pbmdz ICZsdDtmbHVmZnlAaWlpLmNhJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2Jl ciA2LCAyMDE4IDQ6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0K PGI+Q2M6PC9iPiBUZWQgSGFyZGllOyBBZGFtIFJvYWNoOyBSVENXZWIgSUVURjsgSUVTRyBTZWNy ZXRhcnk7IHJ0Y3dlYi1jaGFpcnNAaWV0Zi5vcmc7IFNlYW4gVHVybmVyPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbcnRjd2ViXSBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRy YWZ0LWlldGYtcnRjd2ViLXNkcC0xMDwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCkNocmlzdGVyLCA8 YnI+DQo8YnI+DQpKdXN0IGFzIEZZSSDigKYgU3VoYXMgYW5kIEkgYXJlIHdvcmtpbmcgb24gYSBQ UiBmb3Igc2RwIGRyYWZ0IHRoYXQgbW92ZXMgdGhlIGV4YW1wbGVzIHRvIGJlIGNvbnNpc3RlbnQg d2l0aCBpY2UyLjxicj4NCjxicj4NCkN1bGxlbjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsg T24gT2N0IDUsIDIwMTgsIGF0IDc6MDAgUE0sIFNlYW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNv bSZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGNhbiBhcyBsb25nIGFzIHdlIGlk ZW50aWZ5IHRoYXQgd2UgaGF2ZSBvdXRzdGFuZGluZyBpc3N1ZXMgaW4gdGhlIFNoZXBoZXJkIHdy aXRlLXVwIChpdCBkb2VzKSBhbmQgdGhlIEFEIGlzIHdpbGxpbmcgKEkgYmVsaWV2ZSBoZSBpcyBv ciB3ZSB3aWxsIHNob3J0bHkgZmluZCBvdXQgdGhhdCBoZSBpcyBub3QpLiZuYnNwOyBOb3RlIHRo YXQgSSBhbHNvIGFza2VkIE1hZ251cyBpZiBoZSB3YXMgb2theSB3aXRoIHVzIGRlYWxpbmcgd2l0 aCBoaXMgY29tbWVudHMNCiBhbG9uZyB3aXRoIHRoZSBvdGhlciBJRVRGIExDIGNvbW1lbnRzIGFu ZCBoZSB3YXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHNwdDxicj4NCiZndDsgPGJyPg0KJmd0OyZn dDsgT24gT2N0IDUsIDIwMTgsIGF0IDE2OjI0LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGFtIGp1c3Qgd29uZGVy aW5nIHdoeSB3ZSBhcmUgbWFraW5nIHB1YmxpY2F0aW9uIHJlcXVlc3Qgd2hlbiB3ZSBrbm93IGNo YW5nZXMgYXJlIHN0aWxsIG5lZWRlZC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBSZWdh cmRzLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgRnJvbTogU2VhbiBUdXJuZXIgJmx0O3NlYW5A c24zcmQuY29tJmd0Ozxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgT2N0b2JlciA1LCAyMDE4 IDE6NDMgQU08YnI+DQomZ3Q7Jmd0OyBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQomZ3Q7Jmd0 OyBDYzogVGVkIEhhcmRpZTsgQWRhbSBSb2FjaDsgcnRjd2ViQGlldGYub3JnOyBJRVNHIFNlY3Jl dGFyeTsgcnRjd2ViLWNoYWlyc0BpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBb cnRjd2ViXSBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtcnRj d2ViLXNkcC0xMDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFllcyBhbmQgd2hvbGUgbG90 IG1vcmUgZHJhZnRzOjxicj4NCiZndDsmZ3Q7IDxhIGNsYXNzPSJPV0FBdXRvTGluayIgaWQ9IkxQ bG5rOTE1NzA1IiBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVzdGVyX2luZm8u cGhwP2NpZD1DMjM4IiBwcmV2aWV3cmVtb3ZlZD0idHJ1ZSI+DQpodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9jbHVzdGVyX2luZm8ucGhwP2NpZD1DMjM4PC9hPg0KPGRpdiBpZD0iTFBCb3JkZXJf R1RfMTUzODg1MzI3MDc5NzAuMTQ1MjQzNjQyODMyNzIzOTUiIHN0eWxlPSJ3aWR0aDogMTAwJTsg dGV4dC1pbmRlbnQ6IDBweDsgb3ZlcmZsb3c6IGF1dG87IG1hcmdpbi1ib3R0b206IDIwcHg7Ij4N Cjx0YWJsZSBpZD0iTFBDb250YWluZXJfMTUzODg1MzI3MDc4OTAuMjYzMTQ0NDIyNjc0MTM4NiIg cm9sZT0icHJlc2VudGF0aW9uIiBzdHlsZT0id2lkdGg6IDkwJTsgb3ZlcmZsb3c6IGF1dG87IHBh ZGRpbmctdG9wOiAyMHB4OyBwYWRkaW5nLWJvdHRvbTogMjBweDsgbWFyZ2luLXRvcDogMjBweDsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDIwMCwgMjAwLCAyMDApOyBib3JkZXItYm90dG9tLWNvbG9y OiByZ2IoMjAwLCAyMDAsIDIwMCk7IGJvcmRlci10b3Atd2lkdGg6IDFweDsgYm9yZGVyLWJvdHRv bS13aWR0aDogMXB4OyBib3JkZXItdG9wLXN0eWxlOiBkb3R0ZWQ7IGJvcmRlci1ib3R0b20tc3R5 bGU6IGRvdHRlZDsgcG9zaXRpb246IHJlbGF0aXZlOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IiBjZWxsc3BhY2luZz0iMCI+DQo8dGJvZHk+DQo8dHIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJib3JkZXItc3BhY2luZzogMHB4OyI+DQo8dGQgaWQ9IlRleHRDZWxsXzE1Mzg4NTMy NzA3OTEwLjk4MDU4NTY4MjU2MDI3NDEiIHN0eWxlPSJwYWRkaW5nOiAwcHg7IHZlcnRpY2FsLWFs aWduOiB0b3A7IGRpc3BsYXk6IHRhYmxlLWNlbGw7IHBvc2l0aW9uOiByZWxhdGl2ZTsiIGNvbHNw YW49IjIiPg0KPGRpdiBpZD0iTFBSZW1vdmVQcmV2aWV3Q29udGFpbmVyXzE1Mzg4NTMyNzA3OTEw LjMxODIzNjI0MDYxOTU3MzU2Ij48L2Rpdj4NCjxkaXYgaWQ9IkxQVGl0bGVfMTUzODg1MzI3MDc5 MTAuMzA0MjUxNjI4MzI5NjExNyIgc3R5bGU9InRvcDogMHB4OyBjb2xvcjogcmdiKDAsIDE2OSwg MjEyKTsgbGluZS1oZWlnaHQ6IDIxcHg7IGZvbnQtZmFtaWx5OiAmcXVvdDt3Zl9zZWdvZS11aV9s aWdodCZxdW90OywmcXVvdDtTZWdvZSBVSSBMaWdodCZxdW90OywmcXVvdDtTZWdvZSBXUCBMaWdo dCZxdW90OywmcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtTZWdvZSBXUCZxdW90OyxUYWhvbWEs QXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAyMXB4OyBmb250LXdlaWdodDogNDAwOyI+DQo8 YSBpZD0iTFBVcmxBbmNob3JfMTUzODg1MzI3MDc5NDAuOTI5MDk4ODQzMTAzNTg5NiIgc3R5bGU9 InRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2NsdXN0ZXJfaW5mby5waHA/Y2lkPUMyMzgiIHRhcmdldD0iX2JsYW5rIj5bQzIzOF0gwrsgUkZD IEVkaXRvcjwvYT48L2Rpdj4NCjxkaXYgaWQ9IkxQTWV0YWRhdGFfMTUzODg1MzI3MDc5NDAuMjcx NTc1OTI1ODAxNjcxIiBzdHlsZT0ibWFyZ2luOiAxMHB4IDBweCAxNnB4OyBjb2xvcjogcmdiKDEw MiwgMTAyLCAxMDIpOyBsaW5lLWhlaWdodDogMTRweDsgZm9udC1mYW1pbHk6ICZxdW90O3dmX3Nl Z29lLXVpX25vcm1hbCZxdW90OywmcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtTZWdvZSBXUCZx dW90OyxUYWhvbWEsQXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXdlaWdo dDogNDAwOyI+DQp3d3cucmZjLWVkaXRvci5vcmc8L2Rpdj4NCjxkaXYgaWQ9IkxQRGVzY3JpcHRp b25fMTUzODg1MzI3MDc5NTAuMzc0ODA3OTIwMTQ0MDcyOCIgc3R5bGU9ImNvbG9yOiByZ2IoMTAy LCAxMDIsIDEwMik7IGxpbmUtaGVpZ2h0OiAyMHB4OyBvdmVyZmxvdzogaGlkZGVuOyBmb250LWZh bWlseTogJnF1b3Q7d2Zfc2Vnb2UtdWlfbm9ybWFsJnF1b3Q7LCZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9tYSxBcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtd2VpZ2h0OiA0MDA7IGRpc3BsYXk6IGJsb2NrOyBtYXgtaGVpZ2h0OiAxMDBw eDsiPg0KMjAxNC0xMi0xMiB8IGRyYWZ0LWlldGYtcm1jYXQtY2MtcmVxdWlyZW1lbnRzLTA5LnR4 dCB8IE1JU1NSRUYqUigxRykgUkVGIC4gZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXcgTUlTU1JF RipSKDFHKSBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpbyBQVUI7IGRyYWZ0LWlldGYtcnRjd2ViIC4u LjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPGJyPg0K PGJyPg0KJmd0OyZndDsgW0MyMzhdIMK7IFJGQyBFZGl0b3I8YnI+DQomZ3Q7Jmd0OyA8YSBjbGFz cz0iT1dBQXV0b0xpbmsiIGlkPSJMUGxuazU3Mzg0NiIgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRp dG9yLm9yZyIgcHJldmlld3JlbW92ZWQ9InRydWUiPg0Kd3d3LnJmYy1lZGl0b3Iub3JnPC9hPjxi cj4NCiZndDsmZ3Q7IDIwMTQtMTItMTIgfCBkcmFmdC1pZXRmLXJtY2F0LWNjLXJlcXVpcmVtZW50 cy0wOS50eHQgfCBNSVNTUkVGKlIoMUcpIFJFRiAuIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3 IE1JU1NSRUYqUigxRykgZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8gUFVCOyBkcmFmdC1pZXRmLXJ0 Y3dlYiAuLi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBzcHQ8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgT24gT2N0IDQs IDIwMTgsIGF0IDE0OjU5LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IEhpLDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQXNzdW1pbmcgd2Ug YXJlIGdvaW5nIHRvIGRvIHRoZSBJQ0UgcmVmZXJlbmNlIHVwZGF0ZSwgdGhpcyBkcmFmdCBpcyBh ZmZlY3RlZCB0b28uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBSZWdhcmRz LDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgRnJvbTogcnRjd2ViICZsdDtydGN3ZWItYm91bmNlc0BpZXRmLm9yZyZndDsgb24g YmVoYWxmIG9mIFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIE9jdG9iZXIgNCwgMjAxOCA5OjUwIFBNPGJyPg0KJmd0 OyZndDsmZ3Q7IFRvOiBhZGFtQG5vc3RydW0uY29tPGJyPg0KJmd0OyZndDsmZ3Q7IENjOiBydGN3 ZWJAaWV0Zi5vcmc7IGllc2ctc2VjcmV0YXJ5QGlldGYub3JnOyBydGN3ZWItY2hhaXJzQGlldGYu b3JnPGJyPg0KJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtydGN3ZWJdIFB1YmxpY2F0aW9uIGhhcyBi ZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWItc2RwLTEwPGJyPg0KJmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUZWQgSGFyZGllIGhhcyByZXF1ZXN0ZWQgcHVibGljYXRp b24gb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc2RwLTEwIGFzIEluZm9ybWF0aW9uYWwgb24gYmVoYWxm IG9mIHRoZSBSVENXRUIgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IFBsZWFzZSB2ZXJpZnkgdGhlIGRvY3VtZW50J3Mgc3RhdGUgYXQgPGEgY2xhc3M9 Ik9XQUF1dG9MaW5rIiBpZD0iTFBsbms4MTM5MDMiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNkcC8iIHByZXZpZXdyZW1vdmVkPSJ0cnVl Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNk cC88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtcnRjd2ViLXNkcC0xMCAtIEFubm90 YXRlZCBFeGFtcGxlIFNEUCBmb3IgV2ViUlRDPGJyPg0KJmd0OyZndDsmZ3Q7IGRhdGF0cmFja2Vy LmlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7IEFubm90YXRlZCBFeGFtcGxlIFNEUCBmb3IgV2Vi UlRDIChJbnRlcm5ldC1EcmFmdCwgMjAxOCk8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgcnRj d2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQom Z3Q7Jmd0OyZndDsgPGEgY2xhc3M9Ik9XQUF1dG9MaW5rIiBpZD0iTFBsbmsyNTI0OTYiIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiBwcmV2aWV3cmVt b3ZlZD0idHJ1ZSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YjwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR07MB4782A232B401755AE40EA3C993E40VI1PR07MB4782eurp_-- From nobody Tue Oct 9 20:40:58 2018 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 1A1DB130E5A; Tue, 9 Oct 2018 20:40:57 -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.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <153914285704.10651.5473110712555863295@ietfa.amsl.com> Date: Tue, 09 Oct 2018 20:40:57 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-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, 10 Oct 2018 03:40:57 -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 : Annotated Example SDP for WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-11.txt Pages : 121 Date : 2018-10-09 Abstract: The Real-Time Communications in WEB-browsers (Rtcweb) working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the Rtcweb framework, Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common Rtcweb use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-11 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-11 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 Tue Oct 9 20:42:42 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567E6130E5F; Tue, 9 Oct 2018 20:42:41 -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 rBcceWbgxt0n; Tue, 9 Oct 2018 20:42:38 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 F3ABB130E17; Tue, 9 Oct 2018 20:42:34 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id e206so3729808vsd.0; Tue, 09 Oct 2018 20:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=24Iss1eEH38zlziYMppNQ3Mtwhda70OL+rcYYmq2Bs0=; b=VWMVjh5pTsUDboxd7HY3OFQYxLENfItXutl1USmVaf5ZbyKouXzN6Aqev9MMIM1xqG Ejax2qdOEoQcLiMmEdetssmWV/9vV5ZeRZJvhMjWqqalQrQ6Ftiz+RsB+819bzEKKukZ u5y6jr74lsFfUFLFXBrk4j0bwX/Llld7a37NyBx0iI+8GSovGAdCeF9LStYgQEAOpyth 79kqpUVko4/aAZ/8Br3lzRM/5kaS0NclB6T14Xl71KDJlelpp0IJUdNugOKVbUC9xU2y YRcDkXUnIquKBLXJO4nYDZ8kdxLJDIhgRpZ0y84YJ8mdFmK0dBUqWZR3KFhxPn/thpLZ /rzQ== 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=24Iss1eEH38zlziYMppNQ3Mtwhda70OL+rcYYmq2Bs0=; b=rTCuFFi1xjqqkSN+xmSArY6aSCFcImJlS+UuRR/6ZQxjqXChJTEGD8YRi4Vi3c4eQM v88t0hNVlODnVhPA4Q5WVlKmBMpsfOwbiiGOrmC16M2lMSeKo7CFR0PoxYRxJNSP5CVR zrNOIcCOd9dv+DQdhmuBoLYqI6HKfHJvHxIzB1WoCrqjSk98pa91qB3WcSUKoKlD3NMZ 9pqLAftJD54hUOJ+d45fBUCwCotAgMnpz/b01dNg9Io1z5L3grSgX401i4bscOxs8a2F EhqbUxlJjfIB+LSq9VzdJe+JVOXz/YINa+IVtEVDu6aANU5GMqxzQeIEb+ZcMIyXElgU b3ag== X-Gm-Message-State: ABuFfoiypgGmVwM6xCt+kX9c5I/As2CnyjSULs0xIj4PXlgK7vm4JoSh OFLdrSJmxkw4mAbilYhOVYLMvc2LbgEgXYfY6GM= X-Google-Smtp-Source: ACcGV61MHVBBzc7Pa0TlN7Bsyi7NMfsVsnshAy0Xr1xXpWId53eL5t+kq8Ehf3xXQPRbdw0qqEgug8KNEDN1qGOAe0k= X-Received: by 2002:ab0:1d0d:: with SMTP id j13mr11838325uak.1.1539142953907; Tue, 09 Oct 2018 20:42:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suhas Nandakumar Date: Tue, 9 Oct 2018 20:42:20 -0700 Message-ID: To: Magnus Westerlund Cc: rtcweb@ietf.org, draft-ietf-rtcweb-sdp@ietf.org Content-Type: multipart/alternative; boundary="00000000000006bdf80577d7a533" Archived-At: Subject: Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 10 Oct 2018 03:42:42 -0000 --00000000000006bdf80577d7a533 Content-Type: text/plain; charset="UTF-8" Hello Magnus Apologies that this took a while. Please see inline. On Wed, Jul 4, 2018 at 7:57 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have reviewed Section 5.3 only with a focus on the simulcast and > multi-stream aspects. For example I have not cared if the ICE details > are correct in these examples. > > Thanks for the review. I have submitted -11 version that should address the review comments. > > A. Section 5.3.1: > > BUNDLE grouping framework enables multiplexing of all the 5 streams > (1 audio stream + 4 video streams) over a single RTP Session. > > It might be good to use RFC 7656 terminology and be specific in that > this results in 5 source RTP streams. > > [Suhas] Done > B. Section 5.3.1. > > As 5.3 says that this will use FEC or RTX and this one doesn't maybe be > explicit that it is not added, or rewrite 5.3. > [Suhas] Update the description to mean some examples have FEC/RTX and not all. The idea was to have this section with examples that cover all these cases but not to have all these in all the examples. > > C. section 5.3.1: > > | a=group:LS m0 m1 | [RFC5888] | > > Is it intentional that video 2 is not included in the lip-synch group? > May require a intention comment for this case. > [Suhas] . The intention was to group one AV in a lip sync group and other can be a non-interactive stream. Updated the text to indicate the same. > D. 5.3.1: > > One video source corresponds to VP8 encoding, while the other > corresponds to H.264 encoding. > > As the m= block represents a media source, if the need is to provide one > video camera's images (the media source) as both VP8 and H.264 where > each are in two different resolutions, then simulcast can handle that > fine within a single m= block. So from my perspective this is a wrongly > constructed example from that premise. Can you please clarify if you > want two media source, i.e. two cameras, or two encoder formats VP8 and > H.264, or two resolutions, or any combination of them? > > I would recommend this example to be two media sources, with encoding > simulcast. The resolution can be skipped as the later example includes > resolution simulcasting. > > [Suhas]. Yes, the example wanted to showcase 2 different media sources (one encoded as vp8 and another as h264, can be natively encoded as well) and each being sent at 2 different resolutions. > E. Section 5.3.1: > > | a=rtcp-fb:* nack | [RFC5104] | > > | a=rtcp-fb:* nack pli | [RFC5104] | > > I would note that generalized NACK as well as picture loss indication > (PLI) is defined in RFC4585. > [Suhas] Done, updated all the references. > > F. Section 5.3.2: > > This section shows an SDP Offer/Answer for a session with an audio > and a single video source. The video source is encoded as layered > coding at 3 different resolutions based on [RFC5583]. The video > m=line shows 3 streams with last stream (payload 100) dependent on > streams with payload 96 and 97 for decoding. > > Also here use of RFC 7656 terminology to talk about (source) RTP streams > when applicable would be good. > [Suhas] Updated. > > G. Section 5.3.2: > > | a=rtpmap:96 H264/90000 | [RFC6184] | > | a=fmtp:96 profile-level-id=4d0028; | [RFC6184]H.264 | > | packetization-mode=1;max-fr=30;max-fs=8040 | Layer 1 | > | a=rtpmap:97 H264/90000 | [RFC6184] | > | a=fmtp:97 profile-level- | [RFC6184] H.264 | > | id=4d0028;packetization-mode=1; max- | Layer 2 | > | fr=15;max-fs=1200 | | > | a=rtpmap:100 H264-SVC/90000 | [RFC6184] | > | a=fmtp:100 profile-level- | [RFC6184] | > | id=4d0028;packetization-mode=1; max- | | > | fr=30;max-fs=8040 | | > | a=depend:100 lay m1:96,97 | [RFC5583]Layer 3 | > > I have my doubts about this configuration. First of all as it is SVC in > Single RTP session mode (SST) I don't think it results in multiple RTP > streams. I think the answerer will interpret this, which of these > encodings can support. A non scalable H.264, another non-scalable H.264 > or SVC that can contain a number of layers. > > Secondly a=depend is only defined for MST mode in RFC 6190. > > You also have the wrong reference for the H-264-SVC a=rtpmap and a=fmtp > line. > [Suhas] Agreed Magnus. On re-reading the example it confused me as well :-) Update the example to represent SST mode SVC configuration. > > H. Section 5.3.3: > > | a=extmap:3 urn:ietf:params:rtp- | [I-D.ietf-avtext-ri | > | hdrext:sdes:rtp-stream-id | d] | > > After this line you should have also this line: > > | a=extmap:4 urn:ietf:params:rtp- | [I-D.ietf-avtext-ri | > | hdrext:sdes:repaired-rtp-stream-id | > d] | > > This to enable the RTX streams to indicate which source RTP stream they > are repairing. Add to both offer and answer. > [Suhas] Good catch. Added it. > > I. Section 5.3.3 > > Why isn't RTX enabled for the audio also? > [Suhas] No Specific reason. These are just examples to show configurations and thus picked MVP configurations to show the usage of SDP for scenario at hand than describing all possible options. > J. Section 5.3.3. Answer: > > | m=video 0 UDP/TLS/RTP/SAVPF 98 100 101 103 | BUNDLE accepted | > > Payload types 100 and 101 are undefined in this media description. > [Suhas] Thanks for catching this. Matched the answer with the offer now. > > K. Section 5.3.4 Answer: > > | a=rtpmap:101 VP8/90000 | [RFC7741] | > > Wrong media type for the payload should be RTX. > [Suhas] Nice find. Fixed it. > > L. Section 5.3.4 Answer: > > Missing rtcp-fb definitions to enable use of NACK which RTX depends on. > > [Suhas] Agreed. Added it. > > M. Section 5.3.5: > > | a=fmtp:101 L=5; D=10; ToP=2; repair- | [I-D.ietf-payload-f | > | window=200000 | lexible-fec-scheme] | > | a=fmtp:103 L=5; D=10; ToP=2; repair- | [I-D.ietf-payload-f | > | window=200000 | lexible-fec-scheme] | > > As the parameters are the same, I don't see a point with having two > payload types. Two different RTP repair streams can use the same payload > type. As Flex-FEC can do all the binding using the CSRC field, there are > also no need to have the repaired-rtp-stream-id header extension for > this one. > [Suhas] Good point. Moved to just one PT. Also i think you intend to include repaired-rtp-stream-id for this example too ? > N. Section 5.3.5: > > Does it make sense to still have NACK for a session with FEC. If it > fails isn't PLI or FIR > [Suhas] Dont think its needed. Removed nack and kept pli > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, 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 > --00000000000006bdf80577d7a533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Magnus

=C2=A0Apologies that this = took a while. Please see inline.

On Wed, Jul 4, 2018 at 7:57 AM Magnus Westerlund <magnus.westerlund@= ericsson.com> wrote:
Hi,

I have reviewed Section 5.3 only with a focus on the simulcast and
multi-stream aspects. For example I have not cared if the ICE details
are correct in these examples.

Thanks for the review. I have submitted -11 version t= hat should address the review comments.
=C2=A0

A. Section 5.3.1:

BUNDLE grouping framework enables multiplexing of all the 5 streams
=C2=A0=C2=A0=C2=A0 (1 audio stream + 4 video streams) over a single RTP Ses= sion.

It might be good to use RFC 7656 terminology and be specific in that
this results in 5 source RTP streams.


[Suhas] Done
=C2=A0
B. Section 5.3.1.

As 5.3 says that this will use FEC or RTX and this one doesn't maybe be=
explicit that it is not added, or rewrite 5.3.

[Suhas] Update the description to mean some examples have FEC/RTX a= nd not all.
The idea was to have this section with examples that = cover all these cases but=C2=A0
not to have all these in all the = examples.=C2=A0

C. section 5.3.1:

=C2=A0=C2=A0=C2=A0 | a=3Dgroup:LS m0 m1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5888]=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

Is it intentional that video 2 is not included in the lip-synch group?
May require a intention comment for this case.

[Suhas] . The intention was to group one AV in a lip sync=C2=A0
group and other can be a non-interactive stream. Updated the text to= =C2=A0
indicate the same.=C2=A0


D. 5.3.1:

=C2=A0=C2=A0=C2=A0 One video source corresponds to VP8 encoding, while the = other
=C2=A0=C2=A0=C2=A0 corresponds to H.264 encoding.

As the m=3D block represents a media source, if the need is to provide one =
video camera's images (the media=C2=A0 source) as both VP8 and H.264 wh= ere
each are in two different resolutions, then simulcast can handle that
fine within a single m=3D block. So from my perspective this is a wrongly <= br> constructed example from that premise. Can you please clarify if you
want two media source, i.e. two cameras, or two encoder formats VP8 and H.264, or two resolutions, or any combination of them?

I would recommend this example to be two media sources, with encoding
simulcast. The resolution can be skipped as the later example includes
resolution simulcasting.


[Suhas]. Yes, the example wanted to sh= owcase 2 different media sources (one encoded
=C2=A0as vp8 and an= other as h264, can be natively encoded as well) and=C2=A0 each being sent a= t
=C2=A02 different resolutions.=C2=A0
=C2=A0
E. Section 5.3.1:

=C2=A0=C2=A0=C2=A0 | a=3Drtcp-fb:* nack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5104]=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 | a=3Drtcp-fb:* nack pli=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5104]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

I would note that generalized NACK as well as picture loss indication
(PLI) is defined in RFC4585.

[Suhas] Do= ne, updated all the references.
=C2=A0

F. Section 5.3.2:

=C2=A0=C2=A0=C2=A0 This section shows an SDP Offer/Answer for a session wit= h an audio
=C2=A0=C2=A0=C2=A0 and a single video source.=C2=A0 The video source is enc= oded as layered
=C2=A0=C2=A0=C2=A0 coding at 3 different resolutions based on [RFC5583].=C2= =A0 The video
=C2=A0=C2=A0=C2=A0 m=3Dline shows 3 streams with last stream (payload 100) = dependent on
=C2=A0=C2=A0=C2=A0 streams with payload 96 and 97 for decoding.

Also here use of RFC 7656 terminology to talk about (source) RTP streams when applicable would be good.

[Suhas] = Updated.=C2=A0

G. Section 5.3.2:

=C2=A0=C2=A0 | a=3Drtpmap:96 H264/90000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:96 profile-level-id=3D4d0028;=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6184]H.264=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | packetization-mode=3D1;max-fr=3D30;max-fs=3D8040=C2=A0= | Layer 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:97 H264/90000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:97 profile-level-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | [RFC6184] H.264=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | id=3D4d0028;packetization-mode=3D1; max-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Layer 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | fr=3D15;max-fs=3D1200 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:100 H264-SVC/90000=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | = [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:100 profile-level-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
=C2=A0=C2=A0=C2=A0 | id=3D4d0028;packetization-mode=3D1; max- |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | fr=3D30;max-fs=3D8040 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Ddepend:100 lay m1:96,97=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | [RFC5583]Layer 3=C2=A0=C2=A0=C2=A0 |

I have my doubts about this configuration. First of all as it is SVC in Single RTP session mode (SST) I don't think it results in multiple RTP =
streams. I think the answerer will interpret this, which of these
encodings can support. A non scalable H.264, another non-scalable H.264 or SVC that can contain a number of layers.

Secondly a=3Ddepend is only defined for MST mode in RFC 6190.

You also have the wrong reference for the H-264-SVC a=3Drtpmap and a=3Dfmtp=
line.

[Suhas] Agreed Magnus. On re-read= ing the example it confused me as well :-)
Update the example to = represent SST mode SVC configuration.
=C2=A0

H. Section 5.3.3:

=C2=A0=C2=A0=C2=A0 | a=3Dextmap:3 urn:ietf:params:rtp-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-avtext-ri |=
=C2=A0=C2=A0=C2=A0 | hdrext:sdes:rtp-stream-id=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | d]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

After this line you should have also this line:

=C2=A0=C2=A0=C2=A0 | a=3Dextmap:4 urn:ietf:params:rtp-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-avtext-ri |=
=C2=A0=C2=A0=C2=A0 | hdrext:sdes:repaired-rtp-stream-id=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
d]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

This to enable the RTX streams to indicate which source RTP stream they are repairing. Add to both offer and answer.

[Suhas] Good catch. Added it.
=C2=A0

I. Section 5.3.3

Why isn't RTX enabled for the audio also?

[Suhas] No Specific reason. These are just examples to show configur= ations and thus picked MVP=C2=A0
configurations to show the usage= of SDP for scenario at hand than describing all possible=C2=A0
o= ptions.


J. Section 5.3.3. Answer:

=C2=A0=C2=A0 | m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 101 103=C2=A0 | BUNDLE = accepted=C2=A0=C2=A0=C2=A0=C2=A0 |

Payload types 100 and 101 are undefined in this media description.

[Suhas] Thanks for catching this. Matched the a= nswer with the offer now.
=C2=A0

K. Section 5.3.4 Answer:

=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:101 VP8/90000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | [RFC7741]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

Wrong media type for the payload should be RTX.

[Suhas] Nice find. Fixed it.=C2=A0=C2=A0

L. Section 5.3.4 Answer:

Missing rtcp-fb definitions to enable use of NACK which RTX depends on.


[Suhas] Agreed. Added it.
= =C2=A0

M. Section 5.3.5:

=C2=A0=C2=A0| a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-payload-f |
=C2=A0=C2=A0=C2=A0 | window=3D200000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | lexibl= e-fec-scheme] |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; repair-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-payload-f |
=C2=A0=C2=A0=C2=A0 | window=3D200000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | lexibl= e-fec-scheme] |

As the parameters are the same, I don't see a point with having two payload types. Two different RTP repair streams can use the same payload type. As Flex-FEC can do all the binding using the CSRC field, there are also no need to have the repaired-rtp-stream-id header extension for
this one.

[Suhas] Good point. Moved to = just one PT. Also i think you intend to=C2=A0
include=C2=A0 repai= red-rtp-stream-id for this example too ?


N. Section 5.3.5:

Does it make sense to still have NACK for a session with FEC. If it
fails isn't PLI or FIR

[Suhas] Dont= think its needed. Removed nack and kept pli=C2=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000006bdf80577d7a533-- From nobody Tue Oct 9 20:44:22 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735B130E60; Tue, 9 Oct 2018 20:44:19 -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 nUjURcPVOoFk; Tue, 9 Oct 2018 20:44:17 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 C8CB2130E17; Tue, 9 Oct 2018 20:44:16 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id r83so3711634vsc.4; Tue, 09 Oct 2018 20:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HxafDe689QhjnyzWY90BVLa+J8XuV5X9vBkMPs6FQAw=; b=FbQ2F/H/TcXY7BafU4xb4emn1pmu03zlAFYtOamiUzBnw8A982BtCZSTy3MUxygqUi vNFYs4CESckG+rHJ/KI08EVMfO206AHiU2Chxx43vVD8K1gEcY1+4a6lBVWDRcssq5We f+LJ+jrzhdb2D8lGOCa94JLf2E5i2WG4wAMcsgdGP04CuT1iPj6SPHD5UzCp1Jckj0oX F6kwjjew1+mdmJQDU8HpfA2B6CfXHmQv6w8MGKNNK9wfIVRuC7GVn6+ADn7cIXGATUoN OotfpLT80ENF++c7IQG0iOU05nbrHLSzvn4Zz9oDA/qyyPENHpygKzNipcq5OQh0XkmD rAww== 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=HxafDe689QhjnyzWY90BVLa+J8XuV5X9vBkMPs6FQAw=; b=pDTISCpUFkzk+1cYcs2eblX2vd6AoZZyucfsdINqchyNVogYzLzEmH/1Ptzg8BuiGl /7gZvx4JAzLEg5IUNW5jGTkT5R9PUfWNvvPyKpZmVj4bc5yk78BWCElbuIAOFMoUXk0l Fr2Z6YoOWxL0G/WJhNzm+tQvhMQ32y9t9mdZjsRo25TAOdVkaD+sY0jLHUKAOS6TconH 2pllGyNUpijz0RyqIoVMJLgIFwNuQUWMywKrcbqDbpESVTJ7hbB1QKiKFc7OnbewqSp2 lltThk9TY7GO0nh58CiIeJ+enrgja1HPVjuVQaNYIYBQ4Jirt34udiuym2+hT5ekPlMX +myQ== X-Gm-Message-State: ABuFfogSky7MwrVyErjSR7IS13mikPfUmoinettrDCJIrYnsq9WL6JNH BV0u2vv5vJfcSY9JwuCvQ2cqyT2WcEDmu6vTgp8= X-Google-Smtp-Source: ACcGV60AyjQ2pH+/LCpGlkoanXsgvMuxDYmNn2uVD5BgYUkmOAtdg5nLG6eyjKdDn6ywEUYrpuFn7yaew9PkFnsevlM= X-Received: by 2002:ab0:1d0d:: with SMTP id j13mr11839672uak.1.1539143055845; Tue, 09 Oct 2018 20:44:15 -0700 (PDT) MIME-Version: 1.0 References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com> In-Reply-To: From: Suhas Nandakumar Date: Tue, 9 Oct 2018 20:44:03 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , rtcweb-chairs@ietf.org, rtcweb@ietf.org, IESG Secretary Content-Type: multipart/alternative; boundary="0000000000001a2e1f0577d7abe5" Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 10 Oct 2018 03:44:20 -0000 --0000000000001a2e1f0577d7abe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All We just submitted version -11 that address the following 1. Magnus Review Comments 2. Move from RFC5245 to RFC8445 and ice-sip-sdp for ICE attributes 3. Added an ice2 example Please let me know if you have any questions Thanks Suhas/Cullen On Sat, Oct 6, 2018 at 12:15 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Thanks! =F0=9F=98=8A > > > Regards, > > > Christer > > > ------------------------------ > *From:* Cullen Jennings > *Sent:* Saturday, October 6, 2018 4:43 AM > *To:* Christer Holmberg > *Cc:* Ted Hardie; Adam Roach; RTCWeb IETF; IESG Secretary; > rtcweb-chairs@ietf.org; Sean Turner > *Subject:* Re: [rtcweb] Publication has been requested for > draft-ietf-rtcweb-sdp-10 > > > Christer, > > Just as FYI =E2=80=A6 Suhas and I are working on a PR for sdp draft that = moves the > examples to be consistent with ice2. > > Cullen > > > > > On Oct 5, 2018, at 7:00 PM, Sean Turner wrote: > > > > We can as long as we identify that we have outstanding issues in the > Shepherd write-up (it does) and the AD is willing (I believe he is or we > will shortly find out that he is not). Note that I also asked Magnus if = he > was okay with us dealing with his comments along with the other IETF LC > comments and he was. > > > > spt > > > >> On Oct 5, 2018, at 16:24, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> > >> Hi, > >> > >> I am just wondering why we are making publication request when we know > changes are still needed. > >> > >> Regards, > >> > >> Christer > >> > >> > >> From: Sean Turner > >> Sent: Friday, October 5, 2018 1:43 AM > >> To: Christer Holmberg > >> Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; > rtcweb-chairs@ietf.org > >> Subject: Re: [rtcweb] Publication has been requested for > draft-ietf-rtcweb-sdp-10 > >> > >> Yes and whole lot more drafts: > >> https://www.rfc-editor.org/cluster_info.php?cid=3DC238 > [C238] =C2=BB RFC Editor > www.rfc-editor.org > 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) REF = . > draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio PUB; > draft-ietf-rtcweb ... > > > >> [C238] =C2=BB RFC Editor > >> www.rfc-editor.org > >> 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) > REF . draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio PU= B; > draft-ietf-rtcweb ... > >> > >> > >> > >> spt > >> > >>> On Oct 4, 2018, at 14:59, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >>> > >>> Hi, > >>> > >>> Assuming we are going to do the ICE reference update, this draft is > affected too. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> From: rtcweb on behalf of Ted Hardie < > ted.ietf@gmail.com> > >>> Sent: Thursday, October 4, 2018 9:50 PM > >>> To: adam@nostrum.com > >>> Cc: rtcweb@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org > >>> Subject: [rtcweb] Publication has been requested for > draft-ietf-rtcweb-sdp-10 > >>> > >>> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-10 as > Informational on behalf of the RTCWEB working group. > >>> > >>> Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > >>> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC > >>> datatracker.ietf.org > >>> Annotated Example SDP for WebRTC (Internet-Draft, 2018) > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > --0000000000001a2e1f0577d7abe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All

=C2=A0 We just submitted version= -11 that address the following

1. Magnus Review C= omments
2. Move from RFC5245 to RFC8445 and ice-sip-sdp for ICE a= ttributes
3. Added an ice2 example

Pleas= e let me know if you have any questions

Thanks
Suhas/Cullen


On Sat, Oct 6, 2018 at 12:15 PM Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Thanks! =F0=9F=98=8A=


Regards,


Christer



From:= Cullen Jennings <flu= ffy@iii.ca>
Sent: Saturday, October 6, 2018 4:43 AM
To: Christer Holmberg
Cc: Ted Hardie; Adam Roach; RTCWeb IETF; IESG Secretary; rtcweb-chairs@ietf.org= ; Sean Turner
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-= rtcweb-sdp-10
=C2=A0

Christer,

Just as FYI =E2=80=A6 Suhas and I are working on a PR for sdp draft that mo= ves the examples to be consistent with ice2.

Cullen



> On Oct 5, 2018, at 7:00 PM, Sean Turner <sean@sn3rd.com> wrote:
>
> We can as long as we identify that we have outstanding issues in the S= hepherd write-up (it does) and the AD is willing (I believe he is or we wil= l shortly find out that he is not).=C2=A0 Note that I also asked Magnus if = he was okay with us dealing with his comments along with the other IETF LC comments and he was.
>
> spt
>
>> On Oct 5, 2018, at 16:24, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:
>>
>> Hi,
>>
>> I am just wondering why we are making publication request when we = know changes are still needed.
>>
>> Regards,
>>
>> Christer
>>
>>
>> From: Sean Turner <sean@sn3rd.com>
>> Sent: Friday, October 5, 2018 1:43 AM
>> To: Christer Holmberg
>> Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; rtcweb-chairs@ietf.org
>> Subject: Re: [rtcweb] Publication has been requested for draft-iet= f-rtcweb-sdp-10
>>
>> Yes and whole lot more drafts:
>> https://www.rfc-editor.org/cluster_info.php?cid=3DC238
[C238] =C2=BB RFC Editor
www.rfc-editor.org<= /a>
2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) REF . = draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio PUB; draft= -ietf-rtcweb ...


>> [C238] =C2=BB RFC Editor
>> www.rfc-editor.org
>> 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1= G) REF . draft-ietf-rtcweb-overview MISSREF*R(1G) draft-ietf-rtcweb-audio P= UB; draft-ietf-rtcweb ...
>>
>>
>>
>> spt
>>
>>> On Oct 4, 2018, at 14:59, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:
>>>
>>> Hi,
>>>
>>> Assuming we are going to do the ICE reference update, this dra= ft is affected too.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Ted Hardie <= ;ted.ietf@gmail.com= >
>>> Sent: Thursday, October 4, 2018 9:50 PM
>>> To: adam= @nostrum.com
>>> Cc: rtcwe= b@ietf.org; iesg-secretary@ietf.org; rtcweb-chairs@ietf.org
>>> Subject: [rtcweb] Publication has been requested for draft-iet= f-rtcweb-sdp-10
>>>
>>> Ted Hardie has requested publication of draft-ietf-rtcweb-sdp-= 10 as Informational on behalf of the RTCWEB working group.
>>>
>>> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/
>>> draft-ietf-rtcweb-sdp-10 - Annotated Example SDP for WebRTC >>> data= tracker.ietf.org
>>> Annotated Example SDP for WebRTC (Internet-Draft, 2018)
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000001a2e1f0577d7abe5-- From nobody Wed Oct 10 07:13:22 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59055130F3C for ; Wed, 10 Oct 2018 07:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=unavailable 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 kvdJjBPtwjUV for ; Wed, 10 Oct 2018 07:13:18 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 A3D3D130F39 for ; Wed, 10 Oct 2018 07:13:18 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id u34-v6so5776164qth.3 for ; Wed, 10 Oct 2018 07:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nFlo7W7oP7Enm5KHToYO/Bku8NynnmjPkKOGa2Hm7Mo=; b=TFRF6KHNmC2O6AOIa87U4XLdb+sw9r252fJ2ExmZ6wQlyyDRq+kYSMDv80emU4zuUN YKs+EbFO97HoJ5HTlx2XmVN+t1SeQy/LZfcvlRUfr22B0RVZjB936kf/M/WTBlynwIhv 9rxYQNSGUfwIJth7JUrZnZFAlrZr6gEv30sZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nFlo7W7oP7Enm5KHToYO/Bku8NynnmjPkKOGa2Hm7Mo=; b=HVAATJOvF2Yi9ZjLZ8BYvAplwrbMefPzPBlhxMG9K0blAPA45vPYbBNg/keBLObl5H Xd4oRenvKN9kCo9AKPtwCu9eVTE/6rSwbBqN7njAL5WnzlbZZ90xKaNOaYUqSmX4zK2T tYXaEQMe5qgimJC4uZ3m74DEI8QSrDP8A8OkHBRGHFLxQQ9NdpwGt0x+37LX00GyDjsl 08uWJVBvfax/fu8ba3gRtREvJcU9N3mnjlM5isIbI564EJifMTMtmMMeS2uNT+OY03RC xPDLdTqAfQex29kdGyMhgB/51a7GhiTxTa+mJb9Gw7x82W96GEnh1cLxK4zC4dvn0uqk RZFw== X-Gm-Message-State: ABuFfoilzgooB61pjfPyc/XkZAjOW1vrR2hCZVYaAduDW0iePjmy4fFs y2XI5oc/iNmIgTCLCz2BWHsnww== X-Google-Smtp-Source: ACcGV61/j9znw/Sje7W2i16NSGO/qV2v3F0p9i7WrtDh3qdRUbpyZg0JSX4R6pKZCN2aU1wPouAB3Q== X-Received: by 2002:ac8:955:: with SMTP id z21-v6mr28378150qth.305.1539180797795; Wed, 10 Oct 2018 07:13:17 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id o55-v6sm13606459qtk.58.2018.10.10.07.13.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 07:13:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Wed, 10 Oct 2018 10:13:13 -0400 Cc: rtcweb-chairs@ietf.org, RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8F870406-6588-4FA9-9F97-B47B6BBF450A@sn3rd.com> References: <153867902499.4550.6785559633460278610.idtracker@ietfa.amsl.com> <88A35847-7DAD-4E6B-99DE-E780DEE48626@sn3rd.com> <90696953-881B-4472-B53F-F43C3DF231C0@sn3rd.com> To: Suhas Nandakumar , Cullen Jennings X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 10 Oct 2018 14:13:21 -0000 Thanks for helping us get done! spt > On Oct 9, 2018, at 23:44, Suhas Nandakumar = wrote: >=20 > Hi All >=20 > We just submitted version -11 that address the following >=20 > 1. Magnus Review Comments > 2. Move from RFC5245 to RFC8445 and ice-sip-sdp for ICE attributes > 3. Added an ice2 example >=20 > Please let me know if you have any questions >=20 > Thanks > Suhas/Cullen >=20 >=20 > On Sat, Oct 6, 2018 at 12:15 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: >=20 >> Thanks! =F0=9F=98=8A >>=20 >>=20 >> Regards, >>=20 >>=20 >> Christer >>=20 >>=20 >> ------------------------------ >> *From:* Cullen Jennings >> *Sent:* Saturday, October 6, 2018 4:43 AM >> *To:* Christer Holmberg >> *Cc:* Ted Hardie; Adam Roach; RTCWeb IETF; IESG Secretary; >> rtcweb-chairs@ietf.org; Sean Turner >> *Subject:* Re: [rtcweb] Publication has been requested for >> draft-ietf-rtcweb-sdp-10 >>=20 >>=20 >> Christer, >>=20 >> Just as FYI =E2=80=A6 Suhas and I are working on a PR for sdp draft = that moves the >> examples to be consistent with ice2. >>=20 >> Cullen >>=20 >>=20 >>=20 >>> On Oct 5, 2018, at 7:00 PM, Sean Turner wrote: >>>=20 >>> We can as long as we identify that we have outstanding issues in the >> Shepherd write-up (it does) and the AD is willing (I believe he is or = we >> will shortly find out that he is not). Note that I also asked Magnus = if he >> was okay with us dealing with his comments along with the other IETF = LC >> comments and he was. >>>=20 >>> spt >>>=20 >>>> On Oct 5, 2018, at 16:24, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I am just wondering why we are making publication request when we = know >> changes are still needed. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>> From: Sean Turner >>>> Sent: Friday, October 5, 2018 1:43 AM >>>> To: Christer Holmberg >>>> Cc: Ted Hardie; Adam Roach; rtcweb@ietf.org; IESG Secretary; >> rtcweb-chairs@ietf.org >>>> Subject: Re: [rtcweb] Publication has been requested for >> draft-ietf-rtcweb-sdp-10 >>>>=20 >>>> Yes and whole lot more drafts: >>>> https://www.rfc-editor.org/cluster_info.php?cid=3DC238 >> [C238] =C2=BB RFC Editor = >> www.rfc-editor.org >> 2014-12-12 | draft-ietf-rmcat-cc-requirements-09.txt | MISSREF*R(1G) = REF From nobody Thu Oct 11 00:24:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D06130E44 for ; Thu, 11 Oct 2018 00:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=P1sO7OeY; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lWakRw7/ 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 STHInKOp1fZ9 for ; Thu, 11 Oct 2018 00:24:45 -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 0F5F3130E3A for ; Thu, 11 Oct 2018 00:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539242683; x=1541834683; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=STdrQdvpM3MV1k2uMMb2+guq7O0T1m6A5c5TuClTaqk=; b=P1sO7OeYh3ac6S/ad3SUwUDRU/MkEopa7htXiqFCiYOXIokmFSOYGjx76Ww0giGA TRrG2c+bzU7vN/tvMJvjO6PttWwqRI2MwoFQynNgvWcHN40hk7xOC6Q9/q1ALdRo iN9wORoMkY6GcDlcz27JDw/J+ORPEiv8qxU+KFbjO4Y=; X-AuditID: c1b4fb3a-604d59e0000012ff-d3-5bbefabb7242 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.3C.04863.BBAFEBB5; Thu, 11 Oct 2018 09:24:43 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 11 Oct 2018 09:23:54 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 11 Oct 2018 09:23:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=STdrQdvpM3MV1k2uMMb2+guq7O0T1m6A5c5TuClTaqk=; b=lWakRw7/4I44CyiBzgv4+ybyumpaHRJMcGko6EGQZ/UxZETkx6c0CspPHizedP34Qm5Limbq+hsSudStEiVvAdEUOx7BEYfcT/xO1xPrJ2s9I8/8F/+Kqa5k88cLkCvbMmq1tktz4W4qZsJDn6JUSKqnEHEXvsqiWLtASzAokAA= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB4510.eurprd07.prod.outlook.com (20.177.56.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.8; Thu, 11 Oct 2018 07:23:53 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 07:23:53 +0000 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: A couple of questions on SDP Identity attribute Thread-Index: AQHUYTNdgdx0fYUyP0+ZCWsqcc6KnQ== Date: Thu, 11 Oct 2018 07:23:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.11.0.180909 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4510; 6:p4o9dTY02uT04Eosxwdje9c53B+smQL8SBmgtVCiaweZ+63WoY/B8v3wrLZeaZ6bvw0snHZFy99KMcDFcTx71tawxVguxuZGbVxwA+UxnsQOrcjVKDcs8uGDr/pLN04cY62REEHsb7nVGHtNxkXAsk6oktBDcpvYlJWm48IOf7fDBcLQP25akFOboSFwdwk8W3t543wO55MS/h5/Wx/9cxoCt/CF9nt6zv1gYsIfxotMoOxseJHV6Lb1PpduOrBRd4VtaGVuBvH86VJE4jazsDpkvYw1K8k181DoLiKTqw1ciznar5O4C8/Rr1ebCQniNQEDkfy7XJjzdRgEFEOcPHZD5vJIydlwwGvvYfBwWi0tCStwiWnCd9wodMTBq6RLU1QMjFRcQCggba1+F8XswHXpfLx3qfoGEjbH9YnhqMPVP80LTrvuJvxQTabnKPL6qwKx/DgsYXzh7s/1I6hGCQ==; 5:D2hjUEItjXSRQo3SO0W2m1efhcGimtjCyPKVB8rBMVr8hZSTLIM6JRmn1b96/veFi/M+M7lqlkomqvjK/KQZvV1MzGK+3PEHiO5h7oU7NTPGSFDyHPEyzitSEsTzDpd9n2NhSfq9ea9VlgROmH1zDMlyz85pSEA2YDG6ilRnBTQ=; 7:KSLGhf0YDDInJUZ1Viqd5h1QBdEf2xt/SVREIjj7myLx3pA/AsAVDjmyw/G5q+4iLYURJHY9ZUyVRV+lj9t+nkm5jB3OJRMwGAmpmgRCOtLsUhpk/3+/gBHIMsEF/aQSlB3IvLxJR6a3qvJzLuMle5mMv6Fqw/0fkB/IiyZvBXyqNAGUG0wMtHvqyEbEOt/zl6SkGM0WBWRhbvaJkGLaSrbaUcORLwGUxvfuuFJ47MpFhPwSa1yAejj3KOx8EMBx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 72f41602-569b-4136-6307-08d62f4a7f93 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4510; x-ms-traffictypediagnostic: VI1PR07MB4510: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR07MB4510; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4510; x-forefront-prvs: 08220FA8D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(136003)(366004)(346002)(189003)(199004)(36756003)(2900100001)(68736007)(256004)(58126008)(33656002)(102836004)(6506007)(66066001)(99286004)(478600001)(71200400001)(83716004)(71190400001)(97736004)(2906002)(3846002)(14454004)(81156014)(81166006)(1730700003)(8676002)(8936002)(2501003)(6116002)(105586002)(106356001)(82746002)(316002)(2351001)(5250100002)(44832011)(186003)(5640700003)(6436002)(25786009)(53936002)(26005)(6306002)(6512007)(6916009)(54896002)(2616005)(7736002)(486006)(6486002)(476003)(5660300001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4510; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CESO05ifONsjTJY7ECL6m6f+P9XqJeysj9GFgI5z2Eg4pbBjFlOeA5tqnoAbYqQda99wge63qP19vX/3nBvTi8y/dXVAxGWBCRQDdeXFSa3OLWS5uL/igPY3X/2MfUcF22R+Je0tsUiBXsrJvVQ4bI3QVJBoCoYzWpMZmK33tCy2Nwmz8EAg6dKNuvTJotVuTkkk40xZAjYvD64kmCTgFN89VPUD++7uuPqRKev/bngM4eHXFGBWpzXs0T4CGv4fcPsJ75ts30OSnQR262u+ruYXRdSZuQ9oGGpBQiS6UR7p1abz33d1VUV0aZuGvJngcn5lqDBnPxkRQcQcNhJsKYawp0LAvuY4wtpw3E53dZ4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BA554505711E4E678C66A76A442034E7ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72f41602-569b-4136-6307-08d62f4a7f93 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 07:23:53.2914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4510 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGOffeea/LwWlp/jOLXJRp6EwizDRL+iBF2IciUaiG3nSoU3aX aCSsJDQlNFFrU5nl0Bpapo50ylJDwjIMJVKL4aZMlIowMd9a7e4u8NvvPC8HnsNhSGmrKIhR qjSsWqXIkfmIKV3Kq8KIvnVrWlRJbWBMu6uUPoWSjMY14gJKFcdlsDnKAlYtP3lNnGV7s0Ln 94QWdjd3UFpkOFiOfBnAR6HEto7KkZiR4mEEDR1dJG9I8QqCUWexYBgJeNzrJPgDhatIWH4w JRKcagKW5t+TwsGBoK2rlC5HDOODY6DCdZi/yh+HwoT9I83zDrf8vGaZEPR46Oqp83IkVN92 IZ4pfABm6x0eXYITwDXqpHhGeCf8ftfm0UkcCNNzBkLYgMHYP0YKHAALsy4RzwFYDoaZMpHQ VcBr04w3EwIffti93T0wbqjw7AdspeGX1SoSjAj4WVvrLtBuPg9lyULkLYJni4uUEAkH18CA N54N9ZMOr54DHd83kcB7wXTfTgllMwnDlauIfx/AwWBr1VShSP2WOXq3Q+J0WGn303vWb4cR 3RwlyGHwwiIX0iFQU2GnBT4EdxsavZwEvWN3iK2ZJsSYUADHclxuZnR0JKtWpnNcnipSxWo6 kfv7DHZvxPagwfnTQwgzSOYnsa1a06QiRQFXlDuEgCFl/hL5I7ckyVAU3WTVeVfVN3JYbgjt ZihZoCTxekyqFGcqNGw2y+az6v8uwfgGaVFYx9PEe1qzY+nK1MZEU11ITfKZfccvtWT7yjOW 5kdMxRsRfZbJsvIsy0Ljp8cnXvav6VI0Fu142rGRBGOsbfOJsvvrX8q30oW0KZ/ps3+2pe0a uJUd7xyc1td/03VeHtS2WFWV8YaoxIv7gwvyA8MfmoNG/RvPxZlNzV9IsSRBRnFZiiPhpJpT /ANGJ7LJOgMAAA== Archived-At: Subject: [rtcweb] A couple of questions on SDP Identity attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 11 Oct 2018 07:24:47 -0000 --_000_BA554505711E4E678C66A76A442034E7ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkEgY291cGxlIG9mIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHNvbWUgY29tbWVudHMgb24g R2l0SHViOg0KDQpRMTogSW4gYW4gb2ZmZXIgb3IgYW5zd2VyLCBpdCBhbGxvd2VkIHRvIGluY2x1 ZGUgZmluZ2VycHJpbnRzIHRoYXQgaGF2ZSBOT1QgYmVlbiB1c2VkIHRvIGFzc2VydCB0aGUgaWRl bnRpdHk/DQoNClEyOiBJZiBvbmUgb3IgbW9yZSBvZiB0aGUgZmluZ2VycHJpbnRzIHVzZWQgdG8g YXNzZXJ0IHRoZSBpZGVudGl0eSBjaGFuZ2UsIEkgYXNzdW1lIHRoYXQgdGhlIElkZW50aXR5IGF0 dHJpYnV0ZSB2YWx1ZSB3aWxsIGFsd2F5cyBjaGFuZ2VzIGEgcmVzdWx0PyBPciwgaXMgdGhlcmUg YSBjaGFuY2UgdGhhdCBkaWZmZXJlbnQgZmluZ2VycHJpbnRzIHdvdWxkIHByb2R1Y2UgdGhlIHNh bWUgSWRlbnRpdHkgYXR0cmlidXRlIHZhbHVlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg== --_000_BA554505711E4E678C66A76A442034E7ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <56D6184B0829BC48B370C8AD8FEFA609@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkZJIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QSBjb3VwbGUgb2Yg cXVlc3Rpb25zIHJlbGF0ZWQgdG8gc29tZSBjb21tZW50cyBvbiBHaXRIdWI6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlExOiBJbiBhbiBvZmZlciBvciBhbnN3ZXIsIGl0IGFsbG93ZWQgdG8gaW5jbHVkZSBmaW5nZXJw cmludHMgdGhhdCBoYXZlIE5PVCBiZWVuIHVzZWQgdG8gYXNzZXJ0IHRoZSBpZGVudGl0eT8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5RMjogSWYgb25lIG9yIG1vcmUgb2YgdGhlIGZpbmdlcnByaW50cyB1c2VkIHRv IGFzc2VydCB0aGUgaWRlbnRpdHkgY2hhbmdlLCBJIGFzc3VtZSB0aGF0IHRoZSBJZGVudGl0eSBh dHRyaWJ1dGUgdmFsdWUgd2lsbCBhbHdheXMgY2hhbmdlcyBhIHJlc3VsdD8gT3IsIGlzIHRoZXJl IGEgY2hhbmNlIHRoYXQgZGlmZmVyZW50IGZpbmdlcnByaW50cw0KIHdvdWxkIHByb2R1Y2UgdGhl IHNhbWUgSWRlbnRpdHkgYXR0cmlidXRlIHZhbHVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BA554505711E4E678C66A76A442034E7ericssoncom_-- From nobody Thu Oct 11 04:02:06 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924B2130E47 for ; Thu, 11 Oct 2018 04:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9McZfsLTiRNi for ; Thu, 11 Oct 2018 04:02:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293A2130DD5 for ; Thu, 11 Oct 2018 04:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 95F567C3DCF for ; Thu, 11 Oct 2018 13:01:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7133nD4Qgl1 for ; Thu, 11 Oct 2018 13:01:58 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id DF67A7C35A8 for ; Thu, 11 Oct 2018 13:01:57 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <19e47597-e90c-ebba-3467-25e511bed661@alvestrand.no> Date: Thu, 11 Oct 2018 13:01:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 11 Oct 2018 11:02:04 -0000 Den 11. okt. 2018 09:23, skrev Christer Holmberg: > Hi, > >   > > A couple of questions related to some comments on GitHub: > >   > > Q1: In an offer or answer, it allowed to include fingerprints that have > NOT been used to assert the identity? I don't understand the question..... if you don't assert an identity, there are of course fingerprints that have not been used to assert the identity. Was the question about the case where you include an identity attribute? > >   > > Q2: If one or more of the fingerprints used to assert the identity > change, I assume that the Identity attribute value will always changes a > result? Or, is there a chance that different fingerprints would produce > the same Identity attribute value? A fingerprint can't really "change". There may be new fingerprints because of new hash functions added (though that would be strange over the time of a call), or because new certificates were added to the session. > >   > > Regards, > >   > > Christer > >   > >   > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Oct 11 04:27:17 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A14130E58 for ; Thu, 11 Oct 2018 04:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=DE1y/h9S; dkim=pass (1024-bit key) header.d=ericsson.com header.b=j3NEnJ2D 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 40PZA3FL1Kn9 for ; Thu, 11 Oct 2018 04:27:12 -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 1CE54130E5A for ; Thu, 11 Oct 2018 04:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539257230; x=1541849230; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AOqcIYwCBL1fe42sP1Qx6R47QjgXE4lmYY2Oju1VcTM=; b=DE1y/h9Sl4t8U2K0EOzBoRV3WZms3ecs4WhCX0Z7CMlY1/IlrHbji6NYh4GTions d1gEKui4pXij7Kiwmh1WuHp9qfqq0JlojcX9WMWFnl8Kt+1jS+PZ0jh66am9mCWZ SU8rCEFWE27Q03L4T6kbl/X9Y9z73PoDetYIRqVFkCY=; X-AuditID: c1b4fb30-776849e0000047d2-c1-5bbf338ebccf Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.CF.18386.E833FBB5; Thu, 11 Oct 2018 13:27:10 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 11 Oct 2018 13:27:07 +0200 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 11 Oct 2018 13:27:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOqcIYwCBL1fe42sP1Qx6R47QjgXE4lmYY2Oju1VcTM=; b=j3NEnJ2DOfh++B336OqNIYN9aF5koC6LH6szG9/J9rAHEKKt8P69OQzmvwYdyMNDUxmZkNV19JDdhPzkiB06DCnN7DfGkPafaPtGMrePf5GWfMA2WMTlSaphgFyiNYUXsmDPzCoWB/KXO9wzgGdvR7DqgAo+IkPcMgeYlwFhONw= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB3485.eurprd07.prod.outlook.com (10.175.244.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Thu, 11 Oct 2018 11:27:07 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 11:27:07 +0000 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A couple of questions on SDP Identity attribute Thread-Index: AQHUYTNdgdx0fYUyP0+ZCWsqcc6KnaUZ4UCAgAA5UQA= Date: Thu, 11 Oct 2018 11:27:06 +0000 Message-ID: <3700047D-9343-43BF-B580-6E93110F1D81@ericsson.com> References: <19e47597-e90c-ebba-3467-25e511bed661@alvestrand.no> In-Reply-To: <19e47597-e90c-ebba-3467-25e511bed661@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.11.0.180909 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3485; 6:V4hxRHqXDmZ3SMgKbPu+4hxSzKI/hrLJJkaA6bnF2abz8aWO9yMG7hyr0UqPedR92z9MtVwNnQI6/rb+cIhPh7A8L1I9xO9KE1O7knj/A3+u/3HwdEXeg43IWCcEbjxYAhgk3dDcrNuDRDMMbY8qf1jEj2Ft3QQ39tTGahx3MafusOumpqW8VINOZbPCcJqK7AcaSUP5LcljrIu0KZ41lEw5aCNxdOf+5KiGIthCD+iYn71qj1OmcEPgYaLDK0yukhA2Mjg08TDgyZoR+e/DCSqrGm7LkQtosz4jgi9ahJNR2m1A6hgNW3VSygkGQP2OFhKASQgy7UcwVQY1iXOaVgjVYgLn1P2JdvKaOPrv2TQECCLwyy5tA2rzDRssz9zajGOCn0PBQPldGnoPkhLNsUWBYXxopB2h1r7tyRcjsDnB4fwn3gb2sd8rSVGl3q5fb4ignVbg5pg366P/MSFn4g==; 5:ZWT3h7SilN+vPYLK2Jr28nlrMfl7hgf8zGCiRNHpAmZUAUz9Un0x9CCbxFkPniKjNcBHInYwZwCZroHJYm+0pPFZdbSOBIUjWcQSfLoC3NCRQgKS2hhBvWEQ5eYibRIWWBnrbVsqRADcJxm++zklvetUzBnHECxHgyXQMQYIOaU=; 7:DDaVVVpxyMm+IPVQk4h6cJuxBk8hq/veOBDnClvIHViH2uieYl4pMvEws1QSlCo77WWz3ylb7FWR7QcU9haAGMMcLuktiDXbIWFGtFnDz3Lhg3HQZgpiL4hYWYmXhWb0W4m69vCmLWL/TXqIHmpvbdBfzDHfRrmBBGTW6R+nzkGPLCGmyPhCtORPoS43KmU3oG0GTjVPtr67s0KEIcYM80Jlm2uAFOqziqT5om1vgpZwZR5elIt+DMBsKsxVwc13 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 272831ed-67fe-4a9a-533a-08d62f6c7a0b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3485; x-ms-traffictypediagnostic: VI1PR07MB3485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:VI1PR07MB3485; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3485; x-forefront-prvs: 08220FA8D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(376002)(346002)(396003)(189003)(199004)(5660300001)(81166006)(81156014)(8936002)(478600001)(316002)(14454004)(6246003)(2501003)(5250100002)(8676002)(83716004)(25786009)(66066001)(2900100001)(256004)(36756003)(305945005)(53936002)(105586002)(106356001)(229853002)(6486002)(6506007)(33656002)(6512007)(71190400001)(71200400001)(7736002)(3846002)(58126008)(110136005)(6116002)(6436002)(186003)(86362001)(2906002)(26005)(82746002)(102836004)(68736007)(11346002)(76176011)(486006)(2616005)(97736004)(99286004)(476003)(446003)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3485; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ONBHh6I+vwF0AWRXnN/cWoIQISPqGCfaBrIoO3IRZ0tvSA3vLYfLYMHwiHZGBnZV2smK7plJcDqnSt75yc33xoJfyraQMDq3oSsk56vaWysG7BKEiUdWsKHetyNGPBmbzUycHdA9bTALvcaegf0E6pk4hPgamj7PC78kmtcHf1qKH9QMGm+DUmQSvWivdQr+PtQb1cdMpsrFqrD/dPRFMXqUY/t+ZKO5K7lRCRCWRw+/LnHFcVxexwXAvvdgSmzJHO60PMQB+mI7gN39X/ue01ESxcLiy0CQZ9wLbxkvlGNHNI0fzD1EFbURmJaM58Qh3x8z1nGbeDTieJdvmFhkmDNRRBPYCQ61pbAIxx6A3aE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <27ACC724394E144EAA9F313B44B14653@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 272831ed-67fe-4a9a-533a-08d62f6c7a0b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 11:27:06.9019 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3485 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7d3e6Gw8fl8mClOElI0dnsw4qwRiQzKCs/VErMlRcVdcqu rSyIWWS+4BihmTNZ4ghZaVJJGrblWJYv8w0hMz/MF5j2IQtyJobkdhf07Xf+5/8/nOfw0KTE REXTRboKRq/Tlsj4Il7LxTfXk01pztxU35hQOWSq4yu7tu8LjhPqGfMMpbbZNomzRI7oaD5T UmRg9PL0PFFhb/dDqtwrumF/ZiWNaEBUh4Q04EMw99TPr0MiWoI/IFis9RNc4UcwNvWHCLgk 2EbATCsTaPCwmYTZqs2Qq5EA28/PiCsWETR7jDvDaJqPlVC/nRRIR+JsaPCtoQDvwifBYhpG nJ4BDb9G+RwfgfFasyDAPLwfqmvtQV2Mj8HGvTYBt4UB3CNTVICFWAUbq57gHIR3w8bI8+Cm JI6CuWUrwb0Ng21gguRYCqtL28GsFMvB6q2huKwWnHZvyBMHnu8Loew+mLbWI44dAnD08DlO hh9NTSH/aWj1Tgs4/ohg4oGc40ToHXKE5hSDu8fF/6fXuC0hPQbsDQs8M1JY/lvbsnM5Eh+A F2/lnKyG9ysuPsdx0Fi/ILAErxIBwy3LvCeIsiMpy7BXSgsUihRGX3SVZct0KTqm4iXa+SWD r7dS+9CqT+VCmEayMPFEvDNXQmkNbGWpCwFNyiLF8keOXIk4X1t5k9GXafTXShjWhfbQPFmU WHnmVY4EF2grmGKGKWf0/7oELYw2ohNpFl96/3pLt//LJBsec9eW6dV8M5o8w+2x841YoZrV qPsunXu3disrqfVCQpi5S9Ctco4S7Xtjs8JXtgpjOyftmxl5S6b+qIjSqk7NqcFidyT1qYNe 68iUSw3N2ZfvxGeNf12Yl//OsSI2oe2wLLy9Ony9obSXrH18/naYjMcWag8mknpW+xfgXv76 IQMAAA== Archived-At: Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 11 Oct 2018 11:27:15 -0000 SGksDQoNCiAgICA+PiBRMTogSW4gYW4gb2ZmZXIgb3IgYW5zd2VyLCBpdCBhbGxvd2VkIHRvIGlu Y2x1ZGUgZmluZ2VycHJpbnRzIHRoYXQgaGF2ZQ0KICAgID4+IE5PVCBiZWVuIHVzZWQgdG8gYXNz ZXJ0IHRoZSBpZGVudGl0eT8NCiAgICA+DQogICAgPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHF1 ZXN0aW9uLi4uLi4gaWYgeW91IGRvbid0IGFzc2VydCBhbiBpZGVudGl0eSwNCiAgICA+IHRoZXJl IGFyZSBvZiBjb3Vyc2UgZmluZ2VycHJpbnRzIHRoYXQgaGF2ZSBub3QgYmVlbiB1c2VkIHRvIGFz c2VydCB0aGUNCiAgICA+IGlkZW50aXR5Lg0KICAgID4NCiAgICA+IFdhcyB0aGUgcXVlc3Rpb24g YWJvdXQgdGhlIGNhc2Ugd2hlcmUgeW91IGluY2x1ZGUgYW4gaWRlbnRpdHkgYXR0cmlidXRlPw0K ICAgIA0KICAgIFllcy4NCg0KICAgID4+IFEyOiBJZiBvbmUgb3IgbW9yZSBvZiB0aGUgZmluZ2Vy cHJpbnRzIHVzZWQgdG8gYXNzZXJ0IHRoZSBpZGVudGl0eQ0KICAgID4+IGNoYW5nZSwgSSBhc3N1 bWUgdGhhdCB0aGUgSWRlbnRpdHkgYXR0cmlidXRlIHZhbHVlIHdpbGwgYWx3YXlzIGNoYW5nZXMg YQ0KICAgID4+IHJlc3VsdD8gT3IsIGlzIHRoZXJlIGEgY2hhbmNlIHRoYXQgZGlmZmVyZW50IGZp bmdlcnByaW50cyB3b3VsZCBwcm9kdWNlDQogICAgPj4gdGhlIHNhbWUgSWRlbnRpdHkgYXR0cmli dXRlIHZhbHVlPw0KICAgID4NCiAgICA+IEEgZmluZ2VycHJpbnQgY2FuJ3QgcmVhbGx5ICJjaGFu Z2UiLg0KICAgID4gVGhlcmUgbWF5IGJlIG5ldyBmaW5nZXJwcmludHMgYmVjYXVzZSBvZiBuZXcg aGFzaCBmdW5jdGlvbnMgYWRkZWQNCiAgICA+ICh0aG91Z2ggdGhhdCB3b3VsZCBiZSBzdHJhbmdl IG92ZXIgdGhlIHRpbWUgb2YgYSBjYWxsKSwgb3IgYmVjYXVzZSBuZXcNCiAgICA+IGNlcnRpZmlj YXRlcyB3ZXJlIGFkZGVkIHRvIHRoZSBzZXNzaW9uLg0KICAgIA0KICAgIENvcnJlY3QuDQoNCiAg ICBSZWdhcmRzLA0KDQogICAgQ2hyaXN0ZXINCg0KIA0KDQo= From nobody Thu Oct 11 13:57:23 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566EF127598 for ; Thu, 11 Oct 2018 13:57:21 -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=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 dEe_OtgYize3 for ; Thu, 11 Oct 2018 13:57:19 -0700 (PDT) Received: from smtp105.ord1d.emailsrvr.com (smtp105.ord1d.emailsrvr.com [184.106.54.105]) (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 34E85124C04 for ; Thu, 11 Oct 2018 13:57:19 -0700 (PDT) Received: from smtp22.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 6A27DE0180; Thu, 11 Oct 2018 16:57:18 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp22.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1867BE00ED; Thu, 11 Oct 2018 16:57:18 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.173] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Thu, 11 Oct 2018 16:57:18 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_476A45C2-8B1A-407B-9695-D1517A7D744A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Thu, 11 Oct 2018 14:57:17 -0600 Cc: RTCWeb IETF Message-Id: <8ECAF21E-F2C9-4FFF-9B19-39284A80F13E@iii.ca> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 11 Oct 2018 20:57:21 -0000 --Apple-Mail=_476A45C2-8B1A-407B-9695-D1517A7D744A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 11, 2018, at 12:23 AM, Christer Holmberg = wrote: >=20 > Hi, > =20 > A couple of questions related to some comments on GitHub: > =20 > Q1: In an offer or answer, it allowed to include fingerprints that = have NOT been used to assert the identity? Yes, I think they should because fingerprints can be used even if = Identity is not.=20 > =20 > Q2: If one or more of the fingerprints used to assert the identity = change, I assume that the Identity attribute value will always changes a = result? Or, is there a chance that different fingerprints would produce = the same Identity attribute value? It will pretty much always changes ( or at least at the same odds of two = different things hashing to the same value )=20 If the far end was doing transfers that looked like just changing the = SDP in the same offer/answer session to move the media to a new = endpoint, the fingerprint and identity values would change but it would = also be redoing ICE and setting up a new DTLS session.=20 > =20 > Regards, > =20 > Christer > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_476A45C2-8B1A-407B-9695-D1517A7D744A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 11, 2018, at 12:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
 
A = couple of questions related to some comments on GitHub:
 
Q1: = In an offer or answer, it allowed to include fingerprints that have NOT = been used to assert the = identity?

Yes, I think they should because fingerprints can be = used even if Identity is not. 

 
Q2: = If one or more of the fingerprints used to assert the identity change, I = assume that the Identity attribute value will always changes a result? = Or, is there a chance that different fingerprints would produce the same = Identity attribute value?

It will pretty much always changes ( or at least at the = same odds of two different things hashing to the same value = ) 

If the far end was doing = transfers that looked like just changing the SDP in the same = offer/answer session to move the media to a new endpoint, the = fingerprint and identity values would change but it would also be = redoing ICE and setting up a new DTLS session. 

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

= --Apple-Mail=_476A45C2-8B1A-407B-9695-D1517A7D744A-- From nobody Fri Oct 12 08:14:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8CA130E30 for ; Fri, 12 Oct 2018 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 qKp28mCdtDRq for ; Fri, 12 Oct 2018 08:14:02 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 A4F92130DCB for ; Fri, 12 Oct 2018 08:13:58 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id i8-v6so12590748wmg.0 for ; Fri, 12 Oct 2018 08:13:58 -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=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=kbBh2vZCT06dAV3ddSrKPchglwtC8qRWjrgpG1GC3QjX9AXBxSApO3aKOtzujZ1GJH NuaKnRCqMOOIKiLpGPK0amWRJB6IHtvqv0lyw6V0VrOXiQFEOWW5z9ZfJNtom9rVUMth srAF3yf6cO4smgde0l/2PxMpQUxisblBkAKKgyCCmJD0MulxYe/FnS8SVUeAZK+mM6nd A02AV7eei3jIPsSy7umZW+OCNqoRBLDTnCKdcbOj4iiCZ/ezz/JDHJ3xqztfpYQtVnHA WV2BiJHi//Y+F18B0VtqjPKvciwJluxjT2iBwYlIagr2XtbQIQQ+QfI2r1qurIdAV6O6 dUlA== 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=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=OpntbBYDHqGdlAgE97zi1OZgqbzkFJPBe25CJhkE6S1hYJ2RTJIF2NpgBL+D3opYlG /cg3I355huQiMIXrNxz7MgDZCMaJEOfoZDouf4lg5M+slz+Cv25H74c9nDkYjqyolQ/I hMwvyN4YYK9vZomCfC9HOS8zOhwVV2GbSIt+rQSqMXzuVl8ZIKIfdyJFQbk7gljxYKPI vEuKqj8O2Jxn+7Z4tZRh7F3Ch70ZMrL2Zk1WmT7hFsR6dSCrIMYrZNcW2t6iuYjfUnnn 1h9m19N6qXScK+EDKyRAeBfX9VsMKaKHKUBbnZ8PL3eoVvuxGRN6EJWjFV+Mj/L6M9zx 5+pw== X-Gm-Message-State: ABuFfojpb9Q5Gk/8nn7AMfL1jjGFfVnWQkUl2gk3sIojpHY2R7JIqLrh V9/RaE1Yz9RZvVRBhk1F8GRIzkwn0U8tfXND67EepA== X-Google-Smtp-Source: ACcGV634Ej7c20K7On6ejzP2cAt8eLYIXpqP4/04vMUVSZ5LAKuB4CO37p/gwM5vXcwoWcgRzkxkf0aZRDqFdo1DeUI= X-Received: by 2002:a1c:838a:: with SMTP id f132-v6mr5822773wmd.51.1539357236687; Fri, 12 Oct 2018 08:13:56 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Peter Thatcher Date: Fri, 12 Oct 2018 08:13:43 -0700 Message-ID: To: Justin Uberti Cc: pthatcher=40google.com@dmarc.ietf.org, mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000047047205780989dd" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 12 Oct 2018 15:14:04 -0000 --00000000000047047205780989dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti wrote: > I agree with Peter. Chrome's implementation is already closer to 8445 tha= n > 5245, so I don't see any issues associated with snapping this cluster to > 8445 (aside from the work involved). > > On that topic, note that JSEP will need a few more changes than just the > addition of the 8445 reference and note; the examples will have to be > updated, as will the logic regarding generation of offers and answers and > their parsing (to deal with the new ice-option). These changes will be > modest but probably will need to be done by the authors. > > I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp) in this PR: https://github.com/rtcweb-wg/jsep/pull/851 I've also added the ice2 processing and added ice2 to the examples in the same PR. What did you mean by "and note"? Is there something more needed? > On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher 40google.com@dmarc.ietf.org> wrote: > >> I'm late to the discussion, and reading through it, it seems that we hav= e >> a lot of back and forth without addressing Cullen's root issue. Let me = see >> if I understand Cullen's root issue correctly. I think it's something l= ike: >> >> 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant" >> without changing to be compliant with 8445. >> >> 2. Cisco has existing code that it wants to continue to interoperate >> with endpoints, especially Chrome, even as they make changes to become 8= 445 >> compliant. And they don't want to have to test against old and new >> versions. >> >> Cullen, is that accurate? >> >> >> >> OK, so some of my thoughts: >> >> 1. I don't think there is any interop risk here at all related to >> timings. If you're worried about the drop in minimum check interval goi= ng >> from 20ms to 5ms, don't. Just because the spec allows for going that lo= w >> doesn't mean endpoints will. And if they do, they'll do it carefully. >> Endpoints can and should still choose a value that works best regardless= of >> the min in the spec. For example, Chrome is still using an interval of >> 48ms (we're not in a rush to lower it, but we have non-browser endpoints >> that do go lower). And if we roll out a lower value, it will be via >> experiments or opt-ins and carefully tracked to make sure connectivity >> rates don't drop. If any problem were found in practice, it would be >> quickly reverted. >> >> 2. I don't think there is any interop risk here related to nomination >> either. >> Chrome's default behavior has never been compliant to any spec anyway, >> and it's never been an issue. And like with ping intervals, any changes= to >> implementations will be done slowly and carefully. >> >> 3. I don't think it really matters to major implementations what the >> dependency graph looks like. Whether some point to 5245 and others to 8= 445 >> or if all of them point to 8445, it doesn't matter, implementations will >> behave the same either way. Chrome, for example will adjust timings as >> works well in practice (perhaps someday to below 20ms interval) regardle= ss >> of which RFCs point to 8445 and which point to 5245. If interop issues >> ever do come up, then they can be fixed. And that has nothing to do wit= h >> which RFCs point to 5245 and which point to 8445. >> >> 5. You're going to need to test against different versions of different >> browser no matter what the RFC references are. ICE timings and nominati= ons >> seem like the least of your testing problems. But on the flip side, Chr= ome >> (and I assume other browsers) have been very slow and careful when makin= g >> changes to the ICE code. >> >> 6. FlexICE should go a long way to putting the web app in control of th= e >> ICE behavior. So if you are worried about what browsers will do with IC= E, >> I suggest supporting the FlexICE effort. In fact, it's the result of yo= ur >> proposal at TPAC in 2017 for wanting to have lower-level of control of >> ICE... If we get that into all the browsers, you won't have to worry an= y >> more about any of this because you'll be in control (assuming you contro= l >> the web app). >> > >> Altogether, I don't see any reason to not reference 8445 everywhere, at >> least not any related to interop risk and web browsers. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: >> >>> >>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg < >>> christer.holmberg@ericsson..com > wrote= : >>> >>> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this >>> change. These gratuitous changes, years after the implementation were >>> coded, with no real benefit will ensure that we are not >>> > and will not become compliant with the RFC. It's unlikely we will >>> upgrade to the new ICE until it has real befits. >>> >>> The main reason we did 8445 was because people had identified issues >>> with 5245. The work was driven mostly by the WebRTC community, includin= g >>> yourself and the Chrome people (or, at least the Google people), and on= e of >>> the reason it took time to finalize 8445 was because you (among others) >>> wanted to make sure we get things right (by making network measurements >>> etc). Are you now saying all those changes bring no benefit? Did we all >>> waste our time? >>> >>> >>> Our testing, which we do not share, dig not indicate an improvement of >>> connectivity rates. I did not see results from others that did. Some of= the >>> early test results from others that drove this work were not reproducib= le >>> in our testing. The one thing I think most people did find is that the = more >>> out of sync the pacing of the two agents was, the worse the connectivit= y >>> was. But all of this is water under the bridge, we have old and new ice= , >>> people can use either. What we are talking about here is what is the >>> minimum bar for WebRTC 1.0 >>> >>> >>> > It is doubtful Justin will want to implement the 8445 mechanisms of >>> supporting both new and old ICE. Instead, we will move to say "works >>> with Browser X version Y or later." We have watched at W3C as it moved = to >>> be that unless chrome does it, it rare that it becomes a standard. >>> > Right here I am watching how the stuff IETF defines will be less >>> relevant than the issue of what chrome implements. >>> >>> What exactly would Justin have to change? >>> >>> >>> >>> For us, the largest part is having to test for both old and new - it=E2= =80=99s >>> not easy to do good automated testing for ICE. >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> _______________________________________________ > > >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --00000000000047047205780989dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
I agree with Peter. Chro= me's implementation is already closer to 8445 than 5245, so I don't= see any issues associated with snapping this cluster to 8445 (aside from t= he work involved).

On that topic, note that JSEP will ne= ed a few more changes than just the addition of the 8445 reference and note= ; the examples will have to be updated, as will the logic regarding generat= ion of offers and answers and their parsing (to deal with the new ice-optio= n). These changes will be modest but probably will need to be done by the a= uthors.


I've updated th= e references to 8445 (and to=C2=A0draft-ietf-mmusic-ice-sip-sdp) in this PR= :=C2=A0https://githu= b.com/rtcweb-wg/jsep/pull/851

I've also ad= ded the ice2 processing and added ice2 to the examples in the same PR.=C2= =A0

What did you mean by "and note"?=C2= =A0 Is there something more needed?
=C2=A0
<= div dir=3D"ltr">On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatche= r=3D40goog= le.com@dmarc.ietf.org> wrote:
I'm late to th= e discussion, and reading through it, it seems that we have a lot of back a= nd forth without addressing Cullen's root issue.=C2=A0 Let me see if I = understand Cullen's root issue correctly.=C2=A0 I think it's someth= ing like:

1.=C2=A0 Cisco has existing code that it= wants to call "WebRTC 1.0 compliant" without changing to be comp= liant with 8445.

2.=C2=A0 Cisco has existing code = that it wants to continue to interoperate with endpoints, especially Chrome= , even as they make changes to become 8445 compliant.=C2=A0 And they don= 9;t want to have to test against old and new versions.=C2=A0=C2=A0

Cullen, is that accurate?



OK, so some of my thoughts:

1.=C2=A0 I don't think there is any interop risk here at all related t= o timings.=C2=A0 If you're worried about the drop in minimum check inte= rval going from 20ms to 5ms, don't.=C2=A0 Just because the spec allows = for going that low doesn't mean endpoints will.=C2=A0 And if they do, t= hey'll do it carefully.=C2=A0 Endpoints can and should still choose a v= alue that works best regardless of the min in the spec.=C2=A0 For example, = Chrome is still using an interval of 48ms (we're not in a rush to lower= it, but we have non-browser endpoints that do go lower).=C2=A0 And if we r= oll out a lower value, it will be via experiments or opt-ins and carefully = tracked to make sure connectivity rates don't drop.=C2=A0 If any proble= m were found in practice, it would be quickly reverted.=C2=A0=C2=A0

2.=C2=A0 I don't think there is any interop risk here= related to nomination either.=C2=A0=C2=A0
Chrome's default b= ehavior has never been compliant to any spec anyway, and it's never bee= n an issue.=C2=A0 And like with ping intervals, any changes to implementati= ons will be done slowly and carefully.=C2=A0=C2=A0

3.=C2=A0 I don't think it really matters to major implementations what= the dependency graph looks like.=C2=A0 Whether some point to 5245 and othe= rs to 8445 or if all of them point to 8445, it doesn't matter, implemen= tations will behave the same either way.=C2=A0 Chrome, for example will adj= ust timings as works well in practice (perhaps someday to below 20ms interv= al) regardless of which RFCs point to 8445 and which point to 5245.=C2=A0 I= f interop issues ever do come up, then they can be fixed.=C2=A0 And that ha= s nothing to do with which RFCs point to 5245 and which point to 8445.

5.=C2=A0 You're going to need to test against diff= erent versions of different browser no matter what the RFC references are.= =C2=A0 ICE timings and nominations seem like the least of your testing prob= lems.=C2=A0 But on the flip side, Chrome (and I assume other browsers) have= been very slow and careful when making changes to the ICE code.
=
6.=C2=A0 FlexICE should go a long w= ay to putting the web app in control of the ICE behavior.=C2=A0 So if you a= re worried about what browsers will do with ICE, I suggest supporting the F= lexICE effort.=C2=A0 In fact, it's the result of your proposal at TPAC = in 2017 for wanting to have lower-level of control of ICE...=C2=A0 If we ge= t that into all the browsers, you won't have to worry any more about an= y of this because you'll be in control (assuming you control the web ap= p).=C2=A0

Altogether, I d= on't see any reason to not reference 8445 everywhere, at least not any = related to interop risk and web browsers.







=C2=A0









<= /blockquote>
On Fri, Sep 7= , 2018 at 9:37 AM Cullen Jennings <fluffy@iii.ca> wrote:

On Sep 7, 2018, at 1:25 AM, Christer = Holmberg <christer.holmberg@ericsson..com> wrote:

> C= isco has implemented stuff that is WebRTC 1.0 compliant without this change= .=C2=A0These gratuitous changes, y= ears after the implementation were coded, with no real benefit will ensure = that we are not
>=C2=A0and will not= become compliant with the RFC.=C2=A0It's unlikely we will upgrade to the new ICE until it has real befit= s.=C2=A0
= =C2=A0
The main reason we di= d 8445 was because people had identified issues with 5245. The work was dri= ven mostly by the WebRTC community, including yourself and the Chrome peopl= e (or, at least the Google people), and one of the reason it took time to f= inalize 8445 was because you (among others) wanted to make sure we get thin= gs right (by making network measurements etc). Are you now saying all those= changes bring no benefit? Did we all waste our time?

Our testing, which we do not share, d= ig not indicate an improvement of connectivity rates. I did not see results= from others that did. Some of the early test results from others that drov= e this work were not reproducible in our testing. The one thing I think mos= t people did find is that the more out of sync the pacing of the two agents= was, the worse the connectivity was. But all of this is water under the br= idge, we have old and new ice, people can use either. What we are talking a= bout here is what is the minimum bar for WebRTC 1.0=C2=A0

=C2=A0=
> It is doubtful Justin = will want to implement the 8445 mechanisms of supporting both new and old I= CE.=C2=A0Instead, we will move to = say "works with Browser X version Y or later." We have watched at= W3C as it moved to be that unless chrome does it, it rare that it becomes = a standard. =C2=A0
>=C2=A0Right her= e I am watching how the stuff IETF defines will be less relevant than the i= ssue of what chrome implements.=C2=A0=
= =C2=A0
What exactl= y would Justin have to change?
=C2=A0

For us, the largest part is having to test for both old and new - it= =E2=80=99s not easy to do good automated testing for ICE.=C2=A0
= _______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--00000000000047047205780989dd-- From nobody Fri Oct 12 11:12:27 2018 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 89A0E130E62; Fri, 12 Oct 2018 11:12:19 -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.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <153936793951.29139.1199852922676317754@ietfa.amsl.com> Date: Fri, 12 Oct 2018 11:12:19 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-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, 12 Oct 2018 18:12:20 -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 : WebRTC IP Address Handling Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-ip-handling-10.txt Pages : 12 Date : 2018-10-12 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-10 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-10 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 Fri Oct 12 11:16:33 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F01130E62 for ; Fri, 12 Oct 2018 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 ce57u1YCLGKd for ; Fri, 12 Oct 2018 11:16:28 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 54BCB12D7EA for ; Fri, 12 Oct 2018 11:16:28 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id 74-v6so20102415itw.1 for ; Fri, 12 Oct 2018 11:16:28 -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=hlGb7n6+hCXvEdEzh5nRkZGFB05HgH89PZibLfxz4Xg=; b=VbRIj2vKm2FcP14GtNxSbLkEOcovgBKlUG8QHdyvguGN65N8aZo2fUn8Jm2HulBpkW KE/iQKGKPtxn1fVSwj+KV9C5eo9yhG69O+XaK/FriXq9ujRN1mzklCvbHARnLns5aype btLbjCGfUWPChrNEp+ahWFx+jI7p6X9oJjiXHLvy9DydZeyL5Lp0j0KD7xvoyGVL4EsC jZZ5yWGzK8SRjKEzqwZNb0J+YgWfOtnzlaFjj+9XhADFvOEAFDZjUKUrIpfielM8VemS EltfzJYwIz0YLc236PPzD8++l2z5/cyITz+vNg4JSP0wxuXcDvB0wG0Q6O4T6zwty9Jt N2CA== 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=hlGb7n6+hCXvEdEzh5nRkZGFB05HgH89PZibLfxz4Xg=; b=j1JzWaSDR8kwL5S/sbbZTnUi9b+NWYH6W+wEv9XSlXSwsje9Nl15PyUv9jZG2v/Os7 vg5ZOatJ8EWUPxsCLa2FGxNMZw5DwBKHrUGM2ZLLgV3N38vbKMDsFpL6PBhJPm1BuSzz 0a6JT/Vga/NE5+Bhwbp06lUQ+TYIotEAUfMUdn3olrg2d9k5FB1t1PgrDXhbvxrLsfTq ybkeVPt5VGb+xtvwgstRAcmEkqLfx/uLL1m/DT+GfKUfQ+H+PD3Joluu69RLE4MTfZTZ xgbpIXUxSRSac4VsSwFmNYuIH4bGqWDCFNEeYzYfEoBowuEvypQChUjoybPEokuohJsE 3aFQ== X-Gm-Message-State: ABuFfoh5Px8/HiFaaaWxN5uEnOs+kut0vedJBHbDlPnz/ln/3qnFSWpA nMKjr9+AcvqASkiLJGizNozzANgc5BYCMURhDmRDxMsfpbP71g== X-Google-Smtp-Source: ACcGV60k65ALhIda6nJtDcgBCtx8/YLV6PCGzbJdRy/jT+Q2fcTOZgSROBN8MhKMTxlkY3qdnc2J9394quzALxZaHUQ= X-Received: by 2002:a02:1b4f:: with SMTP id l76-v6mr5612113jad.57.1539368186812; Fri, 12 Oct 2018 11:16:26 -0700 (PDT) MIME-Version: 1.0 References: <153936793951.29139.1199852922676317754@ietfa.amsl.com> In-Reply-To: <153936793951.29139.1199852922676317754@ietfa.amsl.com> From: Justin Uberti Date: Fri, 12 Oct 2018 11:16:13 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000f4905405780c15bf" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 12 Oct 2018 18:16:31 -0000 --000000000000f4905405780c15bf Content-Type: text/plain; charset="UTF-8" This update incorporates feedback from IETF 102, namely that the problems discussed should all be called out in the problem statement, but some solutions may be left to future versions of the document. Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-10 On Fri, Oct 12, 2018 at 11:13 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > WG of the IETF. > > Title : WebRTC IP Address Handling Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-ip-handling-10.txt > Pages : 12 > Date : 2018-10-12 > > Abstract: > This document provides information and requirements for how IP > addresses should be handled by WebRTC implementations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-10 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000f4905405780c15bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This update incorporates feedback from IE= TF 102, namely that the problems discussed should all be called out in the = problem statement, but some solutions may be left to future versions of the= document.


On Fri, Oct 12, 2018 at 11:13 AM <internet-drafts@ietf.org> w= rote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-12

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how IP=
=C2=A0 =C2=A0addresses should be handled by WebRTC implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-r= tcweb-ip-handling-10
https://datatracker.ietf.org/d= oc/html/draft-ietf-rtcweb-ip-handling-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-rtcweb-ip-handling-10


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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000f4905405780c15bf-- From nobody Fri Oct 12 16:08:03 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A015128766 for ; Fri, 12 Oct 2018 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 qbR1U-ff_-Ia for ; Fri, 12 Oct 2018 16:08:00 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 05BDA126BED for ; Fri, 12 Oct 2018 16:08:00 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 204-v6so8656574qkd.5 for ; Fri, 12 Oct 2018 16:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2acSq8kdzB6oZTh2vjJVtbNIxurADDrfWL1E6f/0hdE=; b=JNoUH6VB99NnQ2w+7S2eeJbZI337vqfJjL0BpaqNfK3upGlf8wj8liz4+RqZGC6+X2 K+9qn9eqs3NsEc6JK+EEmimrGN7PWnvQXIV2XHO94xB+cmiZIsCq+1lsWpmbyD0gP0mS WSlMGK1takbJFS+7FCLyhHxMH3/Kogy+CtgRo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2acSq8kdzB6oZTh2vjJVtbNIxurADDrfWL1E6f/0hdE=; b=K60cNeeFQ+TXTUFlA7ah2OcURYcCSJ6wjZVWjW2tUcRHoXqUQJT2IpQ7zD3JZgB+h1 ipp1CsQTxFuo44ab4roKF97khEedMAyG6Fu4BTm7dCE5oZRbejL3ACCghVs4SEgvUW4u qItd7sFRubguv3Hj/zL0sr6Usc0ac3Q9wuOZwSX/xem9dGFKI48jt1LkKpiDdNTymEQZ 838tBSklsXTSaGa7pzaCRKAWs7vLKIzTuOHjQ5dDTWrilvSlzu6n8NpjzvNu+F7Ey3Gi nQPPxjbp/ZEXp2uXiXqbF6bRr7adJQrQ0GJWABM1ehA/Dgla5LEX0XQejqV0UrM1lZpk BT3Q== X-Gm-Message-State: ABuFfogyDeZD8tmQJviyhkXwuOsJl+hujN1hEPh0t4GCTDboO5GCttLX 1BZj05xqknSH5WSV2FNF0QZ2TDpuvPY= X-Google-Smtp-Source: ACcGV63/Y8SZDdOdY32wAvI1fIQIiiYrSZS6JcShXt1HNEHGjj6b9eh1S18I4qzfavscwJ9WOEDt2A== X-Received: by 2002:a37:1f53:: with SMTP id f80-v6mr7320952qkf.109.1539385679225; Fri, 12 Oct 2018 16:07:59 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id j66-v6sm1282160qkf.1.2018.10.12.16.07.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 16:07:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Fri, 12 Oct 2018 19:07:57 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <153936793951.29139.1199852922676317754@ietfa.amsl.com> To: Justin Uberti , Adam Roach X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 12 Oct 2018 23:08:02 -0000 Justin - Many thanks! Adam - I=E2=80=99ve changed the state to removed the =E2=80=9CRevised = I-D Needed - Issue raised by WG=E2=80=9D state so this one is ready for = your review (and hopefully an IETF LC). spt > On Oct 12, 2018, at 14:16, Justin Uberti = wrote: >=20 > This update incorporates feedback from IETF 102, namely that the = problems discussed should all be called out in the problem statement, = but some solutions may be left to future versions of the document. >=20 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-10 >=20 > On Fri, Oct 12, 2018 at 11:13 AM wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers WG of the IETF. >=20 > Title : WebRTC IP Address Handling Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-ip-handling-10.txt > Pages : 12 > Date : 2018-10-12 >=20 > Abstract: > This document provides information and requirements for how IP > addresses should be handled by WebRTC implementations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-10 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 12 18:08:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F44128766 for ; Fri, 12 Oct 2018 18:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 ePL-xfp2LGYw for ; Fri, 12 Oct 2018 18:08:45 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 B089A130934 for ; Fri, 12 Oct 2018 18:08:44 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id w200-v6so20620385itc.4 for ; Fri, 12 Oct 2018 18:08:44 -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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=HY9k6sPH8AwHFqiTqDrKoZrt2+oiGv4wnkLgO2EJ2X+Xwe/NuVMJLDF+BXs+8UVrqv OwU35yytFJ8BahZEQqzcm9ClCZEbzJeGmaZChOncxBqwIx+W6ML5SIIwgeIKjOZ2wMZ0 VC9z0R0oRWHcN3al4nNBQbf0xNBFhQqlb6LfxhauoHaic/0AlPJWfFjDtaa2k8Kgl0Mi C/8RLksxpqFvp6+qA6WsMwF4mMihJoByhUVTrWDJ8UGq9his1q39j7Udy4uXTj/l0UcY C3Gt0B9GxReliBZP1hCPfYgk2GLqzC5c6TRc7qfCdWyaqMEzFr1iRjOjV/A+8fkG1FwR JiaQ== 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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=n2mVf7f0nayO+4lltqFssJUu73tAWn17mYouNrFEGPnGjFNZG749UbkWJ0W0BTQPUD ByWK4BXj/DYOHMiZ/z0/7sOMYP2bSOTELoY1NK9zDWgX5IP//K43i52NlgzBIDJS8ylf JzFASlGy6aJwGzWZJx7TBveozxzC2fL9hf4Hs8XythZ8cafljSDBYDf/EHhJO5i0o8GR 2UF3iN6LkxygJHxvfTfNeJ99s4wd7z+4yK2LR6ATjT/kyHaDVzLNoDr/WCNUups417JT qOa0/BlQnogEgeLfRSl5HtVVZAfccMguHDYhy11vvK88+BIU+b1xtP2pEvua0qtdQQKE O9Wg== X-Gm-Message-State: ABuFfogCUK0BffKdlO+roJzWyKROxftvEvmGQOR8Zt5GCGptJsw+1LBu ygb7H/n8y/IZn4FOmIheWNA242cj6ckLDuO8GeNGSw== X-Google-Smtp-Source: ACcGV63ndaLILfkWGr55imIClvCOJ3JtTzCJeZ4VsYmNIX8q2gBRPm1dEyM+CcrCiwJIiVQ5Ia89iSVo6PHpklJ2piM= X-Received: by 2002:a24:fc02:: with SMTP id b2-v6mr6257023ith.45.1539392923522; Fri, 12 Oct 2018 18:08:43 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Justin Uberti Date: Fri, 12 Oct 2018 18:08:29 -0700 Message-ID: To: pthatcher=40google.com@dmarc.ietf.org Cc: Peter Thatcher , mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000060d8e5057811d87f" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 13 Oct 2018 01:08:47 -0000 --00000000000060d8e5057811d87f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher wrote: > > > On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> I agree with Peter. Chrome's implementation is already closer to 8445 >> than 5245, so I don't see any issues associated with snapping this clust= er >> to 8445 (aside from the work involved). >> >> On that topic, note that JSEP will need a few more changes than just the >> addition of the 8445 reference and note; the examples will have to be >> updated, as will the logic regarding generation of offers and answers an= d >> their parsing (to deal with the new ice-option). These changes will be >> modest but probably will need to be done by the authors. >> >> > I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp= ) > in this PR: https://github.com/rtcweb-wg/jsep/pull/851 > > I've also added the ice2 processing and added ice2 to the examples in the > same PR. > Thanks for doing this, Peter. > > What did you mean by "and note"? Is there something more needed? > The note in question is the text that Adam mentioned in the original email: *While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one. * I do think we need text similar to this to be added to S 5.11 (processing an answer) in JSEP. > > >> On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher > 40google.com@dmarc.ietf.org> wrote: >> >>> I'm late to the discussion, and reading through it, it seems that we >>> have a lot of back and forth without addressing Cullen's root issue. L= et >>> me see if I understand Cullen's root issue correctly. I think it's >>> something like: >>> >>> 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant= " >>> without changing to be compliant with 8445. >>> >>> 2. Cisco has existing code that it wants to continue to interoperate >>> with endpoints, especially Chrome, even as they make changes to become = 8445 >>> compliant. And they don't want to have to test against old and new >>> versions. >>> >>> Cullen, is that accurate? >>> >>> >>> >>> OK, so some of my thoughts: >>> >>> 1. I don't think there is any interop risk here at all related to >>> timings. If you're worried about the drop in minimum check interval go= ing >>> from 20ms to 5ms, don't. Just because the spec allows for going that l= ow >>> doesn't mean endpoints will. And if they do, they'll do it carefully. >>> Endpoints can and should still choose a value that works best regardles= s of >>> the min in the spec. For example, Chrome is still using an interval of >>> 48ms (we're not in a rush to lower it, but we have non-browser endpoint= s >>> that do go lower). And if we roll out a lower value, it will be via >>> experiments or opt-ins and carefully tracked to make sure connectivity >>> rates don't drop. If any problem were found in practice, it would be >>> quickly reverted. >>> >>> 2. I don't think there is any interop risk here related to nomination >>> either. >>> Chrome's default behavior has never been compliant to any spec anyway, >>> and it's never been an issue. And like with ping intervals, any change= s to >>> implementations will be done slowly and carefully. >>> >>> 3. I don't think it really matters to major implementations what the >>> dependency graph looks like. Whether some point to 5245 and others to = 8445 >>> or if all of them point to 8445, it doesn't matter, implementations wil= l >>> behave the same either way. Chrome, for example will adjust timings as >>> works well in practice (perhaps someday to below 20ms interval) regardl= ess >>> of which RFCs point to 8445 and which point to 5245. If interop issues >>> ever do come up, then they can be fixed. And that has nothing to do wi= th >>> which RFCs point to 5245 and which point to 8445. >>> >>> 5. You're going to need to test against different versions of differen= t >>> browser no matter what the RFC references are. ICE timings and nominat= ions >>> seem like the least of your testing problems. But on the flip side, Ch= rome >>> (and I assume other browsers) have been very slow and careful when maki= ng >>> changes to the ICE code. >>> >>> 6. FlexICE should go a long way to putting the web app in control of >>> the ICE behavior. So if you are worried about what browsers will do wi= th >>> ICE, I suggest supporting the FlexICE effort. In fact, it's the result= of >>> your proposal at TPAC in 2017 for wanting to have lower-level of contro= l of >>> ICE... If we get that into all the browsers, you won't have to worry a= ny >>> more about any of this because you'll be in control (assuming you contr= ol >>> the web app). >>> >> >>> Altogether, I don't see any reason to not reference 8445 everywhere, at >>> least not any related to interop risk and web browsers. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: >>> >>>> >>>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg < >>>> christer.holmberg@ericsson..com > >>>> wrote: >>>> >>>> > Cisco has implemented stuff that is WebRTC 1.0 compliant without thi= s >>>> change.. These gratuitous changes, years after the implementation were >>>> coded, with no real benefit will ensure that we are not >>>> > and will not become compliant with the RFC. It's unlikely we will >>>> upgrade to the new ICE until it has real befits. >>>> >>>> The main reason we did 8445 was because people had identified issues >>>> with 5245. The work was driven mostly by the WebRTC community, includi= ng >>>> yourself and the Chrome people (or, at least the Google people), and o= ne of >>>> the reason it took time to finalize 8445 was because you (among others= ) >>>> wanted to make sure we get things right (by making network measurement= s >>>> etc). Are you now saying all those changes bring no benefit? Did we al= l >>>> waste our time? >>>> >>>> >>>> Our testing, which we do not share, dig not indicate an improvement of >>>> connectivity rates. I did not see results from others that did. Some o= f the >>>> early test results from others that drove this work were not reproduci= ble >>>> in our testing. The one thing I think most people did find is that the= more >>>> out of sync the pacing of the two agents was, the worse the connectivi= ty >>>> was. But all of this is water under the bridge, we have old and new ic= e, >>>> people can use either. What we are talking about here is what is the >>>> minimum bar for WebRTC 1.0 >>>> >>>> >>>> > It is doubtful Justin will want to implement the 8445 mechanisms of >>>> supporting both new and old ICE. Instead, we will move to say "works >>>> with Browser X version Y or later." We have watched at W3C as it moved= to >>>> be that unless chrome does it, it rare that it becomes a standard. >>>> > Right here I am watching how the stuff IETF defines will be less >>>> relevant than the issue of what chrome implements. >>>> >>>> What exactly would Justin have to change? >>>> >>>> >>>> >>>> For us, the largest part is having to test for both old and new - it= =E2=80=99s >>>> not easy to do good automated testing for ICE. >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> _______________________________________________ >> >> >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --00000000000060d8e5057811d87f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher <pthatcher= =3D40googl= e.com@dmarc.ietf.org> wrote:


On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org" target=3D"_blank">40google.co= m@dmarc.ietf.org> wrote:
I agree with Peter. Chrome's implement= ation is already closer to 8445 than 5245, so I don't see any issues as= sociated with snapping this cluster to 8445 (aside from the work involved).=

On that topic, note that JSEP will need a few more chan= ges than just the addition of the 8445 reference and note; the examples wil= l have to be updated, as will the logic regarding generation of offers and = answers and their parsing (to deal with the new ice-option). These changes = will be modest but probably will need to be done by the authors.


I've updated the references to 84= 45 (and to=C2=A0draft-ietf-mmusic-ice-sip-sdp) in this PR:=C2=A0https://githu= b.com/rtcweb-wg/jsep/pull/851

I've also ad= ded the ice2 processing and added ice2 to the examples in the same PR.=C2= =A0

Thanks for doing this= , Peter.=C2=A0=C2=A0

What did y= ou mean by "and note"?=C2=A0 Is there something more needed?

The note in question is the t= ext that Adam mentioned in the original email:

= While this specification formally relies on [RFC8445], at the time of its p= ublication, the majority of WebRTC implementations support the version of I= CE described in [RFC5245], and use a pre-standard version of the trickle ic= e mechanism described in [RFCXXXX]. The use of the "ice2" attribu= te defined in [RFC8445] can be used to detect the version in use by a remot= e endpoint and to provide a smooth transition from the older specification = to the newer one.=C2=A0

I do think we n= eed text similar to this to be added to S 5.11 (processing an answer) in JS= EP.
=C2=A0
On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pt= hatcher=3D= 40google.com@dmarc.ietf.org> wrote:
I'm late to the discussion, and reading through it, it seems tha= t we have a lot of back and forth without addressing Cullen's root issu= e.=C2=A0 Let me see if I understand Cullen's root issue correctly.=C2= =A0 I think it's something like:

1.=C2=A0 Cisc= o has existing code that it wants to call "WebRTC 1.0 compliant" = without changing to be compliant with 8445.

2.=C2= =A0 Cisco has existing code that it wants to continue to interoperate with = endpoints, especially Chrome, even as they make changes to become 8445 comp= liant.=C2=A0 And they don't want to have to test against old and new ve= rsions.=C2=A0=C2=A0

Cullen, is that accurate?



OK, so some of my though= ts:

1.=C2=A0 I don't think there is any intero= p risk here at all related to timings.=C2=A0 If you're worried about th= e drop in minimum check interval going from 20ms to 5ms, don't.=C2=A0 J= ust because the spec allows for going that low doesn't mean endpoints w= ill.=C2=A0 And if they do, they'll do it carefully.=C2=A0 Endpoints can= and should still choose a value that works best regardless of the min in t= he spec.=C2=A0 For example, Chrome is still using an interval of 48ms (we&#= 39;re not in a rush to lower it, but we have non-browser endpoints that do = go lower).=C2=A0 And if we roll out a lower value, it will be via experimen= ts or opt-ins and carefully tracked to make sure connectivity rates don'= ;t drop.=C2=A0 If any problem were found in practice, it would be quickly r= everted.=C2=A0=C2=A0

2.=C2=A0 I don't think th= ere is any interop risk here related to nomination either.=C2=A0=C2=A0
Chrome's default behavior has never been compliant to any spec an= yway, and it's never been an issue.=C2=A0 And like with ping intervals,= any changes to implementations will be done slowly and carefully.=C2=A0=C2= =A0

3.=C2=A0 I don't think it really matters t= o major implementations what the dependency graph looks like.=C2=A0 Whether= some point to 5245 and others to 8445 or if all of them point to 8445, it = doesn't matter, implementations will behave the same either way.=C2=A0 = Chrome, for example will adjust timings as works well in practice (perhaps = someday to below 20ms interval) regardless of which RFCs point to 8445 and = which point to 5245.=C2=A0 If interop issues ever do come up, then they can= be fixed.=C2=A0 And that has nothing to do with which RFCs point to 5245 a= nd which point to 8445.

5.=C2=A0 You're going = to need to test against different versions of different browser no matter w= hat the RFC references are.=C2=A0 ICE timings and nominations seem like the= least of your testing problems.=C2=A0 But on the flip side, Chrome (and I = assume other browsers) have been very slow and careful when making changes = to the ICE code.

6.=C2=A0 FlexICE should go a long way to putting the web app in = control of the ICE behavior.=C2=A0 So if you are worried about what browser= s will do with ICE, I suggest supporting the FlexICE effort.=C2=A0 In fact,= it's the result of your proposal at TPAC in 2017 for wanting to have l= ower-level of control of ICE...=C2=A0 If we get that into all the browsers,= you won't have to worry any more about any of this because you'll = be in control (assuming you control the web app).=C2=A0

Altogether, I don't s= ee any reason to not reference 8445 everywhere, at least not any related to= interop risk and web browsers.






=C2= =A0




<= br>




On = Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings <fluffy@iii.ca> wrote:

On Sep 7, 2018, at 1:25 AM, Chr= ister Holmberg <christer.holmberg@ericsson..com> wrote:

> Cisco has implemented stu= ff that is WebRTC 1.0 compliant without this change..=C2=A0These g= ratuitous changes, years after the implementation were coded, with no real = benefit will ensure that we are not
>=C2=A0and will not become comp= liant with the RFC.=C2=A0It's unlikely we will upgrade to the = new ICE until it has real befits.=C2=A0
<= /u>=C2=A0
The main reason we did= 8445 was because people had identified issues with 5245. The work was driv= en mostly by the WebRTC community, including yourself and the Chrome people= (or, at least the Google people), and one of the reason it took time to fi= nalize 8445 was because you (among others) wanted to make sure we get thing= s right (by making network measurements etc). Are you now saying all those = changes bring no benefit? Did we all waste our time?

Our testing, which we do not share, dig not indicate an impro= vement of connectivity rates. I did not see results from others that did. S= ome of the early test results from others that drove this work were not rep= roducible in our testing. The one thing I think most people did find is tha= t the more out of sync the pacing of the two agents was, the worse the conn= ectivity was. But all of this is water under the bridge, we have old and ne= w ice, people can use either. What we are talking about here is what is the= minimum bar for WebRTC 1.0=C2=A0

=C2=A0
>= It is doubtful Justin will want to implement the 8445 mechanisms of suppor= ting both new and old ICE.=C2=A0Instead, we will move to say "= ;works with Browser X version Y or later." We have watched at W3C as i= t moved to be that unless chrome does it, it rare that it becomes a standar= d. =C2=A0
>=C2=A0Right here I am watching how the stuff IETF define= s will be less relevant than the issue of what chrome implements.=C2=A0
=C2=A0
What exactly would Justin have to change?<= /u>
=C2=A0<= /div>

For us, the largest part is having to test for both old a= nd new - it=E2=80=99s not easy to do good automated testing for ICE.=C2=A0<= /div>
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--00000000000060d8e5057811d87f-- From nobody Sat Oct 13 02:23:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBA4130ED3; Sat, 13 Oct 2018 02:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOFA15A1GPTX; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 778F5130DFB; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id e4-v6so15854539wrs.0; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sp9Nt9uE+JXulHdZQVT+BwLv9NztoQ+Rd9dmHrMralQ=; b=BT7QJGNmalxTS/AWqWfTAmxpgd+VQtm7Ucl0+OnfQZ3L4915LIEe3BK4nCwtHaGzLE Zw8mKNoWpWuhUwYE39uziadui6MpaqwGuB+wYknJfiPLsE76s1j+qaNEeLUwCSCP/bb/ cmEGIN7LeqX2306QVgo/hwP2dfbLn4pj/B6rXSbtUUd/N2BrVlvUwpHp/poEzNHEYf7a ISiJgT0JcYALp6uY1/lLY7L/9tat8EsgUWoDr8/lElNOxPl4Z+QMfR8NdsPIhiThoEoM fETCnE7yK34tcu77aidgmcKyBFUxZkqdHfda8jsZqpTG5pTfvWFxv9+AvTQGLM7/Vvje wPLg== 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=Sp9Nt9uE+JXulHdZQVT+BwLv9NztoQ+Rd9dmHrMralQ=; b=SStcxfpebV7wg/GrIcyl5eLL/kTxjHB3YBZJ69o+QTIkUpKXXyl6Pw9v1d44b0YIj4 B3PeVPMJWIALzskmct4mh6jE7oftAms+W16QZ7lLOKN5xoF6bJkgIizJefh7mlYvX7vh QR3vsPhlFfRHSNXaz0YHt0BPu/yijhDq2GQ0j+WTINhbnAMypRZjdzm7i0FTAqJ1lmVG 8+kRLhfye+fIqQf+1/cm8AN6wweneotMc4imjdDFGPL8dgw2Bh/19gG9PuxRFH+Na1g2 gdXvSiRqHnhvuNFHCXjj8EM5hOHJ8MI21D1OAbJKELbTQqN/6OGYB+BWaSmcVVYvFPj6 oKqw== X-Gm-Message-State: ABuFfojBlIYT7b5ZVpSkig0hKI+1pb7SwaKnUCDfu2iHm3w0Ll6VZpmI cpS8dUOHhPY9IDGONj/u3+h7FyVNRHvWDL4zBAdomw== X-Google-Smtp-Source: ACcGV60WWQuevL5fbD3oz4Gs8DzWxJeznaO8eAY/OgVF7CNyE1S+aMdU+7QwPHRRsrhRK2IcaVCgP1tz9/wrtcUzjcg= X-Received: by 2002:a5d:6648:: with SMTP id f8-v6mr8226804wrw.218.1539422589907; Sat, 13 Oct 2018 02:23:09 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> From: Sergio Garcia Murillo Date: Sat, 13 Oct 2018 11:22:58 +0200 Message-ID: To: Adam Roach Cc: Justin Uberti , pthatcher=40google.com@dmarc.ietf.org, mmusic@ietf.org, art@ietf.org, "Heather Flanagan (RFC Series Editor)" , clue@ietf.org, ice@ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000a1789e057818c0bb" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 13 Oct 2018 09:23:14 -0000 --000000000000a1789e057818c0bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable p0090 El lun., 1 oct. 2018 23:11, Adam Roach escribi=C3=B3: > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already closer to 8445 > > than 5245, so I don't see any issues associated with snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes than just > > the addition of the 8445 reference and note; the examples will have to > > be updated, as will the logic regarding generation of offers and > > answers and their parsing (to deal with the new ice-option). These > > changes will be modest but probably will need to be done by the authors= . > > > If I read what you're saying correctly, it sounds like you're talking > about changes that are significant enough that we'll have to put JSEP > through IETF last call and through the IESG again. That being the case, > and the rest of the cluster being so close to done, I'd really prefer to > see this done very soon, if such changes are required. When do you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000a1789e057818c0bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=C3=B3:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

_______________________________________________
rtcweb mailing list
rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /a>
--000000000000a1789e057818c0bb-- From nobody Sat Oct 13 10:34:16 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B5A130E45 for ; Sat, 13 Oct 2018 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZCQIJZj0; dkim=pass (1024-bit key) header.d=ericsson.com header.b=MtHuX631 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 1h7ZvEpr0sQx for ; Sat, 13 Oct 2018 10:34:12 -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 0A932130E3C for ; Sat, 13 Oct 2018 10:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539452049; x=1542044049; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e0NPLbBQ9LMbF3fDZ+7E9IoPkZ6jlguoaTVuM8za9Hg=; b=ZCQIJZj0hMr2HeRgSmJdNeDX45H61Upoog7YJH2NEr2yB9SOPteYPNefr6h8NNrL 4p2dNaWedHUCSXaoMlao5zbCd7r2JdGtQsnFAOAtH7UIZdaOvyXzE039qJ96XBWT yrWuGVZE47tzPDevDReEnr/8dKZMHj8O83XTBbdXdyg=; X-AuditID: c1b4fb25-55bff700000018b4-7c-5bc22c9164d2 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.CC.06324.19C22CB5; Sat, 13 Oct 2018 19:34:09 +0200 (CEST) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 19:34:09 +0200 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 19:34:09 +0200 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 13 Oct 2018 19:34:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BtaNDPU+FCILRsjDVxCrFyGlOGsgMc/Yws2ADX1m3gg=; b=MtHuX631mLp7uWAxYj8FvYcgV6m1bwLR5AgHQ7HBPLC/K4z/nqShVFfeM6tc8OW69xNTNVybWhvJm1uxiHV72V9zX4YT+ywGEM7VGLSDhLaDIDXIGZMC4rXwg2/T/wOkMgVjwZ83PBwGvk1ecTOdVwH4/vpq/gS8eUWAVHN+X9s= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB1054.eurprd07.prod.outlook.com (10.161.111.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12; Sat, 13 Oct 2018 17:34:07 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.020; Sat, 13 Oct 2018 17:34:07 +0000 From: Christer Holmberg To: Cullen Jennings CC: RTCWeb IETF Thread-Topic: [rtcweb] A couple of questions on SDP Identity attribute Thread-Index: AQHUYTNdgdx0fYUyP0+ZCWsqcc6KnaUah5WAgALqY2A= Date: Sat, 13 Oct 2018 17:34:06 +0000 Message-ID: References: , <8ECAF21E-F2C9-4FFF-9B19-39284A80F13E@iii.ca> In-Reply-To: <8ECAF21E-F2C9-4FFF-9B19-39284A80F13E@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.33.179.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1054; 6:DG2HdxHZcP12l6lyjTWP0+FAU5fCjHx/S7yYw7muwrGaE1z3LDoDq71eP/+Sq0wIFispFtD/z0hAsv21Z5qnwAM6FJhwwD3K9s+lqmvAgB2Q3F6SYjzgIiu8Cb/zv1WsBUnVVI7QfXdHMP+PRPUnR5zTUOPCx/gX5NgQIzvjmyojcwdgp8uKMWO7LCs0RRba8YZ/2G6wZs83rc2c2mcvEghuwHWtvhHhzVn1kKC5ymyLqwkWhoTu/3bnquPmxxZXRONAdYG4l/N24fr24eQpq0Nar3Efx2VbLMQKjxD5/Iq0rnlq9Cfq3IUMbGAdmWx5UXRQ5YzAGM6x+ZpqHca97+HTVsH/6kL9MnT09E2bTy1wXa/c5pihtp8Tg4lwHDBh1/FuEB7AAfR0JI5N8RYJyIb/wTDk8D+FFAGMnWTVJqv1wgjdBMFJtpxeg8RQupkiIQlA6Q7vHes9Li25kW6y1g==; 5:xCuAVI4ET0Eo3ZSuJk3Pjnx6PG+PshUb/sTCP5V/+B1vHCM/xQcm1TtM4mdXcT5iWydLHbjHmj8HdHNIOZS5yUzV7kBYVQkyq4c37H7jCF5U01FSmbSy6ZfnLg7d+i9xXzc+0clOssb6zT3bGB8/b1Cec2lMMuisdbR7/wtul4w=; 7:B0gh2VHDbB6vZ7rvWgY7G8vlcoSV8u/7TJCyQPlpptRFV7IDzyfbzHZKCjvT27fwx6a28NqFaFaowlbDCqQnY66t5aj1jPe74d9zjY2c8TyEGHVmsIyQUG3BNbyyJaj/laXdU11RAX0XsMe1qZcgHN0HUuheMS/InAX5+OpuD5dlJh7gJBEhqg2xFT8kV3FRhwliLZejmXFimmIBu06XAhlyqBunIq3aR31Ihl7Jd9XQvOnsz+uUYacFNwmP9tqj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5595d546-c4d3-49af-86c0-08d6313213d9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB1054; x-ms-traffictypediagnostic: VI1PR07MB1054: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991067); SRVR:VI1PR07MB1054; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1054; x-forefront-prvs: 082465FB26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(136003)(346002)(199004)(189003)(446003)(6436002)(5660300001)(97736004)(53936002)(19627405001)(3846002)(6116002)(256004)(229853002)(11346002)(33656002)(8676002)(5250100002)(486006)(76176011)(66066001)(81156014)(6506007)(8936002)(44832011)(105586002)(81166006)(55016002)(6246003)(6916009)(68736007)(9686003)(54896002)(6606003)(476003)(478600001)(86362001)(2900100001)(2906002)(99286004)(14454004)(186003)(7736002)(7696005)(26005)(25786009)(102836004)(74316002)(71190400001)(106356001)(4326008)(316002)(71200400001)(6346003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1054; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-microsoft-antispam-message-info: zwcuDVj/flxLJYKGTYHsVCQlOi14RmYct8BccdWR/nrK/YRxThEDphP/6amnx+y10J9WkWDMUSok5q48nOMzEguJIhr06bAiJzkGplgFn0Ce9z3S1t3UhXK7L3CtfxIKDuBT+qdZt8v04w+vmlf88PAmeDokGyswVPMQMtp0K1PbB1r0UVmrZvbEDwxm1/O60SVhqxHh73A9qPqbT194hROV1sAh0pZHaeNEq0kT1B8rfQGlzTVK1wJNab80V0vbMmgrATsywjCfcA2qVpgnFSfgnSvGzKOT7t7Np2kBYpzNTM37jbEO9t6ppOHH2fWOHciF5yFAQeI9I45XT17lb1GOH07b8fd1/kRyfuZWlQg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4782E84D6178451BE5310B8293E30VI1PR07MB4782eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5595d546-c4d3-49af-86c0-08d6313213d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2018 17:34:06.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1054 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOfu+bZ/O0WlpviiFTQxvm5dC7YLkH4pgUkREaLeVHyrOOfZN 0+gPIYZDW3hbXgIveWWVliZaiblp2irSskQKIS8U1gglmYk52nYU/O/3Ps/De55zOAwlaef7 MdkqLatRKZRSgSddd74/X1YRbkmP/FAVErfc/RfFPXKUCE/wkltb13nJUxMr6DQvzfN4BqvM LmA1EfFXPLMMlXqhujS8sOefkSpGDQdLEcMAPgwb06gUeTAS/ApB3wOPUuTpZDuCP1azkBjO YeqWmhitPBi7PypwDTQup6Cl/TZNnGoeNPzTITLMI5gYr+G7zhDgOChzhLlWeeNAeD8wS7mY wgdgtaNR4OI9OBHq71gRySSBYfWtgPBRGH7dyHMxjYOgSjfizojxBWhq0QtIvVxonvrkrurh zPebbXwXI7wX1t485JGzfOHLItkDGEPr4ARF2AeWFhx88hQB0NYjIvI++NhY5r4K4CEhzBob ETFksGw0UiSfCl9LvElmHMGKqZNPMqFgr/yxlc+Bz333hNu6frR+q8N+MBnm6HIUVb+jHuE8 eGe1uVmMd4O1bpEmuhxmjNUCwmHQ3vyLIiyDWoeF3qk3IaEJ+XAsdzU3M/qQnNVkX+O4PJVc xWp7kPP3mJ9uBA2gKVuCBWEGSb3EVJAlXcJXFHBFuRYEDCX1FscsmNMl4gxF0Q1Wk3dZk69k OQvyZ2ipr3gutjdNgjMVWjaHZdWsZtvlMR5+xShEVxWhifR6PNgJvXeV0+eeJGYGCKtTc7C1 b1LOrnxXidJ2vUwdrpUmbRoK2rqGUuK/rUfwzyzagpWm6MmzF4t/Xz851rVp8Eux18zUxETZ jOHa1OAjnGia3yEqlB1LwC9OPV8aEf2s0M/7+dsbdJdWn/XeDOxWS2Ija9aaQUpzWYqoUErD Kf4DcUVwBDkDAAA= Archived-At: Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 13 Oct 2018 17:34:14 -0000 --_000_VI1PR07MB4782E84D6178451BE5310B8293E30VI1PR07MB4782eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >> Q1: In an offer or answer, it allowed to include fingerprints that have >> NOT been used to assert the identity? > >Yes, I think they should because fingerprints can be used even if Identity= is not. In that case, I think the following text (Section 5.4.6.1.) is wrong: "The identity attribute attests to all "a=3Dfingerprint" attributes in the session description. It is therefore a session-level attribute. Multiple "a=3Dfingerprint" values can be used to offer alternative certificates for a peer. The "a=3Didentity" attribute MUST include all fingerprint values that are included in "a=3Dfingerprint" lines of the session description." In my opinion it clearly states that every fingerprint attribute is associa= ted with the identity attribute, and it is not allowed to include fingerpri= nt attributes that are not associated with the identity attribute. Regards, Christer --_000_VI1PR07MB4782E84D6178451BE5310B8293E30VI1PR07MB4782eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi,

>> Q1: In an offer or answ= er, it allowed to include fingerprints that have 
>> NOT been used to assert= the identity?
>
>Yes, I think they should because finge= rprints can be used even if Identity is not. 

In that case, I think the following text (Section 5.4.6.1.) is wr= ong:

   "The identity attribute attests to all "a=3D= fingerprint" attributes in
   the session description.  It is therefore a session-l= evel attribute.

   Multiple "a=3Dfingerprint" values can be used to off= er alternative
   certificates for a peer.  The "a=3Didentity"= attribute MUST include all
   fingerprint values that are included in "a=3Dfingerprint&= quot; lines of the
   session description."

In my opinion it clearly states that every fingerprint attribute is associa= ted with the identity attribute, and it is not allowed to include fingerpri= nt attributes that are not associated with the identity attribute.

Regards,

Christer
--_000_VI1PR07MB4782E84D6178451BE5310B8293E30VI1PR07MB4782eurp_-- From nobody Sat Oct 13 16:45:35 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881B81277D2 for ; Sat, 13 Oct 2018 16:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 v6dV1i5zQXzp for ; Sat, 13 Oct 2018 16:45:23 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 25815130E67 for ; Sat, 13 Oct 2018 16:45:23 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id n18-v6so11751503ioa.9 for ; Sat, 13 Oct 2018 16:45:23 -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=jcav3Zv9jT+jSncH5KgVBc4qYS1iX5y9XRNbI59zj6Q=; b=PnD5g2AXuKDVRdgCN1Z/lxQ2fhi8CoPWBDsNyncVVQSV5s6aHq1kVipYCqz4h+PcLU 60JSLnM2rwAcCPqK6y1KxMfIlzBBB+lpc8+/qT1Z9PNnF8hCIOU4dZx0N+EzT1XNdJmc br1LLoffoVdGuELccdKSAPr7z6sKeG5pfNE8iHJV970iBLSNiRMAUFOHJTohhoCvxpQ6 x2Lts75hXUzahRly/XXota5w6uL+A97csW5DLEj+ojnhN7kEUvwSWFmBHXryyNbP55O8 ns2fMnVC6ZKMxmBMgCP0E+tQnpz9d7hxnAbzf8BkHOOiDoZDD2ggl2KQatjU7xhf8yV6 4fSg== 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=jcav3Zv9jT+jSncH5KgVBc4qYS1iX5y9XRNbI59zj6Q=; b=uDxxPeRaduGs2on1ag/XizSeAeg3PHae26DF+Xa3qsngUUQzeCgp6V1hJmQ3AfM34g aUitnApVGprrvFXI4fKfYlNIXS0+cAR9pOgzK2VYGQxYp2SiMUf+Nx8r04o/7b93QzOw 7bqBNvp8D1h8kP/b81g+mnIqhMTmSMilbuMCyY4eahU1l3HVmr0t0jQpjyczFnp/kG8e xo8RuYY2vyZq2FVxZS178XWbQzIbue/BLOgXq7H+jFSsLfP/qiN4BYTnD3T+3xkFuCVe qO1dZXrvb2Ipr+bZs8/gvKtb70b9u4smn7x8ZCIPEU/y7CRfl6mH7wGibXBDyT2E+vZq WywA== X-Gm-Message-State: ABuFfog5zlOPa5WOik7xtvoOLiKYUNEtUXh+1oBz4kMov3f9Op8fHDQh GXlQVdSSOnDViHqTTXFDbhBoS2nNKdmrYZmwj9q4iw== X-Google-Smtp-Source: ACcGV614kY2yqpiKv5B3ESSAUHSb6aC1AZpKmDb3VB4qR+zCURaHSkF5zdOcJHsvMIU3NdFavEplpylfIGn44EALVq8= X-Received: by 2002:a6b:39c3:: with SMTP id g186-v6mr8512807ioa.32.1539474322029; Sat, 13 Oct 2018 16:45:22 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: From: Justin Uberti Date: Sat, 13 Oct 2018 16:45:09 -0700 Message-ID: To: Christer Holmberg Cc: Sergio Garcia Murillo , Adam Roach , "Heather Flanagan (RFC Series Editor)" , pthatcher=40google.com@dmarc.ietf.org, ice@ietf.org, RTCWeb IETF , juberti=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000001b9730057824cc19" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [clue] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 13 Oct 2018 23:45:27 -0000 --0000000000001b9730057824cc19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [removing DLs again] We are taking a few other outstanding issues as part of this rev (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think a new LC is warranted. Aiming for a new doc version on Monday. On Sat, Oct 13, 2018 at 1:50 PM Justin Uberti wrote: > We are taking a few other outstanding issues as part of this rev > (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which > you noted), so I think a new LC is warranted. > > Aiming for a new doc version on Monday. > > On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> Personally I don't think updating of references and examples require a >> new IETF last call. >> >> >> Do people foresee any changes to the technical JSEP procedures due to th= e >> reference update? >> >> >> Regards, >> >> >> Christer >> >> >> ------------------------------ >> *From:* clue on behalf of Sergio Garcia Murillo = < >> sergio.garcia.murillo@gmail.com> >> *Sent:* Saturday, October 13, 2018 12:22 PM >> *To:* Adam Roach >> *Cc:* mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series >> Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; >> ice@ietf.org; RTCWeb IETF; Justin Uberti >> *Subject:* Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and >> Cluster 238 >> >> p0090 >> >> El lun., 1 oct. 2018 23:11, Adam Roach > > escribi=C3=B3: >> >> On 9/27/18 6:20 PM, Justin Uberti wrote: >> > I agree with Peter. Chrome's implementation is already closer to 8445 >> > than 5245, so I don't see any issues associated with snapping this >> > cluster to 8445 (aside from the work involved). >> > >> > On that topic, note that JSEP will need a few more changes than just >> > the addition of the 8445 reference and note; the examples will have to >> > be updated, as will the logic regarding generation of offers and >> > answers and their parsing (to deal with the new ice-option). These >> > changes will be modest but probably will need to be done by the author= s. >> >> >> If I read what you're saying correctly, it sounds like you're talking >> about changes that are significant enough that we'll have to put JSEP >> through IETF last call and through the IESG again. That being the case, >> and the rest of the cluster being so close to done, I'd really prefer to >> see this done very soon, if such changes are required. When do you >> believe such an update could be available? >> >> I've copied the RFC Series Editor on this note for her awareness. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --0000000000001b9730057824cc19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 13, 2018 at 1:50 PM Justin Uberti <juberti@google.com> wrote:
We are taking a = few other outstanding issues as part of this rev (potentially including htt= ps://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think = a new LC is warranted.

Aiming for= a new doc version on Monday.

On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

Hi,


Personally I don't think upda= ting of references and examples require a new IETF last call.


Do people foresee any changes to = the technical JSEP procedures due to the reference update?=C2=A0


Regards,


Christer



From: clue <clue-bounces@ietf.org> on behalf of Sergio Garcia = Murillo <sergio.garcia.murillo@gmail.com>
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: mmusic@ietf= .org; art@ietf.org; Heather Flanagan (RFC Series Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; RTCWeb IETF= ; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and = Cluster 238
=C2=A0
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=C3=B3:
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--0000000000001b9730057824cc19-- From nobody Mon Oct 15 07:40:26 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B2130E80 for ; Mon, 15 Oct 2018 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 IKxydcVIkhHS for ; Mon, 15 Oct 2018 07:40:20 -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 5154A130E3E for ; Mon, 15 Oct 2018 07:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539614416; x=1542206416; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hvSdAVPtQDZDxYoFCfpzJiTweXSOmxXt2vVXM/fZ0ok=; b=BHi4KtoePI569GV02nXv34itANrpzbGiyxFF2cS7NPvFypNV21Yn8AGKyWNWaqvD 8p8ZWWPFBrKmgUH+HWmGlG4NR6YoKS+xRVMWkiwwns49M2+8kMoitIfscAPL3jIG EY6iNoVgGsBEymNsj0rd6UIE3iS3oPNrVaRrJ5mAMN8=; X-AuditID: c1b4fb30-2bbff700000047d2-1b-5bc4a6cf7990 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.81.18386.FC6A4CB5; Mon, 15 Oct 2018 16:40:15 +0200 (CEST) Received: from [100.94.48.21] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 15 Oct 2018 16:40:15 +0200 To: Suhas Nandakumar CC: , References: From: Magnus Westerlund Message-ID: <8334a2c9-c2f2-bfff-f51b-b0a561df106d@ericsson.com> Date: Mon, 15 Oct 2018 16:40:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010506020008060602040705" X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESSMB501.ericsson.se (153.88.183.162) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2J7he75ZUeiDQ4vt7GYuGIdm8Xaf+3s FjvndjA7MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBndk7YxFrReYKr4+3QNWwPjjJlM XYycHBICJhIr+qawdzFycQgJHGWUeN75kQ3Cecco8fnsTmaQKmEBd4m9p7pZQGwRAS2J1Yvn gnUzC5hLnJzUD9XdxigxqWUTI0iCTcBC4uaPRjYQm1fAXuLTim9gDSwCqhJzfl8HGyoqECvx 6cpiZogaQYmTM5+ALeAUCJSY/egGK8SCbkaJXcd5QWwhAW2JhqYOVoizlSSuz7sOVM8BZKdL vD7NN4FRcBaSSbOQdEPYYRIbns9lh7DFJW49mc8EYZtJzNv8kBnCVpSY0v0QqIYDyFaTWNaq BBHWlli28DVUibXEjF8H2VCVg9imEq+PfmSEsI0llq37y7aAkWcVo2hxanFSbrqRkV5qUWZy cXF+nl5easkmRmBUHtzy22AH48vnjocYBTgYlXh4leceiRZiTSwrrsw9xKgCNOfRhtUXGKVY 8vLzUpVEeCVCDkUL8aYkVlalFuXHF5XmpBYfYpTmYFES57Xw2xwlJJCeWJKanZpakFoEk2Xi 4JRqYFy0c65Pml6PdtvDZ7UtNUKzhO3ubdNxnvv06/Yn095Wvq2V2dpXU+BXbaCWxVn5ad0m vctHWH0edfe3xTIfMHU+lcrHVnks21JNQKinQfbYsh6p3f/vGm3m+ObyIsNod0n3xt17NY5c 8vPavLOruV+Ca9Z3keWbd6TrSCy65/czaZ36tvvcf5RYijMSDbWYi4oTAUi9EODSAgAA Archived-At: Subject: Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 15 Oct 2018 14:40:24 -0000 --------------ms010506020008060602040705 Content-Type: multipart/alternative; boundary="------------B5232B3BC5832FEDDD9D7625" Content-Language: en-US This is a multi-part message in MIME format. --------------B5232B3BC5832FEDDD9D7625 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBsb29rZWQgYXQgdGhlIGNoYW5nZXMgaW4gLTExLiBJIGhhdmUgc29t ZSBxdWVzdGlvbnMuDQoNCjEuIEluIHRhYmxlIDI5LCBzZWN0aW9uIDUuMy4yIHJlZ2FyZGlu ZyB0aGUgSC4yNjQtU1ZDLg0KDQogwqDCoCB8IGE9Zm10cDoxMDAgcHJvZmlsZS1sZXZlbC3C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBbUkZDNjE5MF0gSC4yNjTC oMKgwqDCoCB8DQogwqDCoCB8IGlkPTUzMDAxZjtwYWNrZXRpemF0aW9uLW1vZGU9MMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgU2NhbGFibGUgRW5jb2RpbmfCoMKgIHwNCg0KV2h5 IGFyZSB5b3UgdXNpbmcgcGFja2V0aXphdGlvbi1tb2RlPTA/IEZvciBTVkMgaW4gU1NULCB3 b3VsZG4ndCBtb2RlPTEgDQpiZSB0aGUgbW9zdCByZWFzb25hYmxlIGNob2ljZT/CoCBOb3Qg dGhhdCBpdCB3aWxsIG5vdCB3b3JrLCBidXQgcHV0dGluZyANCmFsbCB0aGUgbWV0YSBkYXRh IE5BTFVzIGludG8gdGhlaXIgb3duIFJUUCBwYWNrZXRzIHNlZW1zIHVubmVjZXNzYXJ5Lg0K DQoyLiBUYWJsZSAzMCwgc2FtZSBxdWVzdGlvbiBhcyAxKQ0KDQpPdGhlcndpc2UgdGhlIGNo YW5nZXMgcmVsYXRlZCB0byBteSByZXZpZXcgbG9va3MgZ29vZC4NCg0KQ2hlZXJzDQoNCk1h Z251cw0KDQpPbiAyMDE4LTEwLTEwIDA1OjQyLCBTdWhhcyBOYW5kYWt1bWFyIHdyb3RlOg0K PiBIZWxsbyBNYWdudXMNCj4NCj4gwqBBcG9sb2dpZXMgdGhhdCB0aGlzIHRvb2sgYSB3aGls ZS4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+DQo+IE9uIFdlZCwgSnVsIDQsIDIwMTggYXQgNzo1 NyBBTSBNYWdudXMgV2VzdGVybHVuZCANCj4gPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbSANCj4gPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCj4NCj4gICAgIEhpLA0KPg0KPiAgICAgSSBoYXZlIHJldmlld2VkIFNlY3Rpb24gNS4z IG9ubHkgd2l0aCBhIGZvY3VzIG9uIHRoZSBzaW11bGNhc3QgYW5kDQo+ICAgICBtdWx0aS1z dHJlYW0gYXNwZWN0cy4gRm9yIGV4YW1wbGUgSSBoYXZlIG5vdCBjYXJlZCBpZiB0aGUgSUNF IGRldGFpbHMNCj4gICAgIGFyZSBjb3JyZWN0IGluIHRoZXNlIGV4YW1wbGVzLg0KPg0KPiBU aGFua3MgZm9yIHRoZSByZXZpZXcuIEkgaGF2ZSBzdWJtaXR0ZWQgLTExIHZlcnNpb24gdGhh dCBzaG91bGQgDQo+IGFkZHJlc3MgdGhlIHJldmlldyBjb21tZW50cy4NCj4NCj4NCj4gICAg IEEuIFNlY3Rpb24gNS4zLjE6DQo+DQo+ICAgICBCVU5ETEUgZ3JvdXBpbmcgZnJhbWV3b3Jr IGVuYWJsZXMgbXVsdGlwbGV4aW5nIG9mIGFsbCB0aGUgNSBzdHJlYW1zDQo+ICAgICDCoMKg wqAgKDEgYXVkaW8gc3RyZWFtICsgNCB2aWRlbyBzdHJlYW1zKSBvdmVyIGEgc2luZ2xlIFJU UCBTZXNzaW9uLg0KPg0KPiAgICAgSXQgbWlnaHQgYmUgZ29vZCB0byB1c2UgUkZDIDc2NTYg dGVybWlub2xvZ3kgYW5kIGJlIHNwZWNpZmljIGluIHRoYXQNCj4gICAgIHRoaXMgcmVzdWx0 cyBpbiA1IHNvdXJjZSBSVFAgc3RyZWFtcy4NCj4NCj4NCj4gW1N1aGFzXSBEb25lDQo+DQo+ ICAgICBCLiBTZWN0aW9uIDUuMy4xLg0KPg0KPiAgICAgQXMgNS4zIHNheXMgdGhhdCB0aGlz IHdpbGwgdXNlIEZFQyBvciBSVFggYW5kIHRoaXMgb25lIGRvZXNuJ3QNCj4gICAgIG1heWJl IGJlDQo+ICAgICBleHBsaWNpdCB0aGF0IGl0IGlzIG5vdCBhZGRlZCwgb3IgcmV3cml0ZSA1 LjMuDQo+DQo+DQo+IFtTdWhhc10gVXBkYXRlIHRoZSBkZXNjcmlwdGlvbiB0byBtZWFuIHNv bWUgZXhhbXBsZXMgaGF2ZSBGRUMvUlRYIGFuZCANCj4gbm90IGFsbC4NCj4gVGhlIGlkZWEg d2FzIHRvIGhhdmUgdGhpcyBzZWN0aW9uIHdpdGggZXhhbXBsZXMgdGhhdCBjb3ZlciBhbGwg dGhlc2UgDQo+IGNhc2VzIGJ1dA0KPiBub3QgdG8gaGF2ZSBhbGwgdGhlc2UgaW4gYWxsIHRo ZSBleGFtcGxlcy4NCj4NCj4NCj4gICAgIEMuIHNlY3Rpb24gNS4zLjE6DQo+DQo+ICAgICDC oMKgwqAgfCBhPWdyb3VwOkxTIG0wIG0xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4gICAgIFtSRkM1ODg4XcKgwqDCoMKgwqDC oMKgwqDCoMKgIHwNCj4NCj4gICAgIElzIGl0IGludGVudGlvbmFsIHRoYXQgdmlkZW8gMiBp cyBub3QgaW5jbHVkZWQgaW4gdGhlIGxpcC1zeW5jaA0KPiAgICAgZ3JvdXA/DQo+ICAgICBN YXkgcmVxdWlyZSBhIGludGVudGlvbiBjb21tZW50IGZvciB0aGlzIGNhc2UuDQo+DQo+DQo+ IFtTdWhhc10gLiBUaGUgaW50ZW50aW9uIHdhcyB0byBncm91cCBvbmUgQVYgaW4gYSBsaXAg c3luYw0KPiBncm91cCBhbmQgb3RoZXIgY2FuIGJlIGEgbm9uLWludGVyYWN0aXZlIHN0cmVh bS4gVXBkYXRlZCB0aGUgdGV4dCB0bw0KPiBpbmRpY2F0ZSB0aGUgc2FtZS4NCj4NCj4NCj4g ICAgIEQuIDUuMy4xOg0KPg0KPiAgICAgwqDCoMKgIE9uZSB2aWRlbyBzb3VyY2UgY29ycmVz cG9uZHMgdG8gVlA4IGVuY29kaW5nLCB3aGlsZSB0aGUgb3RoZXINCj4gICAgIMKgwqDCoCBj b3JyZXNwb25kcyB0byBILjI2NCBlbmNvZGluZy4NCj4NCj4gICAgIEFzIHRoZSBtPSBibG9j ayByZXByZXNlbnRzIGEgbWVkaWEgc291cmNlLCBpZiB0aGUgbmVlZCBpcyB0bw0KPiAgICAg cHJvdmlkZSBvbmUNCj4gICAgIHZpZGVvIGNhbWVyYSdzIGltYWdlcyAodGhlIG1lZGlhwqAg c291cmNlKSBhcyBib3RoIFZQOCBhbmQgSC4yNjQgd2hlcmUNCj4gICAgIGVhY2ggYXJlIGlu IHR3byBkaWZmZXJlbnQgcmVzb2x1dGlvbnMsIHRoZW4gc2ltdWxjYXN0IGNhbiBoYW5kbGUg dGhhdA0KPiAgICAgZmluZSB3aXRoaW4gYSBzaW5nbGUgbT0gYmxvY2suIFNvIGZyb20gbXkg cGVyc3BlY3RpdmUgdGhpcyBpcyBhDQo+ICAgICB3cm9uZ2x5DQo+ICAgICBjb25zdHJ1Y3Rl ZCBleGFtcGxlIGZyb20gdGhhdCBwcmVtaXNlLiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IGlm IHlvdQ0KPiAgICAgd2FudCB0d28gbWVkaWEgc291cmNlLCBpLmUuIHR3byBjYW1lcmFzLCBv ciB0d28gZW5jb2RlciBmb3JtYXRzDQo+ICAgICBWUDggYW5kDQo+ICAgICBILjI2NCwgb3Ig dHdvIHJlc29sdXRpb25zLCBvciBhbnkgY29tYmluYXRpb24gb2YgdGhlbT8NCj4NCj4gICAg IEkgd291bGQgcmVjb21tZW5kIHRoaXMgZXhhbXBsZSB0byBiZSB0d28gbWVkaWEgc291cmNl cywgd2l0aCBlbmNvZGluZw0KPiAgICAgc2ltdWxjYXN0LiBUaGUgcmVzb2x1dGlvbiBjYW4g YmUgc2tpcHBlZCBhcyB0aGUgbGF0ZXIgZXhhbXBsZQ0KPiAgICAgaW5jbHVkZXMNCj4gICAg IHJlc29sdXRpb24gc2ltdWxjYXN0aW5nLg0KPg0KPg0KPiBbU3VoYXNdLiBZZXMsIHRoZSBl eGFtcGxlIHdhbnRlZCB0byBzaG93Y2FzZSAyIGRpZmZlcmVudCBtZWRpYSBzb3VyY2VzIA0K PiAob25lIGVuY29kZWQNCj4gwqBhcyB2cDggYW5kIGFub3RoZXIgYXMgaDI2NCwgY2FuIGJl IG5hdGl2ZWx5IGVuY29kZWQgYXMgd2VsbCkgYW5kwqAgDQo+IGVhY2ggYmVpbmcgc2VudCBh dA0KPiDCoDIgZGlmZmVyZW50IHJlc29sdXRpb25zLg0KPg0KPiAgICAgRS4gU2VjdGlvbiA1 LjMuMToNCj4NCj4gICAgIMKgwqDCoCB8IGE9cnRjcC1mYjoqIG5hY2vCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgW1JG QzUxMDRdwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPg0KPiAgICAgwqDCoMKgIHwgYT1ydGNw LWZiOiogbmFjayBwbGnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHwNCj4gICAgIFtSRkM1MTA0XcKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4NCj4g ICAgIEkgd291bGQgbm90ZSB0aGF0IGdlbmVyYWxpemVkIE5BQ0sgYXMgd2VsbCBhcyBwaWN0 dXJlIGxvc3MgaW5kaWNhdGlvbg0KPiAgICAgKFBMSSkgaXMgZGVmaW5lZCBpbiBSRkM0NTg1 Lg0KPg0KPg0KPiBbU3VoYXNdIERvbmUsIHVwZGF0ZWQgYWxsIHRoZSByZWZlcmVuY2VzLg0K Pg0KPg0KPiAgICAgRi4gU2VjdGlvbiA1LjMuMjoNCj4NCj4gICAgIMKgwqDCoCBUaGlzIHNl Y3Rpb24gc2hvd3MgYW4gU0RQIE9mZmVyL0Fuc3dlciBmb3IgYSBzZXNzaW9uIHdpdGggYW4g YXVkaW8NCj4gICAgIMKgwqDCoCBhbmQgYSBzaW5nbGUgdmlkZW8gc291cmNlLsKgIFRoZSB2 aWRlbyBzb3VyY2UgaXMgZW5jb2RlZCBhcyBsYXllcmVkDQo+ICAgICDCoMKgwqAgY29kaW5n IGF0IDMgZGlmZmVyZW50IHJlc29sdXRpb25zIGJhc2VkIG9uIFtSRkM1NTgzXS4gVGhlIHZp ZGVvDQo+ICAgICDCoMKgwqAgbT1saW5lIHNob3dzIDMgc3RyZWFtcyB3aXRoIGxhc3Qgc3Ry ZWFtIChwYXlsb2FkIDEwMCkgZGVwZW5kZW50IG9uDQo+ICAgICDCoMKgwqAgc3RyZWFtcyB3 aXRoIHBheWxvYWQgOTYgYW5kIDk3IGZvciBkZWNvZGluZy4NCj4NCj4gICAgIEFsc28gaGVy ZSB1c2Ugb2YgUkZDIDc2NTYgdGVybWlub2xvZ3kgdG8gdGFsayBhYm91dCAoc291cmNlKSBS VFANCj4gICAgIHN0cmVhbXMNCj4gICAgIHdoZW4gYXBwbGljYWJsZSB3b3VsZCBiZSBnb29k Lg0KPg0KPg0KPiBbU3VoYXNdIFVwZGF0ZWQuDQo+DQo+DQo+ICAgICBHLiBTZWN0aW9uIDUu My4yOg0KPg0KPiAgICAgwqDCoCB8IGE9cnRwbWFwOjk2IEgyNjQvOTAwMDDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgW1JGQzYxODRdwqDC oMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwgYT1mbXRwOjk2IHByb2ZpbGUt bGV2ZWwtaWQ9NGQwMDI4O8KgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAgICBbUkZDNjE4NF1I LjI2NMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwgcGFja2V0aXphdGlvbi1tb2RlPTE7 bWF4LWZyPTMwO21heC1mcz04MDQwwqAgfCBMYXllcg0KPiAgICAgMcKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8DQo+ICAgICDCoMKgwqAgfCBhPXJ0cG1hcDo5NyBIMjY0LzkwMDAwwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4gICAgIFtSRkM2 MTg0XcKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4gICAgIMKgwqDCoCB8IGE9Zm10cDo5NyBw cm9maWxlLWxldmVsLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwg W1JGQzYxODRdDQo+ICAgICBILjI2NMKgwqDCoMKgIHwNCj4gICAgIMKgwqDCoCB8IGlkPTRk MDAyODtwYWNrZXRpemF0aW9uLW1vZGU9MTsgbWF4LcKgwqDCoMKgwqDCoMKgIHwgTGF5ZXIN Cj4gICAgIDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwgZnI9 MTU7bWF4LWZzPTEyMDAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfA0KPiAgICAgwqDCoMKgIHwgYT1ydHBtYXA6MTAwIEgyNjQtU1ZDLzkwMDAwwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgW1JGQzYxODRdwqDCoMKgwqDC oMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwgYT1mbXRwOjEwMCBwcm9maWxlLWxldmVs LcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAgICBbUkZDNjE4 NF3CoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAgICDCoMKgwqAgfCBpZD00ZDAwMjg7cGFj a2V0aXphdGlvbi1tb2RlPTE7IG1heC0gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwgZnI9MzA7bWF4LWZzPTgwNDAgfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAgICAgwqDCoMKgIHwg YT1kZXBlbmQ6MTAwIGxheSBtMTo5Niw5N8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8IFtSRkM1NTgzXUxheWVyDQo+ICAgICAzwqDCoMKgIHwNCj4NCj4gICAgIEkg aGF2ZSBteSBkb3VidHMgYWJvdXQgdGhpcyBjb25maWd1cmF0aW9uLiBGaXJzdCBvZiBhbGwg YXMgaXQgaXMNCj4gICAgIFNWQyBpbg0KPiAgICAgU2luZ2xlIFJUUCBzZXNzaW9uIG1vZGUg KFNTVCkgSSBkb24ndCB0aGluayBpdCByZXN1bHRzIGluIG11bHRpcGxlDQo+ICAgICBSVFAN Cj4gICAgIHN0cmVhbXMuIEkgdGhpbmsgdGhlIGFuc3dlcmVyIHdpbGwgaW50ZXJwcmV0IHRo aXMsIHdoaWNoIG9mIHRoZXNlDQo+ICAgICBlbmNvZGluZ3MgY2FuIHN1cHBvcnQuIEEgbm9u IHNjYWxhYmxlIEguMjY0LCBhbm90aGVyIG5vbi1zY2FsYWJsZQ0KPiAgICAgSC4yNjQNCj4g ICAgIG9yIFNWQyB0aGF0IGNhbiBjb250YWluIGEgbnVtYmVyIG9mIGxheWVycy4NCj4NCj4g ICAgIFNlY29uZGx5IGE9ZGVwZW5kIGlzIG9ubHkgZGVmaW5lZCBmb3IgTVNUIG1vZGUgaW4g UkZDIDYxOTAuDQo+DQo+ICAgICBZb3UgYWxzbyBoYXZlIHRoZSB3cm9uZyByZWZlcmVuY2Ug Zm9yIHRoZSBILTI2NC1TVkMgYT1ydHBtYXAgYW5kDQo+ICAgICBhPWZtdHANCj4gICAgIGxp bmUuDQo+DQo+DQo+IFtTdWhhc10gQWdyZWVkIE1hZ251cy4gT24gcmUtcmVhZGluZyB0aGUg ZXhhbXBsZSBpdCBjb25mdXNlZCBtZSBhcyANCj4gd2VsbCA6LSkNCj4gVXBkYXRlIHRoZSBl eGFtcGxlIHRvIHJlcHJlc2VudCBTU1QgbW9kZSBTVkMgY29uZmlndXJhdGlvbi4NCj4NCj4N Cj4gICAgIEguIFNlY3Rpb24gNS4zLjM6DQo+DQo+ICAgICDCoMKgwqAgfCBhPWV4dG1hcDoz IHVybjppZXRmOnBhcmFtczpydHAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4gICAg IFtJLUQuaWV0Zi1hdnRleHQtcmkgfA0KPiAgICAgwqDCoMKgIHwgaGRyZXh0OnNkZXM6cnRw LXN0cmVhbS1pZMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAg ICBkXcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPg0KPiAgICAgQWZ0 ZXIgdGhpcyBsaW5lIHlvdSBzaG91bGQgaGF2ZSBhbHNvIHRoaXMgbGluZToNCj4NCj4gICAg IMKgwqDCoCB8IGE9ZXh0bWFwOjQgdXJuOmlldGY6cGFyYW1zOnJ0cC3CoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfA0KPiAgICAgW0ktRC5pZXRmLWF2dGV4dC1yaSB8DQo+ICAgICDCoMKg wqAgfCBoZHJleHQ6c2RlczpyZXBhaXJlZC1ydHAtc3RyZWFtLWlkwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4gICAgIGRdwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8DQo+DQo+ICAgICBUaGlzIHRvIGVuYWJsZSB0aGUgUlRYIHN0cmVh bXMgdG8gaW5kaWNhdGUgd2hpY2ggc291cmNlIFJUUCBzdHJlYW0NCj4gICAgIHRoZXkNCj4g ICAgIGFyZSByZXBhaXJpbmcuIEFkZCB0byBib3RoIG9mZmVyIGFuZCBhbnN3ZXIuDQo+DQo+ DQo+IFtTdWhhc10gR29vZCBjYXRjaC4gQWRkZWQgaXQuDQo+DQo+DQo+ICAgICBJLiBTZWN0 aW9uIDUuMy4zDQo+DQo+ICAgICBXaHkgaXNuJ3QgUlRYIGVuYWJsZWQgZm9yIHRoZSBhdWRp byBhbHNvPw0KPg0KPg0KPiBbU3VoYXNdIE5vIFNwZWNpZmljIHJlYXNvbi4gVGhlc2UgYXJl IGp1c3QgZXhhbXBsZXMgdG8gc2hvdyANCj4gY29uZmlndXJhdGlvbnMgYW5kIHRodXMgcGlj a2VkIE1WUA0KPiBjb25maWd1cmF0aW9ucyB0byBzaG93IHRoZSB1c2FnZSBvZiBTRFAgZm9y IHNjZW5hcmlvIGF0IGhhbmQgdGhhbiANCj4gZGVzY3JpYmluZyBhbGwgcG9zc2libGUNCj4g b3B0aW9ucy4NCj4NCj4NCj4gICAgIEouIFNlY3Rpb24gNS4zLjMuIEFuc3dlcjoNCj4NCj4g ICAgIMKgwqAgfCBtPXZpZGVvIDAgVURQL1RMUy9SVFAvU0FWUEYgOTggMTAwIDEwMSAxMDPC oCB8IEJVTkRMRQ0KPiAgICAgYWNjZXB0ZWTCoMKgwqDCoCB8DQo+DQo+ICAgICBQYXlsb2Fk IHR5cGVzIDEwMCBhbmQgMTAxIGFyZSB1bmRlZmluZWQgaW4gdGhpcyBtZWRpYSBkZXNjcmlw dGlvbi4NCj4NCj4NCj4gW1N1aGFzXSBUaGFua3MgZm9yIGNhdGNoaW5nIHRoaXMuIE1hdGNo ZWQgdGhlIGFuc3dlciB3aXRoIHRoZSBvZmZlciBub3cuDQo+DQo+DQo+ICAgICBLLiBTZWN0 aW9uIDUuMy40IEFuc3dlcjoNCj4NCj4gICAgIMKgwqDCoCB8IGE9cnRwbWFwOjEwMSBWUDgv OTAwMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiAg ICAgW1JGQzc3NDFdwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPg0KPiAgICAgV3JvbmcgbWVk aWEgdHlwZSBmb3IgdGhlIHBheWxvYWQgc2hvdWxkIGJlIFJUWC4NCj4NCj4NCj4gW1N1aGFz XSBOaWNlIGZpbmQuIEZpeGVkIGl0Lg0KPg0KPg0KPiAgICAgTC4gU2VjdGlvbiA1LjMuNCBB bnN3ZXI6DQo+DQo+ICAgICBNaXNzaW5nIHJ0Y3AtZmIgZGVmaW5pdGlvbnMgdG8gZW5hYmxl IHVzZSBvZiBOQUNLIHdoaWNoIFJUWA0KPiAgICAgZGVwZW5kcyBvbi4NCj4NCj4NCj4gW1N1 aGFzXSBBZ3JlZWQuIEFkZGVkIGl0Lg0KPg0KPg0KPiAgICAgTS4gU2VjdGlvbiA1LjMuNToN Cj4NCj4gICAgIMKgwqB8IGE9Zm10cDoxMDEgTD01OyBEPTEwOyBUb1A9MjsgcmVwYWlyLcKg wqDCoMKgwqDCoMKgIHwNCj4gICAgIFtJLUQuaWV0Zi1wYXlsb2FkLWYgfA0KPiAgICAgwqDC oMKgIHwgd2luZG93PTIwMDAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAgICBsZXhpYmxlLWZlYy1zY2hlbWVd IHwNCj4gICAgIMKgwqDCoCB8IGE9Zm10cDoxMDMgTD01OyBEPTEwOyBUb1A9MjsgcmVwYWly LcKgwqDCoMKgwqDCoMKgIHwNCj4gICAgIFtJLUQuaWV0Zi1wYXlsb2FkLWYgfA0KPiAgICAg wqDCoMKgIHwgd2luZG93PTIwMDAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+ICAgICBsZXhpYmxlLWZlYy1zY2hl bWVdIHwNCj4NCj4gICAgIEFzIHRoZSBwYXJhbWV0ZXJzIGFyZSB0aGUgc2FtZSwgSSBkb24n dCBzZWUgYSBwb2ludCB3aXRoIGhhdmluZyB0d28NCj4gICAgIHBheWxvYWQgdHlwZXMuIFR3 byBkaWZmZXJlbnQgUlRQIHJlcGFpciBzdHJlYW1zIGNhbiB1c2UgdGhlIHNhbWUNCj4gICAg IHBheWxvYWQNCj4gICAgIHR5cGUuIEFzIEZsZXgtRkVDIGNhbiBkbyBhbGwgdGhlIGJpbmRp bmcgdXNpbmcgdGhlIENTUkMgZmllbGQsDQo+ICAgICB0aGVyZSBhcmUNCj4gICAgIGFsc28g bm8gbmVlZCB0byBoYXZlIHRoZSByZXBhaXJlZC1ydHAtc3RyZWFtLWlkIGhlYWRlciBleHRl bnNpb24gZm9yDQo+ICAgICB0aGlzIG9uZS4NCj4NCj4NCj4gW1N1aGFzXSBHb29kIHBvaW50 LiBNb3ZlZCB0byBqdXN0IG9uZSBQVC4gQWxzbyBpIHRoaW5rIHlvdSBpbnRlbmQgdG8NCj4g aW5jbHVkZcKgIHJlcGFpcmVkLXJ0cC1zdHJlYW0taWQgZm9yIHRoaXMgZXhhbXBsZSB0b28g Pw0KPg0KPg0KPiAgICAgTi4gU2VjdGlvbiA1LjMuNToNCj4NCj4gICAgIERvZXMgaXQgbWFr ZSBzZW5zZSB0byBzdGlsbCBoYXZlIE5BQ0sgZm9yIGEgc2Vzc2lvbiB3aXRoIEZFQy4gSWYg aXQNCj4gICAgIGZhaWxzIGlzbid0IFBMSSBvciBGSVINCj4NCj4NCj4gW1N1aGFzXSBEb250 IHRoaW5rIGl0cyBuZWVkZWQuIFJlbW92ZWQgbmFjayBhbmQga2VwdCBwbGkNCj4NCj4NCj4g ICAgIENoZWVycw0KPg0KPiAgICAgTWFnbnVzIFdlc3Rlcmx1bmQNCj4NCj4gICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gICAgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlICYgUHJvdG9jb2xzLCBF cmljc3NvbiBSZXNlYXJjaA0KPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgRXJpY3Nz b24gQULCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgUGhvbmXCoCArNDYgMTAgNzE0ODI4 Nw0KPiAgICAgVG9yc2hhbW5zZ2F0YW4gMjPCoCDCoCDCoCDCoCDCoCDCoHwgTW9iaWxlICs0 NiA3MyAwOTQ5MDc5DQo+ICAgICBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWls dG86DQo+ICAgICBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20gPG1haWx0bzptYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAgICAgcnRjd2ViIG1haWxpbmcgbGlzdA0KPiAgICAgcnRjd2ViQGlldGYub3JnIDxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCi0tIA0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrIEFyY2hpdGVjdHVyZSAmIFByb3RvY29scywgRXJp Y3Nzb24gUmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAg ICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBT d2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQo= --------------B5232B3BC5832FEDDD9D7625 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

I have looked at the changes in -11. I have some questions.

1. In table 29, section 5.3.2 regarding the H.264-SVC.

=C2=A0=C2=A0 | a=3Dfmtp:100 profile-level-=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | [RFC6190] H.264=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 | id=3D53001f;packetization-mode=3D0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Scalable Encoding=C2=A0=C2=A0 |

Why are you using packetization-mode=3D0? For SVC in SST, wouldn't= mode=3D1 be the most reasonable choice?=C2=A0 Not that it will not = work, but putting all the meta data NALUs into their own RTP packets seems unnecessary.

2. Table 30, same question as 1)

Otherwise the changes related to my review looks good.

Cheers

Magnus

On 2018-10-10 05:42, Suhas Nandakumar wrote:
Hello Magnus

=C2=A0Apologies that this took a while. Please see inline.
On Wed, Jul 4, 2018 at 7:57 AM Magnus Westerlund <magnus.westerlun= d@ericsson.com> wrote:
Hi,

I have reviewed Section 5.3 only with a focus on the simulcast and
multi-stream aspects. For example I have not cared if the ICE details
are correct in these examples.

Thanks for the review. I have submitted -11 version that should address the review comments.
=C2=A0

A. Section 5.3.1:

BUNDLE grouping framework enables multiplexing of all the 5 streams
=C2=A0=C2=A0=C2=A0 (1 audio stream + 4 video streams) over a = single RTP Session.

It might be good to use RFC 7656 terminology and be specific in that
this results in 5 source RTP streams.


[Suhas] Done
=C2=A0
B. Section 5.3.1.

As 5.3 says that this will use FEC or RTX and this one doesn't maybe be
explicit that it is not added, or rewrite 5.3.

[Suhas] Update the description to mean some examples have FEC/RTX and not all.
The idea was to have this section with examples that cover all these cases but=C2=A0
not to have all these in all the examples.=C2=A0

C. section 5.3.1:

=C2=A0=C2=A0=C2=A0 | a=3Dgroup:LS m0 m1=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5888]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

Is it intentional that video 2 is not included in the lip-synch group?
May require a intention comment for this case.

[Suhas] . The intention was to group one AV in a lip sync=C2=A0
group and other can be a non-interactive stream. Updated the text to=C2=A0
indicate the same.=C2=A0


D. 5.3.1:

=C2=A0=C2=A0=C2=A0 One video source corresponds to VP8 encodi= ng, while the other
=C2=A0=C2=A0=C2=A0 corresponds to H.264 encoding.

As the m=3D block represents a media source, if the need is t= o provide one
video camera's images (the media=C2=A0 source) as both VP8 an= d H.264 where
each are in two different resolutions, then simulcast can handle that
fine within a single m=3D block. So from my perspective this is a wrongly
constructed example from that premise. Can you please clarify if you
want two media source, i.e. two cameras, or two encoder formats VP8 and
H.264, or two resolutions, or any combination of them?

I would recommend this example to be two media sources, with encoding
simulcast. The resolution can be skipped as the later example includes
resolution simulcasting.


[Suhas]. Yes, the example wanted to showcase 2 different media sources (one encoded
=C2=A0as vp8 and another as h264, can be natively encoded = as well) and=C2=A0 each being sent at
=C2=A02 different resolutions.=C2=A0
=C2=A0
E. Section 5.3.1:

=C2=A0=C2=A0=C2=A0 | a=3Drtcp-fb:* nack=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5104]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

=C2=A0=C2=A0=C2=A0 | a=3Drtcp-fb:* nack pli=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5104]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

I would note that generalized NACK as well as picture loss indication
(PLI) is defined in RFC4585.

[Suhas] Done, updated all the references.
=C2=A0

F. Section 5.3.2:

=C2=A0=C2=A0=C2=A0 This section shows an SDP Offer/Answer for= a session with an audio
=C2=A0=C2=A0=C2=A0 and a single video source.=C2=A0 The video= source is encoded as layered
=C2=A0=C2=A0=C2=A0 coding at 3 different resolutions based on= [RFC5583].=C2=A0 The video
=C2=A0=C2=A0=C2=A0 m=3Dline shows 3 streams with last stream = (payload 100) dependent on
=C2=A0=C2=A0=C2=A0 streams with payload 96 and 97 for decodin= g.

Also here use of RFC 7656 terminology to talk about (source) RTP streams
when applicable would be good.

[Suhas] Updated.=C2=A0

G. Section 5.3.2:

=C2=A0=C2=A0 | a=3Drtpmap:96 H264/90000=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:96 profile-level-id=3D4d0028;=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6184]H.264=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | packetization-mode=3D1;max-fr=3D30;max-f= s=3D8040=C2=A0 | Layer 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:97 H264/90000=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:97 profile-level-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6184] H.264=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | id=3D4d0028;packetization-mode=3D1; max-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Layer 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | fr=3D15;max-fs=3D1200 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:100 H264-SVC/90000=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:100 profile-level-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | [RFC6184]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0 | id=3D4d0028;packetization-mode=3D1; max-= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | fr=3D30;max-fs=3D8040 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0 | a=3Ddepend:100 lay m1:96,97=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | [RFC5583]Layer 3=C2=A0=C2=A0=C2=A0 |

I have my doubts about this configuration. First of all as it is SVC in
Single RTP session mode (SST) I don't think it results in multiple RTP
streams. I think the answerer will interpret this, which of these
encodings can support. A non scalable H.264, another non-scalable H.264
or SVC that can contain a number of layers.

Secondly a=3Ddepend is only defined for MST mode in RFC 6190.=

You also have the wrong reference for the H-264-SVC a=3Drtpma= p and a=3Dfmtp
line.

[Suhas] Agreed Magnus. On re-reading the example it confused me as well :-)
Update the example to represent SST mode SVC configuration.
=C2=A0

H. Section 5.3.3:

=C2=A0=C2=A0=C2=A0 | a=3Dextmap:3 urn:ietf:params:rtp-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-avtext-ri |
=C2=A0=C2=A0=C2=A0 | hdrext:sdes:rtp-stream-id=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | d]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

After this line you should have also this line:

=C2=A0=C2=A0=C2=A0 | a=3Dextmap:4 urn:ietf:params:rtp-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-avtext-ri |
=C2=A0=C2=A0=C2=A0 | hdrext:sdes:repaired-rtp-stream-id=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
d]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

This to enable the RTX streams to indicate which source RTP stream they
are repairing. Add to both offer and answer.

[Suhas] Good catch. Added it.
=C2=A0

I. Section 5.3.3

Why isn't RTX enabled for the audio also?

[Suhas] No Specific reason. These are just examples to show configurations and thus picked MVP=C2=A0
configurations to show the usage of SDP for scenario at hand than describing all possible=C2=A0
options.


J. Section 5.3.3. Answer:

=C2=A0=C2=A0 | m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 101 103=C2= =A0 | BUNDLE accepted=C2=A0=C2=A0=C2=A0=C2=A0 |

Payload types 100 and 101 are undefined in this media description.

[Suhas] Thanks for catching this. Matched the answer with the offer now.
=C2=A0

K. Section 5.3.4 Answer:

=C2=A0=C2=A0=C2=A0 | a=3Drtpmap:101 VP8/90000=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC7741]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

Wrong media type for the payload should be RTX.

[Suhas] Nice find. Fixed it.=C2=A0=C2=A0

L. Section 5.3.4 Answer:

Missing rtcp-fb definitions to enable use of NACK which RTX depends on.


[Suhas] Agreed. Added it.
=C2=A0

M. Section 5.3.5:

=C2=A0=C2=A0| a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-payload-f |
=C2=A0=C2=A0=C2=A0 | window=3D200000=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | lexible-fec-scheme] |
=C2=A0=C2=A0=C2=A0 | a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; rep= air-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [I-D.ietf-payload-f |
=C2=A0=C2=A0=C2=A0 | window=3D200000=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | lexible-fec-scheme] |

As the parameters are the same, I don't see a point with having two
payload types. Two different RTP repair streams can use the same payload
type. As Flex-FEC can do all the binding using the CSRC field, there are
also no need to have the repaired-rtp-stream-id header extension for
this one.

[Suhas] Good point. Moved to just one PT. Also i think you intend to=C2=A0
include=C2=A0 repaired-rtp-stream-id for this example too = ?


N. Section 5.3.5:

Does it make sense to still have NACK for a session with FEC. If it
fails isn't PLI or FIR

[Suhas] Dont think its needed. Removed nack and kept pli=C2= =A0

Cheers

Magnus Westerlund

---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research
---------------------------------------------------------------------- Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| M= obile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlun= d@ericsson.com
----------------------------------------------------------------------
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--=20

Magnus Westerlund=20

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


--------------B5232B3BC5832FEDDD9D7625--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV
BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ
ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+
laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ
HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV
IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o
gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee
VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u
bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0
dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3
DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q
ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD
yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6
H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE
lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl
60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD
ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K
v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3
UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY
VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4
foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx
MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM
HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS
Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX
ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp
VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2
PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2
H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4
rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX
1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv
Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN
VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG
AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu
Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j
b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js
LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7
GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU
JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG
vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn
nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf
ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8
5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd
Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE
EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd
3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du
jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB
MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA
oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEwMTUx
NDQwMTVaMC8GCSqGSIb3DQEJBDEiBCBNSav7oN+Tgtpa29eK6e4u+qVwoi9xu26/rksR/cRG
9DBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz
b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62
a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAdPCg06uSQ3i4a1xeCnEAmSSWEERday8D8Q4j9XIW
A7rRVe3+uvsDyUTKSjLDQLZQnODs3aCfKzZ1r9+6SrEkkW70t3f1rfQItLuW9FLbrUWBNmTx
R9XcEEncTGB1fqHkrI2quwxlHy59bORKIUViaG8VWgvUHjUGxTIpS9+qwFxKxgPRvW/BCNpo
Wr+LVxPuc9FViZDrCNkITkqkJkpGfgUezx/qoezzJySetcQcdyKxx+Ha4RJVdn23DiKqmU0x
kHfVHI7l/S77uU32E29OWPmILuepmb6okbCKsu1rl5Rd1neLk4ydnk9mh75mjz9zjf0w3bM1
lQ5kgSvk1oPNqQAAAAAAAA==
--------------ms010506020008060602040705--


From nobody Mon Oct 15 10:31:09 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6DC130ED3 for ; Sat, 13 Oct 2018 02:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.755
X-Spam-Level: 
X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=IgY+nIJH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YOy4l/Xp
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 WyGBY-gbALaP for ; Sat, 13 Oct 2018 02:51:56 -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 5F4E3130ED7 for ; Sat, 13 Oct 2018 02:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539424310; x=1542016310; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lKlxjdC35O2VYGx9uMNra32Rtcl6p6vmUAkJcSzGSmI=; b=IgY+nIJHoDlVKZM0A0hke62pGc9/+3LosEex2xP4XXPQoOgtNxGZoRDI2vRoYSx6 9EcslwrYNkmmNMuJY39YsMsqDpPn1JIsXNDX2rAOik0Q5SDn8+v5W/3um8x+IUTb +DDzzW11t2oFmP5pgCcUMC4hZzP6oyprlaLcnNQGsoI=;
X-AuditID: c1b4fb2d-b37ff70000003a27-86-5bc1c036d5d5
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.03.14887.630C1CB5; Sat, 13 Oct 2018 11:51:50 +0200 (CEST)
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 11:51:50 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 13 Oct 2018 11:51:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lKlxjdC35O2VYGx9uMNra32Rtcl6p6vmUAkJcSzGSmI=; b=YOy4l/XpUDtRfjPZBzbLrHOdhscyra0SVIlMsPCjIjIU596bm+hPSQQZ2Vv3AZJDoCHXsMI9ycsV13bYiWK83UXIb3DcsE6Q68KUUA1Q45bwifgb6kdtbboQF7ygHYGmubBNR6BQSFZStq/G78tx5w+jk7nHriANORv6QxMKsec=
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB1248.eurprd07.prod.outlook.com (10.164.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.16; Sat, 13 Oct 2018 09:51:48 +0000
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.020; Sat, 13 Oct 2018 09:51:48 +0000
From: Christer Holmberg 
To: Sergio Garcia Murillo , Adam Roach 
CC: "mmusic@ietf.org" , "art@ietf.org" , "Heather Flanagan (RFC Series Editor)" , "clue@ietf.org" , "pthatcher=40google.com@dmarc.ietf.org" , "ice@ietf.org" , RTCWeb IETF , Justin Uberti 
Thread-Topic: [clue] [rtcweb] [MMUSIC] [Ice] [art]  ICE, ICE-bis, and Cluster 238
Thread-Index: AQHUYtZlrUrVsNmXpkqzWCK6GAjkWKUc7mmn
Date: Sat, 13 Oct 2018 09:51:48 +0000
Message-ID: 
References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com>    <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [91.150.32.117]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1248; 6:vq39JdaAxL+EJVzhq0/hmOtkTHCGspJPWBDJCB/KAHmlCjBGPPbC0aOrerGth3x4zi5d7bPQjrSJImp8vrgrh0/EMGbeZ9AK6kQGX2tnNgEQhdhQB0E3gYM4/EGACe65fmK9RFPePX8xSYbZrhdIT33BAlOky8FDFuU7IZAXlh49tZwjD+dZSY5EmXHPqnuHY5OB93igCaPDXHnw/13Cswi1KPqkOMCFxDLaVdJKzyKrhVFJowI9iYJObL+/6Z7V7CyLIa7Uzf43Muptf8y3QYzG0ljBDiaKYY1Ae/Uyo/BEqH4a5t70ZVZ0vVT9V76JuotQ3q7Vf+2dUcfkSzP3Zdd51xtgIEozFucvwzPTy8yAZE+hyBuwoC101X82EFqHEFq+KNAbt01MJqcHxKxnbf6KoHG7y0gW/TOHEjbGPydQH/+ios64fE+PGoD2ge+LwR3Pww0wsgYmTUYgbyIbSA==; 5:PjIa4vstPU2SliO66TXvzLwaG7Ceh3oNSCgTJ/mOXd1Je//9q4gyuUuXPkW9jj/iiXssEVijUdXpQSto9EXFswpzMi2YDLKufxFkKDJ3+q4H4QSmsZpNmJElVYxHTrLhpn2yZ6uXO74hZZ5dMiIfgZiARxkAyiGTP/bsCJ4gOR4=; 7:PUOs0Kv0iC3HkBDCo6f9uUS2UNq2TR4qOPdzyqMXYz/h6gQR/EWcEEH/O9gKs/m0HtbOKZ4ieVsz8l9czYZJIPZFjmVcOzOpSCVXhovQcIabSph0FsoXBE/iBVGsX7DZG0/gN9jRDrXJbSUzt6z8lRGqdSg+pAYrITsVOk5jkhRTY2IBLWarWgHhcq9CbOcfD8V/jz5X5I2d4TWTL8vHKLeOpCazV7mOTCGzNYnT3zZ726H82GEdao2sEJj8LveS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: dbceb871-a67b-430d-e774-08d630f17e46
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB1248; 
x-ms-traffictypediagnostic: VI1PR07MB1248:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR07MB1248; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1248; 
x-forefront-prvs: 082465FB26
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(366004)(189003)(199004)(7736002)(186003)(74316002)(53936002)(106356001)(476003)(33656002)(11346002)(26005)(19627405001)(446003)(606006)(54906003)(66066001)(25786009)(102836004)(2900100001)(44832011)(97736004)(4326008)(105586002)(110136005)(6606003)(486006)(256004)(71190400001)(1015004)(53546011)(7696005)(3846002)(6506007)(71200400001)(6246003)(76176011)(8936002)(229853002)(966005)(99286004)(6116002)(8676002)(81156014)(5250100002)(14444005)(14454004)(7416002)(6436002)(6306002)(39060400002)(2906002)(9686003)(93886005)(54896002)(5660300001)(86362001)(55016002)(236005)(68736007)(478600001)(316002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1248; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MrObq/Xnnrl/us2RhpOftIv2Xke/YyzS62IhrmCFQgo8TdiPEz/LooFmJkVU67P2YmW1GjZpht+fzhqoYFK+OH3qlNirnKlwX4GUIuVO85XztiHI5ezkPgAXuF2yfpQo+d9flyFRqtkT0I2u+xZPKZDO9aILXkdapkwNTEq7TMCVP0yfj3j+LKqwdje+LWY5JfQmloPhja5aU438Sbb75ZcNnsAdg9CcOfeUriZGKXsCfvYDg/DRtRkNY2XJEcgmriw5+J/h5yK7YKElphDOFS/nSI4hEEDwvJKk1qJLmV+F7B3Y/t+/+gooLn6N164+/4XQGBK4PLEBV/NZtDuI16+rLDC5rzpW7Px756xv084=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dbceb871-a67b-430d-e774-08d630f17e46
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2018 09:51:48.2390 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1248
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bOtuNq8Lm8vFiWLSNRtkxFDiJqUbSCMrMg1C4jType2THR wFDxkq6LlZMc1bSGhiVe8YK3XJnmH2lqkbfhZWpihARqIq6cZ4H//d7neb73+T74KEIyznei YhKSGVWCMk4qEJEll5tSZb7vusI9cxb30m0bL4X06wkF3dk3RNArA+l0trqbT2sqZkh6OPMm PTbnR1eZ84T0rLmJCBIpesuH+YoW7YRQodev8RTaFhOpyMj9yD/PDxP5RzJxMSmM6kjAdVF0 lnoQJbV6pZYsjRAZqMijANlQgH2gSveTKEAiSoK7EdRWzAm4YQVBZu4TwpKSYD0P1v+4WAwS FxKQn/WQ5FKPeaCdbeFxwzSCvLpnmw5FCTANavNWhx2OgL9D7VsZAv/mwfDI7Nba3fgCbEze E3KhUBipaCQ59gLjyvQWk/gQNE81EJad4s1F6tVQrmucAL2mWGDJ2OAQMI5/41sYYQdY7XvL szCBHWHUpONxD8Wgb+snOLaHhRmzNa+EzspJq34A+j4bSI6dYVCnRpYywB1CGPsxwOcMGSxp NNYDZ6G2Y81a0INgfimEY3foz6y36rEwWtVnXeoH+vfrQo73QeX9KbIQeWq33ZXjRHiQ2Yss LMa28KnERHK6HL5rigQce0B52SLBsQyemg3kdr0UCSuRPcuwbHyUl7ecUcXcYNnEBHkCk1yH Nv9cV8O6rBm9WTxmQJhC0l3inuqucAlfmcKmxRsQUITUTsx4bkriSGXabUaVeE11K45hDWgP RUodxfLKtjAJjlImM7EMk8So/rs8ysYpA3l/OXlw2dhkV9Mewcw7z9SURgXtXHafo9uzKeFS bM5dv3OGV6c7aqvXzMETA/E6Y8CJ1i7/K53zrm7dO359la0v+Oiumj64kD6u3U8b/fLLRs8U 6HxbesLu0LLi/fXB6PmAXemLS82TZvFF74ZHgYdPOdQEHU8P7DDaBqs73bJ9pCQbrTzqTqhY 5T/nrQlkbwMAAA==
Archived-At: 
X-Mailman-Approved-At: Mon, 15 Oct 2018 10:31:08 -0700
Subject: Re: [rtcweb] [clue]  [MMUSIC] [Ice] [art]  ICE, ICE-bis, and Cluster 238
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 13 Oct 2018 09:51:59 -0000

--_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


Personally I don't think updating of references and examples require a new =
IETF last call.


Do people foresee any changes to the technical JSEP procedures due to the r=
eference update?


Regards,


Christer


________________________________
From: clue  on behalf of Sergio Garcia Murillo 
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series Editor); cl=
ue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; RTCWeb =
IETF; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster=
 238

p0090

El lun., 1 oct. 2018 23:11, Adam Roach > escribi=F3:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8445
> than 5245, so I don't see any issues associated with snapping this
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just
> the addition of the 8445 reference and note; the examples will have to
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These
> changes will be modest but probably will need to be done by the authors.


If I read what you're saying correctly, it sounds like you're talking
about changes that are significant enough that we'll have to put JSEP
through IETF last call and through the IESG again. That being the case,
and the rest of the cluster being so close to done, I'd really prefer to
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

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

--_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi,







Personally I don't think updating=
 of references and examples require a new IETF last call.







Do people foresee any changes to =
the technical JSEP procedures due to the reference update? 







Regards,







Christer










From: clue <clue-bounces=
@ietf.org> on behalf of Sergio Garcia Murillo <sergio.garcia.murillo@=
gmail.com>

Sent: Saturday, October 13, 2018 12:22 PM

To: Adam Roach

Cc: mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series Edit=
or); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; =
RTCWeb IETF; Justin Uberti

Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and =
Cluster 238

 







p0090






El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=F3:





On 9/27/18 6:20 PM, Justin Uberti wrote:

> I agree with Peter. Chrome's implementation is already closer to 8445 =


> than 5245, so I don't see any issues associated with snapping this 
> cluster to 8445 (aside from the work involved).

>

> On that topic, note that JSEP will need a few more changes than just <=
br>
> the addition of the 8445 reference and note; the examples will have to=
 

> be updated, as will the logic regarding generation of offers and 

> answers and their parsing (to deal with the new ice-option). These 
> changes will be modest but probably will need to be done by the author=
s.





If I read what you're saying correctly, it sounds like you're talking 

about changes that are significant enough that we'll have to put JSEP 

through IETF last call and through the IESG again. That being the case, 
and the rest of the cluster being so close to done, I'd really prefer to 
see this done very soon, if such changes are required. When do you 

believe such an update could be available?



I've copied the RFC Series Editor on this note for her awareness.



/a



_______________________________________________

rtcweb mailing list

rtcweb@ietf.o=
rg

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














--_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_--


From nobody Thu Oct 18 03:30:16 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292D3130E4D for ; Thu, 18 Oct 2018 03:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.364
X-Spam-Level: 
X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SH3cQALK; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gUdcvLt+
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 wpfH2N5y7glD for ; Thu, 18 Oct 2018 03:30:11 -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 8B4C312D7F8 for ; Thu, 18 Oct 2018 03:30:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539858608; x=1542450608; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JEhz5ET7dSmSDQdOYTc8tRiLcc/aIHg22rNCz3pbXtA=; b=SH3cQALK5MlEyYoT2X/2pafB9fFs+q0ErzEFpW/kMuoezjGTgLjhbOEb791o3Sy2 0FqkLAbGmv3/oeXocHSfxOdscjpbPi48eO8Cg+a3kYSjkawdq+LcEGsZ9F7wUm4f 8nSoKHkVB7rWxh4ElKLeKfkcDW8+TLhzZJezfkF2w8I=;
X-AuditID: c1b4fb3a-159ff700000012ff-dd-5bc860b0f5e1
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.6C.04863.0B068CB5; Thu, 18 Oct 2018 12:30:08 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 18 Oct 2018 12:30:08 +0200
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 18 Oct 2018 12:30:08 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cgSH8TN0HPkaf6CukLWzKbcI/Iq6YBRaPBRavK5Kl5o=; b=gUdcvLt+UNzJpzOLjeK9u+JMLjsWTf77A5d2Jwef1I6wDF/wCH7j4ZkDFPt0sUqAxQPtlIqN2tJKW4eDBa/k5NFH1G44+igYAWDltmO86e2JugL6/eG4LyImo4N1IErCcT+Hy7skKH3E7+IbiQdkg1FcnjO0gkKnl3ZdpZgeXzc=
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB0928.eurprd07.prod.outlook.com (10.161.110.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Thu, 18 Oct 2018 10:30:07 +0000
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77%2]) with mapi id 15.20.1250.020; Thu, 18 Oct 2018 10:30:07 +0000
From: Christer Holmberg 
To: Cullen Jennings 
CC: RTCWeb IETF 
Thread-Topic: [rtcweb] A couple of questions on SDP Identity attribute
Thread-Index: AQHUYTNdgdx0fYUyP0+ZCWsqcc6KnaUah5WAgALqY2CAB2aBJg==
Date: Thu, 18 Oct 2018 10:30:06 +0000
Message-ID: 
References: , <8ECAF21E-F2C9-4FFF-9B19-39284A80F13E@iii.ca>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [2001:14bb:52:b252:75b4:c42f:7eb:8f4b]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB0928; 6:nXjhozHIq6wx4k9XAfJ7Y6wK47hlbGr2M0PBPurOaTxSAWqyEbe+zrCpavZvfaHEfAJfIX7nDC1DOSlgDhv76tgyOYQwn/Up757/Zw7UOdtYYm+a0xc+5gFzMZBPnc/zYbtBauhfd5zZ+YNAeGeTWfZnEU5YRizKvP0VSB3GH7h9MRaq8PIDr/TYpWoD+rwdLAzLeULlO38wvLzYTP1S3F8yRW56KhceoY54o0Lsz2qhVANDga9umo541x68Am83f1aONERaalSk0FgvBMhM75QYO1EEFwMhhBkprxOG3v8DKTFr6BhtsA+6/32+Oy7hBPR8aXuIOt3yiwM0gviZhHhUXD/xtWvdOg4M6yAj4EvZH03/Xqc+14k8Ror0dg/wP1KJiJ6IzxDEGf7DQO6n6OGoh5glR/3s3ubeq5bjpmg69hKq5xLqPhBvX6bzC/V+iLArPgu5XfNc/f4dxP+zmmSsUSt1HrcURYBGVuoO0CA=; 5:U0wIvttPAw6ZVKa4lhLwFkxpt0l+HWalqfvjvxlz3Bh8Umo4EaDBQ5HoUnzr8HX/op9ofkZoU5uRss7LgRwoTL0f7dEGu07tNPLO358rTmqE/9ATL+3mrDKFOA22tlGNK4wXm2IwKBbdwHjrlFGH6GDZRHU0FLN1BaVJK3aCEeM=; 7:2z3kwnfDxxfMo8lpTmHCQMVg/Y+Ztp/H3f8SbfNKaceCUr7oPDSZ4QzFyN7yjhveDAwbcbCg0ARoVVzHv/8Zpz0kHPSquMg6S0sFBaXOG5N+PhhK059h/9xP8AAWKz9Uv2U5T/AQarcTmRNvGxm3UoPP1eK641hP6l1/dV1nGf15tj0vDRPf8EKsTb60y8NmFOsr8n25O+X/luNv0yy4AgZZqxsyS1JFK2jw+gpsP6Q8OS/0GQvhZfHsMTTCfxDi
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b23a248c-6c87-412a-3cd5-08d634e4ac82
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB0928; 
x-ms-traffictypediagnostic: VI1PR07MB0928:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB0928; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0928; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(136003)(376002)(396003)(189003)(199004)(6436002)(316002)(71200400001)(229853002)(6506007)(106356001)(105586002)(71190400001)(53546011)(2906002)(99286004)(76176011)(7696005)(6916009)(5250100002)(6606003)(86362001)(256004)(4326008)(6116002)(25786009)(5660300001)(19627405001)(6246003)(102836004)(186003)(2900100001)(46003)(44832011)(74316002)(54896002)(7736002)(33656002)(446003)(55016002)(53936002)(9686003)(68736007)(11346002)(476003)(486006)(97736004)(81166006)(8676002)(478600001)(8936002)(14454004)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0928; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UzEnk/BDHdD5vM0atWyhpJBBZGiFYXpFnBfQoLV6qMFSrwdbkTdwVefpw7kH2xq+OB8ckfK+DmbnhZ4SfHIJCZXTAIObrMupShw8Jcl8yv7VdrpyhCbjEaYmcJWt/Fja9lwtYjA0Dl5fNzKJKj+n9DzHj0xGNWzHLA4JB6aixHy5CSQQgb2JFAViOXONd4IyBbkbTCCTllIe28bPlZmWg018SmQc7x6N8j3tv5QPBe45/ouGM7vSbvLczTWkO460TGXzlrJrfKNIIMuZhLpVtvbYfiSA+PK42PbdsNOSiI0KdFLgoOQzRE1p5lUg2mgElw1PW1l90MrS8gmLYQC+QGeYvE1IWFOp7oqfNaxCKmY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47820C658CCA5B34F34012FA93F80VI1PR07MB4782eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b23a248c-6c87-412a-3cd5-08d634e4ac82
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 10:30:07.0126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0928
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe++92+5Gq7elebAPahWEtqUSNsTUDEuIQAukNNOhN11+tjtF DZaDKJhpFrNyiMsQFVG0mGRSigPNWX7/Y2VoS8lQZIKfaTOvd4H//c7zPOc958BLk7I6gTet ydQx2kx1ulwoocqvvS1QNCf2xPmNNslVzqYVpGp0PRSFEZHV1atE5MjAPIoiYiXByUy6JpfR ngpJlKSuP14WZg+dyXMaF4lCZPI3IjEN+DTYF81CI5LQMtyFoGOjhOCLJQT1G+uIS8lwNQHd jiDOoHApCW3NU4hPmQgwF48J+MKBYOldlciIaFqIVVDk8uW6PfBR6G/9TnJM4iOwUGsRcrwX R4C5xI74zAUoXvgk5Fo9cDjUPpVxMoWPw6M1q4hjKb4B03Wr7u06ETi657beEeN4mG1aFHCM 8D5Y7m0g+Fle8HXSQvB3Yqh+P0Dy7Am/f7rceTV01E+4dRU0Gr4gng/CsKVo60jAwyIYf1Ih 4A0FOMvKSG5RwJehZjqPz3xEMGaZpviMD/SOmNycBl1ts+4Bl8BgsLv5ENQX/6BKkZ952648 Z8HQ/H3SvHX0HrCXT1K8roTRMpOQZ1+oqZoheVbAC5eN2q6/RKJ65MkyLJuREhCgZLSaJJbN ylRmMro3aPP/dFrXglpR569zNoRpJN8p9b/eEycTqHPZ/AwbApqUe0jvBm5K0mR1fgGjzUrQ 5qQzrA3tpym5lzT8lipWhlPUOiaNYbIZ7X+XoMXehej27ohgm1yzWHx+tfuDPk7q0KT1V87t EjjD+p51+V99MPFXf+eebozto2U320NeG8wNgivGQKN36Mmzz02H421xiQFTr07QUZXW0BF7 dOSOpIRBvTLcNCMWLy/3DyjCBmb1Xsl/VmLaJy5aK3KixxuIAxsFx3L7v8V8bkkfZFvkFJuq 9vchtaz6H7U04XE7AwAA
Archived-At: 
Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 18 Oct 2018 10:30:15 -0000

--_000_VI1PR07MB47820C658CCA5B34F34012FA93F80VI1PR07MB4782eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Any comments?


Regards,


Christer



________________________________
From: rtcweb  on behalf of Christer Holmberg 
Sent: Saturday, October 13, 2018 8:34 PM
To: Cullen Jennings
Cc: RTCWeb IETF
Subject: Re: [rtcweb] A couple of questions on SDP Identity attribute



Hi,

>> Q1: In an offer or answer, it allowed to include fingerprints that have
>> NOT been used to assert the identity?
>
>Yes, I think they should because fingerprints can be used even if Identity=
 is not.

In that case, I think the following text (Section 5.4.6.1.) is wrong:

   "The identity attribute attests to all "a=3Dfingerprint" attributes in
   the session description.  It is therefore a session-level attribute.

   Multiple "a=3Dfingerprint" values can be used to offer alternative
   certificates for a peer.  The "a=3Didentity" attribute MUST include all
   fingerprint values that are included in "a=3Dfingerprint" lines of the
   session description."

In my opinion it clearly states that every fingerprint attribute is associa=
ted with the identity attribute, and it is not allowed to include fingerpri=
nt attributes that are not associated with the identity attribute.

Regards,

Christer

--_000_VI1PR07MB47820C658CCA5B34F34012FA93F80VI1PR07MB4782eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















Any comments?







Regards,







Christer

















From: rtcweb <rtcweb-bou=
nces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@eric=
sson.com>

Sent: Saturday, October 13, 2018 8:34 PM

To: Cullen Jennings

Cc: RTCWeb IETF

Subject: Re: [rtcweb] A couple of questions on SDP Identity attribut=
e

 















Hi,










>> Q1: In an offer or answer=
, it allowed to include fingerprints that have 


>> NOT been used to assert t=
he identity?




>





>Yes, I think they should because fingerp=
rints can be used even if Identity is not. 















In that case, I think the following text (Section 5.4.6.1.) is wr=
ong:









   "The identity attribute attests to all "a=3D=
fingerprint" attributes in

   the session description.  It is therefore a session-l=
evel attribute.



   Multiple "a=3Dfingerprint" values can be used to off=
er alternative

   certificates for a peer.  The "a=3Didentity"=
 attribute MUST include all

   fingerprint values that are included in "a=3Dfingerprint&=
quot; lines of the

   session description."









In my opinion it clearly states that every fingerprint attribute is associa=
ted with the identity attribute, and it is not allowed to include fingerpri=
nt attributes that are not associated with the identity attribute.








Regards,









Christer


















--_000_VI1PR07MB47820C658CCA5B34F34012FA93F80VI1PR07MB4782eurp_--


From nobody Fri Oct 19 04:35:26 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93087130E7B for ; Fri, 19 Oct 2018 04:35:25 -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_MED=-2.3] 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 2jN80nSoRfOK for ; Fri, 19 Oct 2018 04:35:23 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB5712D7F8 for ; Fri, 19 Oct 2018 04:35:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 156467C0C4F for ; Fri, 19 Oct 2018 13:35:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBf6JlHWj8LC for ; Fri, 19 Oct 2018 13:35:19 +0200 (CEST)
Received: from [IPv6:2620:f:8000:210:13f2:d048:4384:5c7e] (unknown [IPv6:2620:f:8000:210:13f2:d048:4384:5c7e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 606F87C0940 for ; Fri, 19 Oct 2018 13:35:19 +0200 (CEST)
To: "rtcweb@ietf.org" 
From: Harald Alvestrand 
Openpgp: preference=signencrypt
Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk=
Message-ID: <3bd21949-542e-b1a9-f949-4fe5f89e22d1@alvestrand.no>
Date: Fri, 19 Oct 2018 13:35:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: [rtcweb] Proposed protocol change to JSEP: Omitting track ID
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 19 Oct 2018 11:35:26 -0000

I note that the editors of JSEP seem to have made the following change
to their draft:

https://github.com/rtcweb-wg/jsep/pull/850


It proposes removing the track ID from MSID signalling.

This is an incompatible protocol change, proposed after IESG approval of
the document. (I also happen to disagree with it.)

I'd like to have the WG declare consensus that we don't want
incompatible protocol changes to JSEP after IESG approval.
(If we want to discuss the proposed protocol change on its merits, we
can do that too, but I'm very much not in agreement with doing this
change in this way. Breaking changes belong in -bis documents, not in
the RFC Editor queue.)


Harald

-- 
Surveillance is pervasive. Go Dark.


From nobody Fri Oct 19 07:58:46 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7257130F8D for ; Fri, 19 Oct 2018 07:58:35 -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 g1dpW8j6FD5f for ; Fri, 19 Oct 2018 07:58:34 -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 85A8E130F61 for ; Fri, 19 Oct 2018 07:58:33 -0700 (PDT)
Received: from Svantevit.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 w9JEwOS3048538 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Oct 2018 09:58:25 -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 Svantevit.local
To: Harald Alvestrand , "rtcweb@ietf.org" 
References: <3bd21949-542e-b1a9-f949-4fe5f89e22d1@alvestrand.no>
From: Adam Roach 
Message-ID: <9c3f9d22-f1ef-6a7d-fc08-41440a97508e@nostrum.com>
Date: Fri, 19 Oct 2018 09:58:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <3bd21949-542e-b1a9-f949-4fe5f89e22d1@alvestrand.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Proposed protocol change to JSEP: Omitting track ID
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 19 Oct 2018 14:58:44 -0000

[as responsible AD]

On 10/19/18 6:35 AM, Harald Alvestrand wrote:
> I'd like to have the WG declare consensus that we don't want
> incompatible protocol changes to JSEP after IESG approval.
> (If we want to discuss the proposed protocol change on its merits, we
> can do that too, but I'm very much not in agreement with doing this
> change in this way. Breaking changes belong in -bis documents, not in
> the RFC Editor queue.)


Without speaking to the specific changes your cite, I'll note that the 
current plan is to take JSEP through IETF last call and IESG approval 
again. In fairness, this conclusion was easy to miss, as it was buried 
in a pretty long thread:

https://mailarchive.ietf.org/arch/msg/art/ycWd6evWxVjYCajxTbWynNvOIw4

/a


From nobody Fri Oct 19 12:02:35 2018
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 71C6F131124; Fri, 19 Oct 2018 11:56:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: adam@nostrum.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153997539745.6592.780659019504980864.idtracker@ietfa.amsl.com>
Date: Fri, 19 Oct 2018 11:56:37 -0700
Archived-At: 
Subject: [rtcweb] rtcweb - Requested session has been scheduled for IETF 103
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 19 Oct 2018 18:56:46 -0000

Dear Ted Hardie,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    rtcweb Session 1 (1:30 requested)
    Thursday, 8 November 2018, Afternoon Session II 1610-1810
    Room Name: Meeting 2 size: 150
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/103/sessions/rtcweb.ics

Request Information:


---------------------------------------------------------
Working Group Name: Real-Time Communication in WEB-browsers
Area Name: Applications and Real-Time Area
Session Requester: Ted Hardie

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 65
Conflicts to Avoid: 
 First Priority: dispatch doh dprive httpbis ice mmusic iasa2 quic saag secdispatch
 Second Priority: cbor mtgvenue tsvarea



People who must be present:
  Eric Rescorla
  Sean Turner
  Adam Roach
  Cullen Jennings
  Ted Hardie

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Mon Oct 22 10:28:38 2018
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 830F01252B7; Mon, 22 Oct 2018 10:28:30 -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.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: rtcweb@ietf.org
Message-ID: <154022931051.6882.7694911170290875654@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 10:28:30 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-mdns-ice-candidates-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 22 Oct 2018 17:28:31 -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           : Using Multicast DNS to protect privacy when exposing ICE candidates
        Authors         : Youenn Fablet
                          Jeroen de Borst
                          Justin Uberti
                          Qingsi Wang
	Filename        : draft-ietf-rtcweb-mdns-ice-candidates-01.txt
	Pages           : 11
	Date            : 2018-10-22

Abstract:
   WebRTC applications collect ICE candidates as part of the process of
   creating peer-to-peer connections.  To maximize the probability of a
   direct peer-to-peer connection, client private IP addresses are
   included in this candidate collection.  However, disclosure of these
   addresses has privacy implications.  This document describes a way to
   share local IP addresses with other clients while preserving client
   privacy.  This is achieved by obfuscating IP addresses with
   dynamically generated Multicast DNS (mDNS) [RFC6762] names.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-01
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-mdns-ice-candidates-01


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

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


From nobody Mon Oct 22 10:47:51 2018
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 9A4C7124BE5; Mon, 22 Oct 2018 10:47:49 -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.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: rtcweb@ietf.org
Message-ID: <154023046959.6878.3408886644758417167@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 10:47:49 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-16.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 22 Oct 2018 17:47:50 -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           : WebRTC Security Architecture
        Author          : Eric Rescorla
	Filename        : draft-ietf-rtcweb-security-arch-16.txt
	Pages           : 42
	Date            : 2018-10-22

Abstract:
   This document defines the security architecture for WebRTC, a
   protocol suite intended for use with real-time applications that can
   be deployed in browsers - "real time communication on the Web".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-16
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-16


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

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


From nobody Mon Oct 22 14:35:53 2018
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 C644C130F00; Mon, 22 Oct 2018 14:35:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Sean Turner 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: iesg-secretary@ietf.org, Sean Turner , rtcweb@ietf.org, sean@sn3rd.com, rtcweb-chairs@ietf.org
Message-ID: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 14:35:46 -0700
Archived-At: 
Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 22 Oct 2018 21:35:52 -0000

Sean Turner has requested publication of draft-ietf-rtcweb-security-arch-16 as Proposed Standard on behalf of the RTCWEB working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/


From nobody Mon Oct 22 14:37:34 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389B3128CB7 for ; Mon, 22 Oct 2018 14:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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] 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 etEMcU833yMD for ; Mon, 22 Oct 2018 14:37:31 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 57A23126BED for ; Mon, 22 Oct 2018 14:37:31 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id q40-v6so48261342qte.0 for ; Mon, 22 Oct 2018 14:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8C9YCoKTzKhgcI/98Owiq8gv18RRh+r4xya60XXEtwo=; b=SLSiFc1XjTBAIUV1EGUMJFgNX7j4WYFBra5i4NP2KclzYAl/IdJP4dqamSlhOpqkTl XjlFrAGtkB5N+myaE0m6MlsOdUjMBUrTtEgdeTgDs+GAMqe3ZONOoIftypLco/32Y68y gDZdmZ7Z9FXwiibhD7WVzELA/0wb1mxUGOlEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8C9YCoKTzKhgcI/98Owiq8gv18RRh+r4xya60XXEtwo=; b=OfahGV5Sd7+eTMBAEpXfO0jGXg170LGCBAUY7ve0PjJsXSbQ717MSGNXaj+0s5CdBk VBeUmd8dg8/uU8HJV9GnEZm+JhSGRTST8Ovg2G/+m13CFeEUnk1eYTV9y8vZhgUCV3BW Qy35YFjR1/Ee2jCW89VzcI1I6SIYWcFLCKpwDek0Vt+WMTA/j/nE/yMWSc2gtwh4Y4of is7ngUtWqFqSgNWNFHrv/C5os+ylalqN1R+jMUbAun84QyJVnxYDMIxuSyDS577ApErD 4+Vjrks+FIiZSgEXc8RrvFsTSV55q1NJqlrhlbDC9DQ9OwpJAkol4vxgd5Bekl3bdXyA qtuQ==
X-Gm-Message-State: ABuFfoijYv5P2Uzdr0fupTZhR1vYbxcAa0uILcTKp57JWIRecEDddOcH TfNR5fMfB1QZnYJWUhRj4cCjKQ==
X-Google-Smtp-Source: ACcGV611i6wSxo2aiSJHd3qXKOPiKqQAjjkTnRXMZ7EWD0m8ko1MqU3PUMIhX4U6rqSfVll8FFvZuw==
X-Received: by 2002:ac8:6754:: with SMTP id n20-v6mr45715581qtp.70.1540244250443;  Mon, 22 Oct 2018 14:37:30 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id w17-v6sm32534841qth.47.2018.10.22.14.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 14:37:29 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Sean Turner 
In-Reply-To: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 17:37:28 -0400
Cc: RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <796FD020-4F75-4273-B297-1CA78C43F3E6@sn3rd.com>
References: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 22 Oct 2018 21:37:33 -0000

Adam,

After the latest version was posted, I went ahead and requested =
publication.  Any other comments I believe we can deal with as part of =
the IETF LC process.  I.e., this draft ready for your review!

spt

> On Oct 22, 2018, at 17:35, Sean Turner  wrote:
>=20
> Sean Turner has requested publication of =
draft-ietf-rtcweb-security-arch-16 as Proposed Standard on behalf of the =
RTCWEB working group.
>=20
> Please verify the document's state at =
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
>=20


From nobody Mon Oct 22 15:26:50 2018
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 9C0D8128CB7; Mon, 22 Oct 2018 15:26:48 -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.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: rtcweb@ietf.org
Message-ID: <154024720859.13565.17489815349796433190@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 15:26:48 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-mdns-ice-candidates-02.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 22 Oct 2018 22:26:49 -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           : Using Multicast DNS to protect privacy when exposing ICE candidates
        Authors         : Youenn Fablet
                          Jeroen de Borst
                          Justin Uberti
                          Qingsi Wang
	Filename        : draft-ietf-rtcweb-mdns-ice-candidates-02.txt
	Pages           : 11
	Date            : 2018-10-22

Abstract:
   WebRTC applications collect ICE candidates as part of the process of
   creating peer-to-peer connections.  To maximize the probability of a
   direct peer-to-peer connection, client private IP addresses are
   included in this candidate collection.  However, disclosure of these
   addresses has privacy implications.  This document describes a way to
   share local IP addresses with other clients while preserving client
   privacy.  This is achieved by obfuscating IP addresses with
   dynamically generated Multicast DNS (mDNS) [RFC6762] names.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-mdns-ice-candidates-02


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

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


From nobody Mon Oct 22 15:35:47 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D21293FB for ; Mon, 22 Oct 2018 15:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 KL-VwHlLTqvB for ; Mon, 22 Oct 2018 15:35:44 -0700 (PDT)
Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 5FD29126BED for ; Mon, 22 Oct 2018 15:35:44 -0700 (PDT)
Received: by mail-it1-x12e.google.com with SMTP id l191-v6so13744150ita.4 for ; Mon, 22 Oct 2018 15:35:44 -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=ND3FHZPeBC7RON9afrOVssCU0qpODT6yftGs7GgR/Uk=; b=ak2bw+Y3lDjckjBeS37hSTJKz+WvylhjmYkKKWJSg6CtNtFtzKyLuSog2s68QNUY+2 rc+cHLUyfNaZkbKoyohButqq6yw8W42IsIkMDCve6931KMywBR8DXe2MSs429MTC0aBy 2XSX1XsIYyUBFUmyJ+nr7EqTBC6tycKLTV/f4DWh3OQwSPVdzDhE6Uut/Uq5ozDqehqn K1Iuc8BdzwQ+yiJvHYDCYAaP7Rqae7WRBFadRs+GxvE0agiT/G++YRvWWL8IEyJtgR6g dXxSLwch+UMs2jvdUgGdAqbZnEW6n7RhYztpRaZl2sjD7UkMpJQ/jgzfD8S4bxuMbTM6 IToA==
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=ND3FHZPeBC7RON9afrOVssCU0qpODT6yftGs7GgR/Uk=; b=UDVDjGSR9m0VZKJyJPaHeb9g/O9AuFuTkpHlSd07d3Iev8X/jRaU8ArbAGHeGLrVG4 OZVM3WqbZIjU5q3ba50JQVXmuaHeVOeAAAzI0bJmebELTBly6thZmQoKHBlDV/BNb70o Byobz3mYn5B1SHE9x0fp+Apxu8vSEoB/MdTa0hveX6lriR+8tytxWmTQhEvuawmKRH4I qnqXsVjcyDCLIR7fmbu3/XF/EYtMvR1LaNY3ZwCFKo1qgFXp9LhVwwVIeXw3Wkldn02m rM5aQ0pxnzb8DfYOWeOIHGUUhuzH1QMuCKVDyhoGAMjwy51dSVNNsxT9COXB9PpWwZIm Sj6w==
X-Gm-Message-State: ABuFfoja1Pem2cVbPuGBneAmGH5wgqf0YGX887C6Y1YXnSKzMt385RnC EDbxncJn3kV6e8nNdz3ZmPXrFE0GI/w/zmvwywem3CVqb9c=
X-Google-Smtp-Source: ACcGV60qVabqQxoLj5Qfa+z06DcYJI6h8Y3irvsxn7F6Lf14JU7m8D8O/w3W91wIKszcrnsR1pkTx8oHQr612GVFWA4=
X-Received: by 2002:a02:1b4f:: with SMTP id l76-v6mr33818341jad.57.1540247742928;  Mon, 22 Oct 2018 15:35:42 -0700 (PDT)
MIME-Version: 1.0
References: <154024720859.13565.17489815349796433190@ietfa.amsl.com>
In-Reply-To: <154024720859.13565.17489815349796433190@ietfa.amsl.com>
From: Justin Uberti 
Date: Mon, 22 Oct 2018 15:35:30 -0700
Message-ID: 
To: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="00000000000095cf5a0578d8df4d"
Archived-At: 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-mdns-ice-candidates-02.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 22 Oct 2018 22:35:46 -0000

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

This -02 release fixes a few lingering bugs in the -01. Overall, this is a
significant update from the -00 and should be read as a new I-D rather than
a diff.

On Mon, Oct 22, 2018 at 3:27 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Real-Time Communication in WEB-browsers
> WG of the IETF.
>
>         Title           : Using Multicast DNS to protect privacy when
> exposing ICE candidates
>         Authors         : Youenn Fablet
>                           Jeroen de Borst
>                           Justin Uberti
>                           Qingsi Wang
>         Filename        : draft-ietf-rtcweb-mdns-ice-candidates-02.txt
>         Pages           : 11
>         Date            : 2018-10-22
>
> Abstract:
>    WebRTC applications collect ICE candidates as part of the process of
>    creating peer-to-peer connections.  To maximize the probability of a
>    direct peer-to-peer connection, client private IP addresses are
>    included in this candidate collection.  However, disclosure of these
>    addresses has privacy implications.  This document describes a way to
>    share local IP addresses with other clients while preserving client
>    privacy.  This is achieved by obfuscating IP addresses with
>    dynamically generated Multicast DNS (mDNS) [RFC6762] names.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02
>
> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-mdns-ice-candidates-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


This -02 release fixes a few lingering bugs in the -01. Ov=
erall, this is a significant update from the -00 and should be read as a ne=
w I-D rather than a diff.

On Mon, Oct 22, 2018 at 3:27 PM <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Real-Time Communication in WEB-browsers WG=
 of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Using Multicast DNS to protect privacy when exposing ICE candidates

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Youe=
nn Fablet

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Jeroen de Borst

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Justin Uberti

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Qingsi Wang

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-rtcweb-mdns-ice-candidates-02.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 11

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2018-10-22



Abstract:

=C2=A0 =C2=A0WebRTC applications collect ICE candidates as part of the proc=
ess of

=C2=A0 =C2=A0creating peer-to-peer connections.=C2=A0 To maximize the proba=
bility of a

=C2=A0 =C2=A0direct peer-to-peer connection, client private IP addresses ar=
e

=C2=A0 =C2=A0included in this candidate collection.=C2=A0 However, disclosu=
re of these

=C2=A0 =C2=A0addresses has privacy implications.=C2=A0 This document descri=
bes a way to

=C2=A0 =C2=A0share local IP addresses with other clients while preserving c=
lient

=C2=A0 =C2=A0privacy.=C2=A0 This is achieved by obfuscating IP addresses wi=
th

=C2=A0 =C2=A0dynamically generated Multicast DNS (mDNS) [RFC6762] names.




The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/=
doc/draft-ietf-rtcweb-mdns-ice-candidates/



There are also htmlized versions available at:

https://tools.ietf.org/html/draf=
t-ietf-rtcweb-mdns-ice-candidates-02

https://datatracker.ie=
tf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-02



A diff from the previous version is available at:

https://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-rtcweb-mdns-ice-candidates-02





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

rtcweb mailing list

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




--00000000000095cf5a0578d8df4d--


From nobody Mon Oct 22 16:59:35 2018
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 5566D12DD85; Mon, 22 Oct 2018 16:59:27 -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.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: rtcweb@ietf.org
Message-ID: <154025276731.13660.6869474462005738841@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 16:59:27 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-25.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-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, 22 Oct 2018 23:59:28 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF.

        Title           : JavaScript Session Establishment Protocol
        Authors         : Justin Uberti
                          Cullen Jennings
                          Eric Rescorla
	Filename        : draft-ietf-rtcweb-jsep-25.txt
	Pages           : 115
	Date            : 2018-10-22

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-25
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-25

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-25


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

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


From nobody Mon Oct 22 17:06:59 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069312F1A6 for ; Mon, 22 Oct 2018 17:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zNilmZsDIVHz for ; Mon, 22 Oct 2018 17:06:54 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 54C541286E3 for ; Mon, 22 Oct 2018 17:06:54 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id d80-v6so7620835iof.1 for ; Mon, 22 Oct 2018 17:06:54 -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=mTrVaUbwKrAorHfXKESxKa2V5wlxagIvN18pF3e6o6Q=; b=poQB0RCRUUyhISGAW+lbjlCVh0C3Ub7q3Pzghq8+43sfbV3MX4/xJEo8UHzllp+SY6 5x52ZVl63qgJv2xwQ/3vUMGwce3bsgdxWKlYZyYd6KH9/IRBiRGHgFh60jA2V/PsNI9y D2WHVKx+7oyDkz/d+ZKG/qAaKxl7tRxpxEcxT7sGr3VaW72iI0iEupP4EP12WXhA5N3q sYsS++IovQoWzmkXeUj3YT7Vx8TtQPYh+ze/nYb5vyIAFRtt2R6VlPzMuarW8TTY5xFV 2xOkXE+zMB5Gh/Mxb6rZDInODtpdf2Dlw2Im5j6V7TBPUQ7dttVoP70KXXjV/nPo9Pst ujsA==
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=mTrVaUbwKrAorHfXKESxKa2V5wlxagIvN18pF3e6o6Q=; b=exDKYE3M6zZpe6Um6Xbf4ArnXiRbHNweQ6rSD46cnEIFXacSpk4+pKGWqt0g56EthF hNLzFrqUSJp8VmcIHhEPDKkWM+XMVMWSat84JyQ1qJ/t6woy63JSzrIwBcD3bFSgfi41 Z4u/uIV0yNrEjOrIS+RYFDGzi/md1emnl7PAnhOscaZbGIRiyu4JtZdMhELAAi3tY/1N BfTM4TslxlVhorHYWiXjmqgfskZ/PiyoICBJupHck8WjDNIMnYMjA56+zoQpEjVX7bct 8m0dOzxHqvqXDFVnVskxoANmP6sagkeWhefcqh2WP2xzS6xrIY3Ul3QqDvI6//QajWux BObA==
X-Gm-Message-State: AGRZ1gKALHTDoR3sGvWtfbwG/pFTecLjaKf3ZPxZrE7yFIki8GDBiJJw sBRhU2kcaCzKPrtyhf/hg0o3C4dnuq5e0cyQh6X9Ec9PiAZPwA==
X-Google-Smtp-Source: AJdET5cLJiTv0xojI1dVS7WDRYkdsTcG+/CknO5B4TTAYQ4MYHmAfN1FyVAYx37iPyaGEDe0BH2tAdmOOMoW8dlNTDQ=
X-Received: by 2002:a5e:9802:: with SMTP id s2-v6mr10031692ioj.87.1540253212888;  Mon, 22 Oct 2018 17:06:52 -0700 (PDT)
MIME-Version: 1.0
References: <154025276731.13660.6869474462005738841@ietfa.amsl.com>
In-Reply-To: <154025276731.13660.6869474462005738841@ietfa.amsl.com>
From: Justin Uberti 
Date: Mon, 22 Oct 2018 17:06:41 -0700
Message-ID: 
To: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="0000000000009eef260578da25d6"
Archived-At: 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-25.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 23 Oct 2018 00:06:57 -0000

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

   Changes in draft-25:
     o  Remove MSID track ID from offers and answers
.
     o  Add note about rejecting all m= sections in a BUNDLE group
.
     o  Update ICE references to RFC 8445 and mention ice2
.

On Mon, Oct 22, 2018 at 5:00 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Real-Time Communication in WEB-browsers
> WG of the IETF.
>
>         Title           : JavaScript Session Establishment Protocol
>         Authors         : Justin Uberti
>                           Cullen Jennings
>                           Eric Rescorla
>         Filename        : draft-ietf-rtcweb-jsep-25.txt
>         Pages           : 115
>         Date            : 2018-10-22
>
> 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-25
> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-25
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-25
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


=C2=A0 =C2=A0Changes in draft-25:		
=C2=A0	=C2=A0 =C2=A0o=
=C2=A0 Remove MSID=
 track ID from offers and answers.
On Mon, Oct 22, 2018 at 5:00 =
PM <internet-drafts@ietf.org=
> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Real-Time Communication in WEB-browsers WG=
 of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 JavaScript Session Establishment Protocol

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just=
in Uberti

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Cullen Jennings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Eric Rescorla

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-rtcweb-jsep-25.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 115

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2018-10-22



Abstract:

=C2=A0 =C2=A0This document describes the mechanisms for allowing a JavaScri=
pt

=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses=
sion

=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, =
and

=C2=A0 =C2=A0discusses 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-j=
sep-25

https://datatracker.ietf.org/doc/html=
/draft-ietf-rtcweb-jsep-25



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-rtcweb-jsep-25





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

rtcweb mailing list

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




--0000000000009eef260578da25d6--


From nobody Mon Oct 22 17:49:13 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DB3130DD2 for ; Mon, 22 Oct 2018 17:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zCqtPDPDcDvu for ; Mon, 22 Oct 2018 17:49:08 -0700 (PDT)
Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 82CE5130DDA for ; Mon, 22 Oct 2018 17:49:08 -0700 (PDT)
Received: by mail-it1-x129.google.com with SMTP id 74-v6so14052657itw.1 for ; Mon, 22 Oct 2018 17:49:08 -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=LB0FvfTLNi/luOnhezZgvAX5qLl9ZR5cEpc9ZKcodg4=; b=bBldCW4CBywac3+BTu9P16gCsNLsp/upojUfUCkkCb95yQwFSVRZHtS7w+9EVTvhEc tJo2JHvfY4AjDd6DSJDSZw/EYz8kjA1L4Fc9kKiVt9jL8aO8C6vPDUZoCOJFVY8koUXd zicfhvtE9PUbpWRaS33sy5ZU4XJQ1SYaKQDPX3YiiE2Di92moGgdFfh+7H9mmgME8B2q /dkUwNXJX5BwWGxQoFiEnYnXfgO8TdGYnBIzl8TGwyUA5J/5OaST1elHi9TpZ0w/I+Ix g5ho005wfh8dbnisOuI22dhJo5LioDEXBk3rC4K8tWCYdmkT6JF0rd+01i2JYJCtjHjl T4cg==
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=LB0FvfTLNi/luOnhezZgvAX5qLl9ZR5cEpc9ZKcodg4=; b=uMIZbyRu+28oisfhJmkrtyjAzUvDccLipqUasrBJvwF4Iyo5TDGFzP6QUgDPUgLRmu WdsqnfDUfa3ZsVc25cetk92oEMAlZjDvWvw1rMrLz5wzDPCYaTopT2/XYBXfR+3Rtpo7 e+GbZMWHYrQNTeuAz64eUCf1y8Mr/6BVowm7w6USam6CHYuK6cJZicE3PJzaNyW2bozO Kd6ftzoQOuDOsR3D1n+7gty/o+QYzGY7Hnz3C+Jx0obT1jMP0l3jKhT6RweEoFwyinv8 0bC/Yv0DBfhz772J68zuRQqvCiK6Gf6VH5Hgnh7k/p5CxXamsZC6X2Mu8YiKWU1+z+Eg zP1g==
X-Gm-Message-State: AGRZ1gJR0LJSl5bp8bi1A6WoSLyb5OBI/Vexk6/fEBd6pfo791vfCzX2 LlHasUqgcQnNNK9qHVwHQN5Fl6KvcIhwkh3NDlqVsZHnjYqZYA==
X-Google-Smtp-Source: AJdET5fe5dbGE7GhcqcjehiBTsozn+0+t1+ITyCB73cQyh+MlPcWNfhxnehO/hO2vct8JhD+h9G8ZQ85PAIz5IVMRSU=
X-Received: by 2002:a24:80d6:: with SMTP id g205-v6mr638134itd.76.1540255747093;  Mon, 22 Oct 2018 17:49:07 -0700 (PDT)
MIME-Version: 1.0
References: <154025276731.13660.6869474462005738841@ietfa.amsl.com> 
In-Reply-To: 
From: Justin Uberti 
Date: Mon, 22 Oct 2018 17:48:55 -0700
Message-ID: 
To: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="000000000000ab94970578dabcf8"
Archived-At: 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-25.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 23 Oct 2018 00:49:12 -0000

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

Additional context on the MSID change, for those wondering about the
rationale:
- w3c mailing list discussion

- w3c interim 
- mmusic mailing list discussion



On Mon, Oct 22, 2018 at 5:06 PM Justin Uberti  wrote:

>    Changes in draft-25:
>      o  Remove MSID track ID from offers and answers
> .
>      o  Add note about rejecting all m= sections in a BUNDLE group
> .
>      o  Update ICE references to RFC 8445 and mention ice2
> .
>
> On Mon, Oct 22, 2018 at 5:00 PM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Real-Time Communication in WEB-browsers
>> WG of the IETF.
>>
>>         Title           : JavaScript Session Establishment Protocol
>>         Authors         : Justin Uberti
>>                           Cullen Jennings
>>                           Eric Rescorla
>>         Filename        : draft-ietf-rtcweb-jsep-25.txt
>>         Pages           : 115
>>         Date            : 2018-10-22
>>
>> 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-25
>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-25
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-25
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>

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


Additional context on the MSID change, for those wondering=
 about the rationale:- w3c inte=
rim

On=
 Mon, Oct 22, 2018 at 5:06 PM Justin Uberti <juberti@google.com> wrote:

On Mon, Oct 22,=
 2018 at 5:00 PM <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Real-Time Communication in WEB-browsers WG=
 of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 JavaScript Session Establishment Protocol

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just=
in Uberti

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Cullen Jennings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Eric Rescorla

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-rtcweb-jsep-25.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 115

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2018-10-22



Abstract:

=C2=A0 =C2=A0This document describes the mechanisms for allowing a JavaScri=
pt

=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses=
sion

=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, =
and

=C2=A0 =C2=A0discusses 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-j=
sep-25

https://datatracker.ietf.org/doc/html=
/draft-ietf-rtcweb-jsep-25



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-rtcweb-jsep-25





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

rtcweb mailing list

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






--000000000000ab94970578dabcf8--


From nobody Mon Oct 22 22:30:30 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D91130E89 for ; Mon, 22 Oct 2018 22:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level: 
X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=V02nQkXB; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ADm1hCGn
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 BStvwlQ6gw9N for ; Mon, 22 Oct 2018 22:30:25 -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 4FAF9130DF0 for ; Mon, 22 Oct 2018 22:30:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1540272622; x=1542864622; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zivNgrtLLGBebDIlqlCk3uYQVjxXEe6aEbZX+X/wXRk=; b=V02nQkXBUwbRYAaCLF+120tF+QbKEMAeNMLVYU5LohXOHzF4hCbz4qSOli14/XZB avQ4BEHmRvniHyCx/t4D87q/PAi9r/oQph/6c0atbxy+BwkcnpfphrnD31KC4ahi gqUoc4+9MF3O9jwCBOWS7KT7oSAIDA/wWAJZZqaCu3A=;
X-AuditID: c1b4fb3a-171ff700000012ff-48-5bceb1eee51b
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.3A.04863.EE1BECB5; Tue, 23 Oct 2018 07:30:22 +0200 (CEST)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 07:30:22 +0200
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 07:30:22 +0200
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 23 Oct 2018 07:30:21 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CnWt6SvYo+xv83j4n9rNcTFikLIxkJ9e2jzZCMQ30a0=; b=ADm1hCGn/aRtIkyy8lZu55vqGXblUcXkLmFTvfwMe8gL8OSObcyG+XZiuChJnp2KEul2RRlaBD/FikM6Im88VYyMDnZk5g0hIS5T1mYe8QW3OPqzOT6nUVKjinEjyxt+Xu4NZQSELJlqrlhkGuVEA5tuBtEajfvNWCBb5Rz7Cnw=
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB4816.eurprd07.prod.outlook.com (20.178.8.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.5; Tue, 23 Oct 2018 05:30:21 +0000
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77%2]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 05:30:21 +0000
From: Christer Holmberg 
To: Sean Turner , Adam Roach 
CC: RTCWeb IETF , "rtcweb-chairs@ietf.org" 
Thread-Topic: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
Thread-Index: AQHUak9dBxagUAlzrE2U0l+OMU86FaUryj0AgACDrJc=
Date: Tue, 23 Oct 2018 05:30:20 +0000
Message-ID: 
References: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com>,  <796FD020-4F75-4273-B297-1CA78C43F3E6@sn3rd.com>
In-Reply-To: <796FD020-4F75-4273-B297-1CA78C43F3E6@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:708:150:10::19dd]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4816; 6:rivy+rd+hKjh+PnjR/AaAyMGRn4IrZoHGvaGLg46v2Tn9yzmtIWDJkaqz+pjbO0JtNAWpJkFFS43aExJts+3iK5T5xnSrPOscgPN489zkJnaqAIfqZil9aF7KxiD+nTExuMdI1gwJUxHAW+ysphGIe/RWipu9OG7u4L6asP5DIratNGiB6bnQ3x3pJINq1qx8W8AvFMfKFlkwPGXQ1Jws5wlac2fRjEmnKyH55yptJ/BecsCmTPmYGJc3nyEI45mhysFArPnM7nnFT5rjSN24b9Nh4vherMRIjYwhpeTf9M/sIi4qEPt+vtEPfnlMYzsco84T7gtjizILn8prDZrxqQ0jtBRPvVww6Com1RXHkYW+jJM0wxygcxXDpuTMGv2KkXJEYUncflMAHI2x/jBgqmbSQnEczsJtWJR74NCSb6SXmBGziVxPnm8BHAT3xJRW/82kARn5M3zp7KO0XJZNA==; 5:9lpbfI4mHN7w5K2akSdCKgswNSeew4UltGo7A84wDFhc+qsnmd6O7/F5//W4o+5L+eYNDTuoXJji/Fzcnfrs4fHZ+hRr1QV/1jsUIBj5eVI8qV95lvM/jHnf5jotfrgdWap871oY1BKcsIzhxZZZBTmooQn42BhXoD7plNpoRgk=; 7:praCdDn09qbQhtrHd8hFZo7F4vL0ilADbFz/0UAXtvbpO68dMTb8KRP7BBk+TOa2u1RZpcCwymY3C87HzRI2oSWTNXGUfiam2qb/xJE7a4oWvZLYk5IHBgU5gY0ESjIbD3JMgXH0x09gRKONu8r/NQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 03e5d61d-4288-4be0-3d8b-08d638a8a018
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4816; 
x-ms-traffictypediagnostic: VI1PR07MB4816:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(278428928389397); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4816; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4816; 
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(136003)(346002)(366004)(189003)(199004)(76176011)(7696005)(99286004)(5250100002)(6606003)(54906003)(110136005)(6116002)(19627405001)(7736002)(186003)(236005)(446003)(86362001)(53546011)(71200400001)(476003)(9686003)(54896002)(71190400001)(6306002)(55016002)(14454004)(106356001)(11346002)(53936002)(33656002)(46003)(105586002)(229853002)(478600001)(4326008)(5660300001)(606006)(6436002)(97736004)(2906002)(102836004)(6506007)(486006)(966005)(74316002)(14444005)(68736007)(8676002)(316002)(256004)(2900100001)(25786009)(44832011)(81166006)(8936002)(15650500001)(6246003)(1015004)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4816; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: TRDA+DJsxuMJGuN9Ixvp5dTZ1GUJQ6UilsohBmjW1eusMKv13VH1nlxaKpSIKZKl+Tv9gXjKU3zklC7JfvKv4GpliMNC72N3FvdgCEVFgKbsIGEPHHVuC/OVKA0rH7wrQfB5VRpCxRj3/pG/qn6zWXMwu6ZzHQ0tjC/HeJOnjLEfZ1V9IOWRErkTqUil7CJE/Y4T0dUVBtEa7GPPEwiT5c0B6K+bs/dghLTjH8u6QgR0r36v5mwJ/ZO+IcQuQx9rvaC4ukIUvnQXHwGuNh791Af5Yd5zxzRkEFFnu50/Qc4layRbKl3StyH3WxISYAGvcQH3xx5/5gCgjlR9EnqkcEqhLJKsQiqejfwwNYmNiZw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB478239EFEE526AB19F4F355793F50VI1PR07MB4782eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 03e5d61d-4288-4be0-3d8b-08d638a8a018
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 05:30:20.9897 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4816
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe/a+296tBo/zdrKMGPkhRUuzGmZX8RIV+SHEvDby9YJzyt5l aheUEtGJGSSpkJotTVNJsUwxYoMRGl6bYSoVOiwb6kJwXnLm9q7w2+//P+f/nHPgoQjxG64H laZQ0UqFTC7hCcmq6K5bvgvtg7GHjc37pL0b9Xxp6fw4KW21FvGlhuYC4gwZodGsciKqu41k hFaLIokYYXASLU/LppWHTl0TpppfjHGzGoNzeg10PloNLEECCnAgNMz0oBIkpMRYj0A/VESw YhnBp0UT77+oL88nWaHhwDdLiV2QuJyAkS9jjgfKOaAe2nRkphH0Fv7cqlAUD0tBbfWxTXTB p6GubIZjYwJHweTkV8LGzjge1p6MEmxPAjTet/BsURccBK8W99tsEntBy6aZa2MRjoPX+gn7 M2J8F6zzA/aoAJ8EXVuxnRF2A0t/i2OUO0wYazns0Rg0vUMEy64wN2PlsnwQDH/6EMueMFqr tt8F+DMPXo78dgR8wVxR4eBLUGlq4rNNHxCMdXTybUsD9obBdyHsEjJ43/zd0Z8Ov5osjmHx oC+8h8qRf/W2/VjOhNJFA1ltv9MJ+qqMJOv7wXjFIx7LPtDw1ESw7AuVVh253a9D/GbkytAM k5ESEOBHK9OuM0ymwk9BqzrQ1m/Sdq4HvUXaH2d1CFNIsku0s3EwVsyVZTO5GToEFCFxEZ1o 27JESbLcPFqZmai8IacZHdpDkRJ30blkaYwYp8hUdDpNZ9HKf1UOJfDIRyj5WJTXhQRDqMg3 RwvPrdwpz1o3VfuRsNhnreG7uyIf50W3zT6cUsfXDQcIHkgL1H2bipsDV9wumlXC9R0qWUCN YansaqKT4fYSddzYvxGUv3R5b5Z85UD33J2Ej20DobNhaYLinoWQcPc45ujyWrHcNKZyTqlZ Smqddhk+vyIhmVSZvzehZGR/AVcPDOdJAwAA
Archived-At: 
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 23 Oct 2018 05:30:28 -0000

--_000_VI1PR07MB478239EFEE526AB19F4F355793F50VI1PR07MB4782eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


Note Cullen's comment that it should be possible to include fingerprint att=
ributes in offers/answers that are not associated with the identity asserti=
on. The draft does not allow that, so I think it would be good if Cullen co=
uld indicate whether he is ok with that.


Regards,


Christer


________________________________
From: rtcweb  on behalf of Sean Turner 
Sent: Tuesday, October 23, 2018 12:37 AM
To: Adam Roach
Cc: RTCWeb IETF; rtcweb-chairs@ietf.org
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-=
security-arch-16

Adam,

After the latest version was posted, I went ahead and requested publication=
.  Any other comments I believe we can deal with as part of the IETF LC pro=
cess.  I.e., this draft ready for your review!

spt

> On Oct 22, 2018, at 17:35, Sean Turner  wrote:
>
> Sean Turner has requested publication of draft-ietf-rtcweb-security-arch-=
16 as Proposed Standard on behalf of the RTCWEB working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/dr=
aft-ietf-rtcweb-security-arch/
draft-ietf-rtcweb-security-arch-15 - WebRTC Security ...
datatracker.ietf.org
RTCWEB E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Tra=
ck July 17, 2018 Expires: January 18, 2019 WebRTC Security Architecture dra=
ft-ietf-rtcweb-security-arch-15 Abstract This document defines the security=
 architecture for WebRTC, a protocol suite intended for use with real-time =
applications that can be deployed in browsers - "real time communication on=
 the Web".



>

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

--_000_VI1PR07MB478239EFEE526AB19F4F355793F50VI1PR07MB4782eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi,







Note Cullen's comment that it sho=
uld be possible to include fingerprint attributes in offers/answers that ar=
e not associated with the identity assertion. The draft does not allow that=
, so I think it would be good if Cullen
 could indicate whether he is ok with that.







Regards,







Christer










From: rtcweb <rtcweb-bou=
nces@ietf.org> on behalf of Sean Turner <sean@sn3rd.com>

Sent: Tuesday, October 23, 2018 12:37 AM

To: Adam Roach

Cc: RTCWeb IETF; rtcweb-chairs@ietf.org

Subject: Re: [rtcweb] Publication has been requested for draft-ietf-=
rtcweb-security-arch-16

 






Adam,



After the latest version was posted, I went ahead and requested publication=
.  Any other comments I believe we can deal with as part of the IETF L=
C process.  I.e., this draft ready for your review!



spt



> On Oct 22, 2018, at 17:35, Sean Turner <sean@sn3rd.com> wrote:
> 

> Sean Turner has requested publication of draft-ietf-rtcweb-security-ar=
ch-16 as Proposed Standard on behalf of the RTCWEB working group.

> 

> Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/













datatracker.ietf.org



RTCWEB E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Tra=
ck July 17, 2018 Expires: January 18, 2019 WebRTC Security Architecture dra=
ft-ietf-rtcweb-security-arch-15 Abstract This document defines the security=
 architecture for WebRTC, a protocol
 suite intended for use with real-time applications that can be deployed in=
 browsers - "real time communication on the Web".













> 



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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












--_000_VI1PR07MB478239EFEE526AB19F4F355793F50VI1PR07MB4782eurp_--


From nobody Fri Oct 26 06:14:42 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3928F130DDF for ; Fri, 26 Oct 2018 06:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 4lkXRqYk-8db for ; Fri, 26 Oct 2018 06:14:39 -0700 (PDT)
Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com [173.203.187.72]) (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 D1F0A1286E3 for ; Fri, 26 Oct 2018 06:14:38 -0700 (PDT)
Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C6F2B57D0; Fri, 26 Oct 2018 09:14:37 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1E3435A74;  Fri, 26 Oct 2018 09:14:37 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 26 Oct 2018 09:14:37 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_C87D61A5-7A69-46AF-919B-9940E9FBB0DC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings 
In-Reply-To: 
Date: Fri, 26 Oct 2018 07:14:35 -0600
Cc: Sean Turner , Adam Roach , RTCWeb IETF , "rtcweb-chairs@ietf.org" 
Message-Id: <92608CCA-A368-4604-B29C-D16D0E0EDD98@iii.ca>
References: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com> <796FD020-4F75-4273-B297-1CA78C43F3E6@sn3rd.com> 
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 26 Oct 2018 13:14:40 -0000

--Apple-Mail=_C87D61A5-7A69-46AF-919B-9940E9FBB0DC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Oct 22, 2018, at 11:30 PM, Christer Holmberg =
 wrote:
>=20
> Hi,
>=20
> Note Cullen's comment that it should be possible to include =
fingerprint attributes in offers/answers that are not associated with =
the identity assertion. The draft does not allow that, so I think it =
would be good if Cullen could indicate whether he is ok with that.
>=20
> Regards,
>=20
> Christer


Yes, I=E2=80=99m fine with that.=20



--Apple-Mail=_C87D61A5-7A69-46AF-919B-9940E9FBB0DC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Oct 22, 2018, at 11:30 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

Note Cullen's comment that it should =
be possible to include fingerprint attributes in offers/answers that are =
not associated with the identity assertion. The draft does not allow =
that, so I think it would be good if Cullen could indicate whether he is =
ok with that.

Regards,

Christer


Yes, I=E2=80=99m fine =
with that. 


=

--Apple-Mail=_C87D61A5-7A69-46AF-919B-9940E9FBB0DC--


From nobody Fri Oct 26 09:55:34 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F84130E0C for ; Fri, 26 Oct 2018 09:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level: 
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=B45tl8HQ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lojjLflU
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 GVOOFZ0Ajeqg for ; Fri, 26 Oct 2018 09:55:31 -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 8355F130DE9 for ; Fri, 26 Oct 2018 09:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1540572928; x=1543164928; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LilF1B0x3WqXFcV/5Tgku+eH5F+g7iL3wfA6Fm9/Bxk=; b=B45tl8HQcKyx9QSrwxeqTBGPqtOsVluYm3sRvRQDVuysLDyO7mNpWz3ZSGrDRW0H /M/PHm8P+jGIpoxZMRxETYxHEvUB7pcqRbbRAZOSyisRO2ZyagGPNxsFySFPYD7a Oz+z2FUKZXS6Pi2MIbi1ImQf/1hobX10b1uBJ17vuXU=;
X-AuditID: c1b4fb3a-e3fcf9e0000063b1-0f-5bd34700aa72
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.99.25521.00743DB5; Fri, 26 Oct 2018 18:55:28 +0200 (CEST)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 26 Oct 2018 18:55:27 +0200
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 26 Oct 2018 18:55:26 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LilF1B0x3WqXFcV/5Tgku+eH5F+g7iL3wfA6Fm9/Bxk=; b=lojjLflUOdKzOnPPfavb0mqiPduvalYULbqR84sCab2anb2lGh0E3/ZR15JuPOPjP4a4sf/TxCkq4OEym/qP7Wzroulnzed616gIJmEP1ym+5cS7Vy8WF0Zl4psbRQ0CXGi1UBh3g7WXLx9xWoMcqwby3cwtKKLtu29SzhRYgQM=
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB4560.eurprd07.prod.outlook.com (20.177.56.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.7; Fri, 26 Oct 2018 16:55:23 +0000
Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::c85a:ac8f:54d8:1a77%2]) with mapi id 15.20.1273.025; Fri, 26 Oct 2018 16:55:23 +0000
From: Christer Holmberg 
To: Cullen Jennings 
CC: Sean Turner , Adam Roach , RTCWeb IETF , "rtcweb-chairs@ietf.org" 
Thread-Topic: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
Thread-Index: AQHUak9dBxagUAlzrE2U0l+OMU86FaUryj0AgACDrJeABTkmgIAAPYFT
Date: Fri, 26 Oct 2018 16:55:22 +0000
Message-ID: 
References: <154024414673.13439.6348944924030733376.idtracker@ietfa.amsl.com> <796FD020-4F75-4273-B297-1CA78C43F3E6@sn3rd.com> , <92608CCA-A368-4604-B29C-D16D0E0EDD98@iii.ca>
In-Reply-To: <92608CCA-A368-4604-B29C-D16D0E0EDD98@iii.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [37.136.22.227]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4560; 6:R83jJyBtFrOKGt7SN/VhZISwLN8CnpWHXXu2OdRsbbeOeVXVhT9j/NNpXIwyxCZLC2Ta2KZUuxlh7lxzle8thNw1khla0W0ElEH0GRTw792cnUKANn1ma2CcZberdSZMD68AmzLYCRkDnzw6Yp895XCfD1CVXaIlTYHVwqQJyu/kO8c6xozLjRicBgSBimB84a6VVDemW0BBcw2uGUJzopdMYZNtaLwmwYM/OcyTZB0zw6qJDhhTvwwGTmoh7bWVdh1c8mI5eZfgvPgL9TyQI4jRPj4hpe7TwOpJ54h0MpjCyHsw0vk4CD8WoDyEMIOfHtYwKBqOWny5b0FVH7Reu/2zLX95I3r8ycDXYhPpDRFQBM1YOz7NI8RnTq+BU3NbDflqO3sTdOAGaEf+ho8q1SG9hDdm1u1ildDJR5zNoMuUoyprFpG5g4DyA6+iuFNdLDccVJNoU1Jh3Zrsts7zZw==; 5:SyMI0Kbb34Q/jxH+mbw8QyPBVRG9peJ3k7ODeFBMMwXX0G0n+ZRTVPTqyG49zpxvyBz769hW1V8qtHAQbQluzXvCeSpwVSiwvallh8biqpcAy2E6415xPJHeWnvP11stx7CFoHqr7Iks3UxMJpvAzILN/jnrrWfoZ5DYwGX+u6w=; 7:zbmYDkIY53gmZxLfFMROYyZcs9rYyYggntWCuJ7ZqP7IHCU5pZ83EMYYeoSXNFAXtQWgPd+t6WDd0hYOy3vtdRpjBrbGoqAopvLUS7c89Ykl0JxaxHDdEzNXS7kNQvOYd8wmEiGYxmnOz6uZZiaGyw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b52a6e80-37e7-47c5-2893-08d63b63d204
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4560; 
x-ms-traffictypediagnostic: VI1PR07MB4560:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4560; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4560; 
x-forefront-prvs: 083751FCA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(366004)(346002)(136003)(199004)(189003)(19627405001)(476003)(186003)(6436002)(26005)(33656002)(99286004)(76176011)(5660300001)(55016002)(54896002)(25786009)(236005)(9686003)(5250100002)(74316002)(81156014)(8676002)(2906002)(486006)(102836004)(53546011)(7736002)(6506007)(81166006)(256004)(14444005)(86362001)(14454004)(446003)(6346003)(11346002)(478600001)(6116002)(3846002)(71200400001)(6916009)(68736007)(66066001)(6606003)(93886005)(7696005)(229853002)(8936002)(316002)(71190400001)(15650500001)(44832011)(54906003)(6246003)(105586002)(106356001)(97736004)(2900100001)(4326008)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4560; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-message-info: QDL7E4PsiMFOH+ys1xP/f+Kj1aEEMlvBklyw4VHwYpxTewNmzWcAHzmVioYZE7i6S35rPUBfzTguLtl7g6Az9sd8BNUCii0fPH1z7ry7ktI2ApqV1oVtlhQ/of+xHfG2L6q2e+qHVc25Tw9q8+zI5JF+vPS2X7HLeCW9c4+21/Lj1ud/4y999xoUmGhTT4p5y1fyIhBARykdmsTuKOVs1T090dMy/X8SAchuWSWihPh65g1UCo6UitMFb9FjPmwTAxPipOciG6aqOJrQVP4L8TTDCl3C+I9GK+RtXHHpgK0Y+mi0uaXgsfV+AZYfjZoD+7IxC90cOb7/lbRQNxPUDV9SQRRormAaUREzRtCq/Ng=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4782479ACB87D50B2C68B8D593F00VI1PR07MB4782eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b52a6e80-37e7-47c5-2893-08d63b63d204
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 16:55:22.9822 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4560
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fO5nE4eJuaT8sWLfKD9yRiSIZWlpCGQR9KKxt5vKButmOW BepMqbyElywVTa1l5oXIxCYZNaG84dRNzAsmpRVm2irNWaR5PAv89nv/z/P/P88DL0WIX/Il VKwyiVYrFfEygZAsPfEs2WPDYVO498Itmbzt7z0bufmxBclzZ4dJeePyNRv5YJ2G8OcHabVL vCBT33cUVNY6RQbp9SiUDBPujaTjY5Nptde+s8IYS281P9HseqnFMkmmo1yXbGRLAd4NkyPv UDYSUmL8GkHJ006SLYjxLwS6YQnHWh50lEaxTOJ8Anr0cZyhkAePbgwLuMcHBLNlrJuiBFgO OcturMEB7wCDbpxgewhchGBu7sHaBHt8Gn5XGAmu6Qw8zFwUcHwIMhruCNgcEu8ES6eclUX4 FBjzyq2zNDyorinhswVb7AuNK9OIZYQ3wWJ3A49lAjvB6FQljzsTg7atj+DYEaYnl/kcb4fc +Vprz1YwVuYgjocEkDsu4dgDzMXFVm8IVFWM2bBLAO5AMGB+ZQ1yhf4BnTUoDkq+1FuDjoBG 02U1S6Eu7z3JcQcBHSZxPvIuW7crxyowmkeJsrWjN0JX6RTJ6d7wzVBJcOwGNdUzVvaCJ/O9 aL1ehWzqkCNDM0xCtI+PJ62OPccwKqWnkk5qQqvfSt/8x1eH9J8D2hGmkMxO5OpuChfzFclM SkI7AoqQOYh8nVclUaQi5TKtVkWoL8TTTDvaQpEyJ9H+KHmYGEcrkug4mk6k1f+rPMpWko5c MqQzPRbbg6Y9gVVdvXZRxaqxhcLgzTcjatsyD4xmNcsCf9xtafQ+Vp4hvF6VcHswYIBKdTju d0Wa2mS34Of+fMmiDC0oJ/uDf6a92RZysvXjEDJ2pqWfP5r1afTtsuGi/9f4TM3kRNGKgTIU RdmnOmcWvBipr7w6cX94UbXQLZWRTIxilyuhZhT/AMRiDDNSAwAA
Archived-At: 
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-arch-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 26 Oct 2018 16:55:33 -0000

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


Excellent! Then the document is ready as far as I am concerned.

Regards,

Christer

________________________________
From: Cullen Jennings 
Sent: Friday, October 26, 2018 4:14 PM
To: Christer Holmberg
Cc: Sean Turner; Adam Roach; RTCWeb IETF; rtcweb-chairs@ietf.org
Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-=
security-arch-16



On Oct 22, 2018, at 11:30 PM, Christer Holmberg > wrote:

Hi,

Note Cullen's comment that it should be possible to include fingerprint att=
ributes in offers/answers that are not associated with the identity asserti=
on. The draft does not allow that, so I think it would be good if Cullen co=
uld indicate whether he is ok with that.

Regards,

Christer


Yes, I=92m fine with that.



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















Excellent! Then the document is ready as far as I am concerned.







Regards,







Christer








From: Cullen Jennings <f=
luffy@iii.ca>

Sent: Friday, October 26, 2018 4:14 PM

To: Christer Holmberg

Cc: Sean Turner; Adam Roach; RTCWeb IETF; rtcweb-chairs@ietf.org

Subject: Re: [rtcweb] Publication has been requested for draft-ietf-=
rtcweb-security-arch-16

 













On Oct 22, 2018, at 11:30 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:







Hi,









Note Cullen's comment that it should be possible to include fingerprint att=
ributes in offers/answers that are not associated with the identity asserti=
on. The draft does not allow that, so I think it would be good if Cullen co=
uld indicate whether he is ok with
 that.









Regards,









Christer















Yes, I=92m fine with that. 




















--_000_VI1PR07MB4782479ACB87D50B2C68B8D593F00VI1PR07MB4782eurp_--


From nobody Tue Oct 30 18:08:38 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77886130DCB for ; Tue, 30 Oct 2018 18:08:36 -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 OfpGfuYrT5hL for ; Tue, 30 Oct 2018 18:08:34 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 B5FEB1277CC for ; Tue, 30 Oct 2018 18:08:34 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id l41-v6so15901710qtl.8 for ; Tue, 30 Oct 2018 18:08:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=EKwSNs9CPepSdwJIwCm24Q8cWdhjPRqv6BiRumVoBMk=; b=Vtgjwo9oKAIExvveA+q0OeFD/dLrV43YzY0IIa4QoMI+i25eLMLE+QqYewYqhYw0u+ mq003utn+8duXFGXVWa7QJwFXjb83svRSQmc1W6nFyRqGGWWJUWxQsISoPQ+Sn9X0rt6 esVfLP0LsHtjW/7grwmjZWp7ljiTihtIADNO8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=EKwSNs9CPepSdwJIwCm24Q8cWdhjPRqv6BiRumVoBMk=; b=HJhT624T45zXSpRhOxCAjvGtCEccs2AWHWBDoK25dOWShOSOi0ezFSbpG/S+941srk lTTYNijDWK7r+vjShOyZYuTByzqy/EKVmDrpTifabapIUYR5JTckW1AVY8JYN9KEdQ/1 qev84r5sy1aM8+zabj5MhzPys7ncLsKalqZaPIGhoXKh89C8hBPj9+xvxeCYDhbLua55 KgN9DCd5poiP+eTjEkhr8vaISsdeohZMmxW6yZjXPRSyX3dAU5lsj4OeWZQ/Bz4i0l1L +SWnj1DTbhuM7DhwQmyXlqt/OHdqqvupT0CAx0iqOlhBi/9FZwLkkjSYvqrMa+2gnTDL /F6A==
X-Gm-Message-State: AGRZ1gKk1ZbhI0d33sNat4IjftJJcS3kERr+KzUsqgxVV/0pNjtPpYlk BvayjZASAdMcBhr+wgtimmLBS5XHOck=
X-Google-Smtp-Source: AJdET5cYq2C3kRyACc1YEXrrEbO9Bfly78WFVQYHNsibZIxWQuiJrWwhIdj8vv/pyBvEPaOIr4jizQ==
X-Received: by 2002:a0c:bd15:: with SMTP id m21mr65647qvg.57.1540948113553; Tue, 30 Oct 2018 18:08:33 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id w1-v6sm15876206qkd.6.2018.10.30.18.08.32 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 18:08:32 -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 11.5 \(3445.9.1\))
Message-Id: <103FEA6D-629A-42F9-9ACA-5518A2063B4E@sn3rd.com>
Date: Tue, 30 Oct 2018 21:08:31 -0400
To: RTCWeb IETF 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [rtcweb] RTCWEB@IETF103
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 31 Oct 2018 01:08:36 -0000

The RTCWEB WG will be meeting at IETF 103.  Our session is scheduled =
for: 16:10-18:10 Thursday in the "Meeting 2=E2=80=9D room; all times =
UTC+7.  The agenda can be found here:

https://datatracker.ietf.org/meeting/103/materials/agenda-103-rtcweb-00

The chair=E2=80=99s slides as well as the JSEP changes we will be =
discussing are here:

=
https://datatracker.ietf.org/meeting/103/materials/slides-103-rtcweb-ietf-=
103-rtcweb-wg-chair-slides-as-well-as-jsep-changes-00

Remote participation information can be found here:

https://www.meetecho.com/ietf103/rtcweb/

Cheers,

spt=


From nobody Tue Oct 30 19:48:39 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7912872C; Tue, 30 Oct 2018 19:48:37 -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 0GM67mXuEXcl; Tue, 30 Oct 2018 19:48:34 -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 6CFA71274D0; Tue, 30 Oct 2018 19:48:32 -0700 (PDT)
Received: from Svantevit.attlocal.net (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 w9V2mUK1041537 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Oct 2018 21:48:31 -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 Svantevit.attlocal.net
To: draft-ietf-rtcweb-security-arch.all@ietf.org, "rtcweb@ietf.org" 
From: Adam Roach 
Message-ID: <3283c7fe-6cc6-71b8-1208-d65e00c2df8e@nostrum.com>
Date: Tue, 30 Oct 2018 21:48:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [rtcweb] AD Review: draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 31 Oct 2018 02:48:38 -0000

[sorry for the re-send to the authors; I forgot to copy the WG on my 
first email]

This is my AD review for draft-ietf-rtcweb-security-arch. Several of the
comments below are marked [DISCUSS], which indicates issues that either 
require
discussion among the working group participants to resolve an ambiguity, or
issues that I would like to see addressed before asking for IETF review. I
think all of these should be easy to fix. I expect we'll talk about 
several of
them during the RTCWEB meeting next week.

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

[DISCUSS]

Per the discussion around Cluster 238 dependencies, please reference RFC 
8445
instead of RFC 5245.

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

Please fix the following nits:

   == The document seems to contain a disclaimer for pre-RFC5378 work, 
but was
      first submitted on or after 10 November 2008.  The disclaimer is 
usually
      necessary only for documents that revise or obsolete older RFCs, 
and that
      take significant amounts of text from those RFCs.  If you can 
contact all
      authors of the source material and they are willing to grant the BCP78
      rights to the IETF Trust, you can and should remove the disclaimer.
      Otherwise, the disclaimer is needed and you can ignore this comment.
      (See the Legal Provisions document at
      https://trustee.ietf.org/license-info for more information.)

   == Unused Reference: 'RFC5234' is defined on line 1799, but no explicit
      reference was found in the text

(This latter nit should probably be fixed by referencing RFC 5234 from §5)

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

I note that the early security review had some DISCUSS-level concerns about
the language in section 4.1. I don't see any discussion of this on the 
mailing
list, and the cited language is still in the document. See
https://mailarchive.ietf.org/arch/msg/rtcweb/aqSxsEtE-f4tVlT8je5HxwjOeho

Please ensure this review is addressed along with any other IETF last-call
comments.

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

§3.1:

 >  Note that merely being authenticated does not make these entities
 >  trusted.  For instance, just because we can verify that
 >  https://www.evil.org/

Note that evil.org has been delegated by ICANN and appears to be in
active use. Please consider "https://www.evil.example/" or
"https://evil.example.org/" instead.

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

§4:

 >  of signaling.  Specifically, Alice and Bob have relationships with
 >  some Identity Provider (IdP) that supports a protocol (such as OpenID
 >  Connect) that can be used to demonstrate their identity to other

Consider adding a citation for Open ID Connect.

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

§4.1:

 >  In this example, we show Alice and Bob using a separate
 >  identity service, though the identity service may be the same entity
 >  as the calling service or there may be no identity service at all.

It seems to me that there should be some discussion here about the 
diminished
guarantees of non-interceptability of media when the identity service 
and the
calling service are under the same domain of control.

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

§4.1:

 >  Once the PeerConnection is created, the calling service JS needs to
 >  set up some media.  Because this is an audio/video call, it creates a
 >  MediaStream with two MediaStreamTracks

Consider adding a citation to JSEP for the formal definition of these 
terms when
they first appear.

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

§4.1:

 >  In the current W3C API, once some streams have been added, Alice's
 >  browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep]
 >  containing:
 >
 >  o  Media channel information
 >
 >  o  Interactive Connectivity Establishment (ICE) [RFC5245] candidates

I understand that this is intended as a high-level summary of behavior, 
but this
second bullet is pretty uncommon in the general case due to the use of 
Trickle
ICE. I suggest removing or caveating it.


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

§4.1:

 >  [RFC5246].  The signaling server processes the message from Alice's
 >  browser, determines that this is a call to Bob and sends a signaling
 >  message to Bob's browser (again, the format is currently undefined).

The phrasing here ("currently undefined") makes this sound like a to-do 
of sorts
for the working group. I believe it would be clearer to describe it as
"implementation-defined" or something similar to that.

Nit: "...a call to Bob, and sends..."

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

§4.1:

 >  This allows
 >  the browser to display a trusted element in the browser chrome
 >  indicating that a call is coming in from Alice.

"browser chrome" is a very specific term of art that readers of this 
document
may be unfamiliar with. Please either define it or rephrase along the 
lines of
"...trusted element in a privileged part of the browser's user interface..."

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

§4.3:

 >  If Alice and Bob authenticated via their IdPs,
 >  then they also know that the signaling service is not mounting a man-
 >  in-the-middle attack on their traffic.

It seems that this should be caveated to point out that an IdP that colludes
with the signaling server could enable the signaling service to mount an
active MITM attack on their traffic.

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

§5.1.2:

 >  When an answerer receives an offer that contains an 'identity'
 >  attribute, the answerer can use the the attribute information to

Nit: s/the the/the/

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

[DISCUSS]

§5.1.4:

 >  Offer processing of an 'identity' attribute is the same as that
 >  described in Section 5.1.2.

Many of the protocols that are used inter-domain don't have an easy way to
"reject" an answer (and it's not a well-defined operation in RFC 3264 
either).
It would be far less ambiguous to instead be explicit that the session is
terminated; e.g.:

    When an offerer receives an answer that contains an 'identity'
    attribute, the offerer can use the attribute information to
    contact the IdP, and verify the identity of the peer.  If the
    identity verification fails, the offerer MUST terminate the
    session.

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

[DISCUSS]

§5.1.5:

This section omits any discussion of what the clients are supposed to do 
if an
updated fingerprint fails validation. Presumably, if the fingerprint in 
an offer
fails, the answerer can reject it, and the offerer can roll back the 
session. If
the fingerprint in an answer fails, I think the only recovery is to 
terminate
the session. It's not clear whether we want these to be symmetrical (both
terminate the session), but I think the procedure needs to be clearly 
spelled
out regardless of whether that's true (or, if we want to leave it up to the
implementation whether to reject the offer or terminate the session, we 
should
say so explicitly).

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

[DISCUSS]

§6.2 seems somewhat schizophrenic on how insecure HTTP is handled. For 
example:

 >  Because HTTP origins cannot be securely established against network
 >  attackers, implementations MUST NOT allow the setting of permanent
 >  access permissions for HTTP origins.  Implementations MUST refuse all
 >  permissions grants for HTTP origins.

My reading of this is that one sentence places restrictions on how 
devices can
be accessed from insecure pages, while the next one forbids such access
altogether. If that's not the intention of these respective sentences, then
they probably need some clarification.

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

§6.2:

 >     this may not be necessary in systems that are non-windows-based
 >     but that have good notifications support, such as phones.]

Presumably, this means "non-window-based" rather than 
"non-Windows-based". The
current phrasing implies the second, as the adjectival form of nouns are
typically singular.

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

§6.3:

 >  While continuing consent is required, the ICE [RFC5245]; Section 10

To make sure it doesn't get overlooked, I want to highlight that this 
changes to
"[RFC8445] Section 11".

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

§6.3:

 >  The current WG consensus is to use ICE
 >  Binding Requests for continuing consent freshness.

This phrasing won't age well.

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

§6.3:

 >  A separate document will profile
 >  the ICE timers to be used; see [RFC7675].

The future tense here is confusing.

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

§6.4:

 >     the user to optimize performance by reconfiguring to allow non-
 >     turn candidates during an active call if the user decides they no

Nit: "non-TURN"

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

[DISCUSS]

§6.5:

 >   All implementations MUST implement DTLS 1.0

I understand that it's still a work in progress, but the current text in
draft-ietf-tls-oldversions-deprecate §9 would seem to counter-indicate this
recommendation:

    o  Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].

Unless I misunderstand the situation, one of these two documents needs to
change. Right?

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

[DISCUSS]

§6.5:

 >     *  The "security characteristics" MUST indicate the cryptographic
 >        algorithms in use (For example: "AES-CBC".)  However, if Null
 >        ciphers are used, that MUST be presented to the user at the
 >        top-level UI.

Text earlier in this section forbids the negotiation of null cipher 
suites. I
suspect this is legacy text?

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

§7:

 >  Recently, a number of Web-based identity technologies (OAuth,

Consider citing RFC 6749.

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

§7.1:

 >  Authoritative:   IdPs which have verifiable control of some section
 >     of the identity space.  For instance, in the realm of e-mail, the
 >     operator of "example.com" has complete control of the namespace
 >     ending in "@example.com".  Thus, "alice@example.com" is whoever
 >     the operator says it is.  Examples of systems with authoritative
 >     identity providers include DNSSEC, RFC 4474, and Facebook Connect

Please update to point to RFC 8224. Also, please add this an informative
reference.

Also, consider citing RFC 4035 (or something more appropriate -- it's 
not really
my area) for "DNSSEC"

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

§7.2:

 >  In order to provide security without trusting the calling site, the
 >  PeerConnection component of the browser must interact directly with
 >  the IdP.  The details of the mechanism are described in the W3C API
 >  specification, but the general idea is that the PeerConnection

Please provide a citation to:

[webrtc-identity]
     Identity for WebRTC 1.0. Adam Bergkvist; Daniel Burnett; Cullen 
Jennings;
     Anant Narayanan; Bernard Aboba; Taylor Brandstetter. W3C. W3C Candidate
     Recommendation. URL: 
https://w3c.github.io/webrtc-identity/identity.html

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

§7.2:

 >  component downloads JS from a specific location on the IdP dictated

Please expand "JS" on first use.

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

§7.7:

 >  The application can then load the provided URL to enable the user to
 >  enter credentials.  The communication between the application and the
 >  IdP is described in [webrtc-api].

All information involving the IdP has been moved from the [webrtc-api] 
document
into the [webrtc-identity] document I point to above. Please update 
accordingly.

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

§7.7:

 >  For instance, an OAuth-based protocol will likely require using the
 >  IdP as an oracle, whereas with a signature-based scheme might be able
 >  to verify the assertion without contacting the IdP, provided that it
 >  has cached the relevant public key.

This sentence is ungrammatical in a way that isn't trivial to fix. Please
re-work.

---------------------------------------------------------------------------
[DISCUSS]

§8.1:

 >  The identity provided from the IdP to the RP browser MUST consist of
 >  a string representing the user's identity.  This string is in the
 >  form "@", where "user" consists of any character except
 >  '@', and domain is an internationalized domain name [RFC5890].

This needs to specify whether the domain name is encoded as an A-label 
or as a
U-label. Although either would work, I suspect that U-label is what is 
intended.

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

§8.1:

 >  Sites that have identities that do not fit into the RFC822 style (for

Please either make RFC822 a citation or designate this using different
terminology (e.g., "@").

---------------------------------------------------------------------------
[DISCUSS]

§8.1:

 >  instance, identifiers that are simple numeric values, or values that
 >  contain '@' characters) SHOULD convert them to this form by escaping
 >  illegal characters and appending their IdP domain (e.g.,
 >  user%40133@identity.example.com), thus ensuring that they are
 >  authoritative for the identity.

The form of escaping here needs to either be normatively defined, or this
document needs to be extremely clear that the receiving party cannot 
rely on the
ability to un-escape user portions. The example implies the use of URI-style
percent encoding -- if this is meant to be normative, please cite RFC 
3986 §2.1.

If no canonical escaping mechanism is intended, this should probably use 
a term
other than "escaping," as the reciprocal operation of "unescaping" becomes
impossible. Something like "transformed" seems more appropriate.

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

§9.2:

 >  Such services SHOULD instruct the browser to use separate
 >  DTLS keys for each call and also to use TURN throughout the call.

The phrasing here ("instruct") seems a bit odd, as this is required by this
document to be the default mode of behavior. Something involving 
"...SHOULD not
override..." would be less confusing.



From nobody Wed Oct 31 08:36:35 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287A0130E2A for ; Wed, 31 Oct 2018 08:36:34 -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 oBP8fKkbJ9Xr for ; Wed, 31 Oct 2018 08:36:33 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 DD0B7130DE5 for ; Wed, 31 Oct 2018 08:36:32 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id q1so8476165qkf.13 for ; Wed, 31 Oct 2018 08:36:32 -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=jtalfBP3KItGJvfqv1gKcjxBu+QifJ+gM8muug6OQ7s=; b=fPOIII6qinpRDnNVa75bf0HYD5nDG0BrQB+6GyNUUck4Pnwtmm+EGc39r+k8om8t0s /PXOESUAncrGWk6lM6Yrxi2ZoQV2K9l2AFA4aEVezAhkfycvoYT5nn898m+00lxlfp0T S8G8E0HqzQOedNtu3ro58pusmJ2TEnf4tpzr0=
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=jtalfBP3KItGJvfqv1gKcjxBu+QifJ+gM8muug6OQ7s=; b=eDKnYuqSrHFQTfadIEdqQWe9C+h+mmxozIvG9kwQiqDo6rVD27MmMTejyLYG5rA5tZ gMUwbiqOrnO11XhsEU8Q8DF+sFNPnXRxNwA8QW8mSsMV1jK8vxwbsFp5sEZ78ijeXR4E XJhcWkMyMLrDfcY+tW5xXLouSmNejqU/GYuYR4BvIOGWs9/Ssxj3ghqBBSbPQJqyoJYw Ey+/c8Db7V1UYaiZ0y5NsIGVxKPiQ+EGAWtyOuAD8H7PEZJNmbil5+/7xdugLoBo3eWX DO1cyfwflz5XD2Iijun/spVp6XvUS4fdX6RBnCZ7UIUDkMGxdVcBJnUS25Y+s08wdIm1 lAuQ==
X-Gm-Message-State: AGRZ1gLBi5kOMg8TtcCDCtO9ju/HBIVi/YsM61eb58UbhY+K9ojqdCX7 /4wBEBOuXztrakYrrIWH8f0+eFdq1gE=
X-Google-Smtp-Source: AJdET5fkc4UEcolADNBGDjXZtKU8bun0ZmMtXnSrYg80CVSoMK/zf0zAg93ex+wnQ3ARiPCjCW551w==
X-Received: by 2002:aed:2325:: with SMTP id h34mr3149452qtc.286.1541000191773;  Wed, 31 Oct 2018 08:36:31 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id o27sm7447387qkh.35.2018.10.31.08.36.30 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 08:36:30 -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 11.5 \(3445.9.1\))
Date: Wed, 31 Oct 2018 11:36:29 -0400
References: <3283c7fe-6cc6-71b8-1208-d65e00c2df8e@nostrum.com>
To: "rtcweb@ietf.org" 
In-Reply-To: <3283c7fe-6cc6-71b8-1208-d65e00c2df8e@nostrum.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [rtcweb] AD Review: draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-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, 31 Oct 2018 15:36:34 -0000

> On Oct 30, 2018, at 22:48, Adam Roach  wrote:
>=20
> I expect we'll talk about several of
> them during the RTCWEB meeting next week.

Please note that we will have plenty of time to address Adam=E2=80=99s =
comments during our 2hr slot on Thursday.  Please come prepared to help =
get us across the finish line.

spt=