From nobody Mon Oct 3 06:17:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C622B12B17A for ; Mon, 3 Oct 2016 06:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lCVfejRMciri for ; Mon, 3 Oct 2016 06:17:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE3712B05C for ; Mon, 3 Oct 2016 06:17:25 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1956A324EB6 for ; Mon, 3 Oct 2016 15:17:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.43]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D8EA44C06C for ; Mon, 3 Oct 2016 15:17:22 +0200 (CEST) Received: from OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0301.000; Mon, 3 Oct 2016 15:17:23 +0200 From: To: "rtcweb@ietf.org" Thread-Topic: New draft submitted draft-copeland-rtcweb-p2p-idp-auth-00 Thread-Index: AdIddNmZCUYeJUoVTASrqvgEZC1Alw== Date: Mon, 3 Oct 2016 13:17:22 +0000 Message-ID: <7325_1475500642_57F25A62_7325_7355_1_3050D245D58D024B9A72E6E33529DCA216AB273F@OPEXCLILM42.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_3050D245D58D024B9A72E6E33529DCA216AB273FOPEXCLILM42corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.3.123316 Archived-At: Subject: [rtcweb] New draft submitted draft-copeland-rtcweb-p2p-idp-auth-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 13:17:28 -0000 --_000_3050D245D58D024B9A72E6E33529DCA216AB273FOPEXCLILM42corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to inform you that a new draft has been submitted on identity = requirements for the WebRTC communication: https://www.ietf.org/id/draft-co= peland-rtcweb-p2p-idp-auth-00.txt . This draft has been written by a group of people from Orange, Deutsche Tele= kom and Institut Mines Telecom, involved in reThink collaborative project (= https://rethink-project.eu/ ). It studies the relationships of WebRTC commu= nication users with their web Calling Services (CS) and their Identity Prov= iders (IdPs), in order to identify important requirements for IdP based pee= r-to-peer authentication. We would be very pleased to present this to the next IETF meeting. Simon B=E9cot, Orange Labs ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_3050D245D58D024B9A72E6E33529DCA216AB273FOPEXCLILM42corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to inform you that a new draft has been= submitted on identity requirements for the WebRTC communication: https://www.ietf.org/id/draft-copeland-rtcweb-p2p-idp-auth-00.txt .<= o:p>

This draft has been written by a group of people fro= m Orange, Deutsche Telekom and Institut Mines Telecom, involved in reThink = collaborative project (https://reth= ink-project.eu/ ). It studies the relationships of WebRTC communication users with their web Calling Service= s (CS) and their Identity Providers (IdPs), in order to identify important = requirements for IdP based peer-to-peer authentication.

We would be very pleased to present this to the next= IETF meeting.

 

Simon B=E9cot,

Orange Labs

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_3050D245D58D024B9A72E6E33529DCA216AB273FOPEXCLILM42corp_-- From nobody Tue Oct 4 00:36:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8C71295E0; Tue, 4 Oct 2016 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 OQSCmRj4QXhi; Tue, 4 Oct 2016 00:35:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5841295D5; Tue, 4 Oct 2016 00:35:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7EF7D7CAD73; Tue, 4 Oct 2016 09:35:54 +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 miZtSUPl-oDB; Tue, 4 Oct 2016 09:35:51 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805] (unknown [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805]) by mork.alvestrand.no (Postfix) with ESMTPSA id 432057CAD72; Tue, 4 Oct 2016 09:35:50 +0200 (CEST) To: Michael Welzl References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> From: Harald Alvestrand Message-ID: Date: Tue, 4 Oct 2016 09:35:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: RTCWeb IETF , Mirja Kuehlewind , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 07:36:00 -0000 After listening to the (silent) list and considering the matter further, I'm adding the following paragraph at the end of the "local prioritization" section: Note that this specification doesn't dictate when disparate streams are to be "congestion controlled under the same congestion control regime". The issue of coupling congestion controllers is explored further in [I-D.ietf-rmcat-coupled-cc]. and adding that as an informational reference. Den 30. sep. 2016 14:28, skrev Michael Welzl: > >> On 30. sep. 2016, at 12.59, Harald Alvestrand wrote: >> >> Den 30. sep. 2016 12:31, skrev Michael Welzl: >>> >>>> On 30. sep. 2016, at 11.41, Harald Alvestrand wrote: >>>> >>>> Wanting to ask .... >>>> >>>> do you have commitment from some of the browser vendors that they intend >>>> to add -coupled to their congestion control code? >>> >>> No committment, but I did have some hope that you guys at Google would be interested? >>> Stefan was interested in coupling the data channel with the media channel, which is probably a straightforward way of adapting our coupling algorithm. >>> >>> We’re going to work on this code ourselves; we already have preliminary code on coupling + shared bottleneck detection in Chromium, but this is work in progress that was interrupted for a year due to a contract that let us focus on coupling TCP for a while (which also works very well, BTW; we’ll provide an update at ICCRG in Seoul). So we’re (well: Safiqul is) just about to get back to it. >>> >>> >>>> That would go a long way towards allaying my fear that this would be >>>> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. >>> >>> I think what I’m asking for is a far cry from a MUST. >>> It’s merely about putting a reference there such that implementers see both possibilities (coupling and/or dscp), not only one (dscp). >>> >> >> The DSCP section would be the wrong section for it anyway. >> >> References to -coupled should be in the "local prioritization" section >> (4.1). > > I agree. I didn’t mean for this to be in the same section. > > >> My worry about -coupled in the previous round is that it's a *specific* >> instance of coupled congestion controllers (and experimental-track). >> >> We don't yet know if it's *the* way. > > Understood - but: > > 1) draft-ietf-rmcat-coupled-cc doesn’t say that the algorithm in it is *the* way. I believe it correctly acknowledges that you could e.g. also have a single congestion control instance for everything ("congestion manager” style coupling). Both implementations have their pro’s and con’s - our algorithm is easier in some ways, e.g. for turning on and off (which is useful when coupling flows to multiple destinations). > > > 2) as I said, we have lots of indications that this algorithm works for *many* controllers with only minimal changes. > > Some details: > We successfully used it with NADA and GCC ( http://heim.ifi.uio.no/michawe/research/publications/noms2016.pdf ), but also TFRC and RAP ( http://heim.ifi.uio.no/michawe/research/publications/csws14.pdf ), LEDBAT ( slide 31: http://heim.ifi.uio.no/michawe/research/publications/caia2014.pdf ), also LEDBAT combined with another congestion control (don’t remember which, maybe RAP), and most recently TCP. TCP is perhaps an extreme case because it has so many states. If you ignore all this and just blindly apply our algorithm, you get pretty much the behavior of E-TCP, which isn’t bad ( http://www.isi.edu/div7/publication_files/effects_of_ensemble.pdf ). We have improved on it by correctly incorporating the states - this makes things better, but note that all of this is better than simply leaving flows as they are and let them compete against each other, in particular when the goal is to minimize latency. > > > I’d find it pretty strange if this isn’t enough reason to justify a mention of this possibility and a reference. > > >> That said, I personally wouldn't worry too much about mentioning it, but >> it's a post-IESG change without IESG buy-in, so I'll want more >> authorization to do that. > > Sure > > cheers, > Michael > From nobody Tue Oct 4 01:42:32 2016 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 8F94112965B; Tue, 4 Oct 2016 01:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147557055058.12851.8144717927980126130.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2016 01:42:30 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-16.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 08:42:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-16.txt Pages : 20 Date : 2016-10-04 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-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 Tue Oct 4 01:48:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14821296AD; Tue, 4 Oct 2016 01:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] 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 VcUhJlc04a1z; Tue, 4 Oct 2016 01:48: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 9D1B71296B1; Tue, 4 Oct 2016 01:47:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ABBD27CAD77; Tue, 4 Oct 2016 10:47:57 +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 yL2275Ijrs8D; Tue, 4 Oct 2016 10:47:56 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805] (unknown [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805]) by mork.alvestrand.no (Postfix) with ESMTPSA id C2F707CAD76; Tue, 4 Oct 2016 10:47:55 +0200 (CEST) References: <147557055077.12851.1347339442333163275.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" , "Mirja Kuehlewind (IETF)" , "rtcweb-chairs@ietf.org" , Alissa Cooper From: Harald Alvestrand X-Forwarded-Message-Id: <147557055077.12851.1347339442333163275.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 4 Oct 2016 10:47:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147557055077.12851.1347339442333163275.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-16.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 08:48:03 -0000 I believe this version closes all post-IESG open issues on -transports. Thank you for your consideration. -------- Videresendt melding -------- Emne: New Version Notification for draft-ietf-rtcweb-transports-16.txt Dato: Tue, 04 Oct 2016 01:42:30 -0700 Fra: internet-drafts@ietf.org Til: Harald Alvestrand A new version of I-D, draft-ietf-rtcweb-transports-16.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-ietf-rtcweb-transports Revision: 16 Title: Transports for WebRTC Document date: 2016-10-04 Group: rtcweb Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-16.txt Status: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ Htmlized: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-16 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-16 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Oct 4 04:41:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E292129833 for ; Tue, 4 Oct 2016 04:41:32 -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 6q1rmzb9d3Vt for ; Tue, 4 Oct 2016 04:41:30 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910191297E4 for ; Tue, 4 Oct 2016 04:41:30 -0700 (PDT) Received: from [130.209.247.112] (port=59731 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1brO66-0006FG-3x; Tue, 04 Oct 2016 12:41:28 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> Date: Tue, 4 Oct 2016 12:41:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 11:41:32 -0000 > On 26 Sep 2016, at 10:35, Harald Alvestrand = wrote: >=20 > Den 26. sep. 2016 11:14, skrev Magnus Westerlund: >> Den 2016-09-26 kl. 10:48, skrev Harald Alvestrand: >>> Den 23. sep. 2016 10:56, skrev Magnus Westerlund: >>>> Hi, >>>>=20 >>>> I think the use cases looks fairly covering. >>>>=20 >>>> I want to add an alternative way of thinking on how the SDES item = (MID, >>>> RID) related demultiplexing part is handled. So the RID and MID in = RTP >>>> header extensions or in RTSP SDES packets results in these values = being >>>> bound to the SSRC until further notice. So packets arriving without >>>> actual RTP header extensions can still be handled according to the = SSRCs >>>> associated SDES items. =46rom my perspective all the cases with MID = and >>>> RID can be handled on a per packet basis rules without latching the = SSRC >>>> to a specific receiver. Instead what is "latched" is the SDES = values to >>>> the SSRC. Still at the point of change there needs to take the >>>> combination of SSRC and Seq into account to avoid miss routing = packets. >>>>=20 >>>> So my general handling algorithm would be this sequence: >>>>=20 >>>> 1. Check if RTP header extensions update any SDES item for the = SSRC. >>>> a. If they do, mark the Sequence number and keep the old SDES = item as >>>> valid prior to this extended sequence number. >>>>=20 >>>> 2. Determine the set of relevant SDES items that applies for this >>>> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID = and >>>> RID. >>>>=20 >>>> 3. Perform the demuxing algorithm >>>=20 >>> I don't understand this as written. >>> When an RTP packet arrives before the RTCP packet containing SDES, = we >>> can't latch to the content of the RTCP packet; we haven't seen it = yet. >>=20 >> So if neither RTP header extension nor RTCP SDES item with RID/MID = for >> that SSRC has been received, then you don't have that information and >> you will have to either queue or drop that packet if the relation = isn't >> otherwise clear through PT or SSRC signalling in SDP. >>=20 >>>=20 >>> You can, in theory, latch RID and MID for the SSRC to the values in = the >>> SDES packet you haven't seen yet, but that seems somewhat backwards. >>>=20 >>> The problematic sequence is: >>>=20 >>> 1) RTP packet(s) with header extensions >>> 2) RTP packet(s) without header extensions >>> 3) SDES RTCP packet >>=20 >> I don't see why the above is problematic. Step one gives you the SDES >> item for that SSRC. Thus in step 2 one knows that the SSRC has the >> MID/RID value that you need. >>=20 >> I don't understand why you are not binding the SDES info from the RTP >> header extension to the SSRC. >=20 > OK, I had missed the change of the RID header extension from being its > own header extension to being a component of the SDES header extension = only. >=20 > Then it all makes sense! Thanks! I think I agree with Magnus. RTP flows are based around SSRCs, so the = key to demultiplexing is that RTP packets are grouped by SSRC, then that = SSRC is mapped to some higher level role based on some combination of = signalled SSRC, MID, RID, etc.=20 I=92d suggest that the right way to write Section 7 of JSEP is not =93how = to route RTP packets=94, as RTP packets are always grouped by SSRC, but = rather how to map SSRCs to higher-level roles, based on updates of the = mapping received in SDP, RTCP SDES, and RTP header extensions. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 4 05:00:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E594129833 for ; Tue, 4 Oct 2016 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6xTlDaK_bIK for ; Tue, 4 Oct 2016 05:00:41 -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 6B04C129831 for ; Tue, 4 Oct 2016 05:00:41 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-d3-57f399e6422c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id DD.CD.31035.6E993F75; Tue, 4 Oct 2016 14:00:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 14:00:38 +0200 From: Christer Holmberg To: Colin Perkins , Harald Alvestrand Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCABLS/gIAAB1yAgAAFnACADLXmgIAAOXmA Date: Tue, 4 Oct 2016 12:00:38 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> In-Reply-To: <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71B32D39E2F6C94687CECDCE10ADB299@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7tO7zmZ/DDV62q1ssf3mC0eJYXxeb xdp/7ewOzB5XJlxh9Zh2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4Mk4fWc1a8EWh4vrOM2wN jLukuhg5OSQETCROrjjK3MXIxSEksJ5RYtKBJihnEaPE2sV/GLsYOTjYBCwkuv9pgzSICARK vF/8mRHEZhZQl7iz+Bw7iC0sYCCxsO0rO0i5iIChRFefPER5nsS/GxvAwiwCKhLrr9aAhHkF rCX+v5/IDrFpOYvE1t3H2UASnAKOEjfX9TGD2IwCYhLfT61hglglLnHryXwmiJsFJJbsOc8M YYtKvHz8jxXEFhXQk/j+dTYzyC4JASWJaVvTIFr1JG5MncIGYVtLLH/9Hup6bYllC18zQ9wj KHFy5hOWCYzis5Bsm4WkfRaS9llI2mchaV/AyLqKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQT IzD+Dm75rbqD8fIbx0OMAhyMSjy8CSmfwoVYE8uKK3MPMUpwMCuJ8D6a8TlciDclsbIqtSg/ vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsapxUl+qlc23VkpqrXjUtb6 G6o/Zr7cG5KnfqT+96c+J4+/d354qsqWPBA5/SLTeuJZ6x0ZfasFRf4f1HivsqLX71nMAoOd nwXX/GZZyyscLMjjc4anKeS4GWOyGRfjvWTbR9Kzfe7tMGk/2CucvCCnTH5BZrt4wAFRbt8v HPOcNnFpByg8W6LEUpyRaKjFXFScCACNqoCruwIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:00:46 -0000 Hi, I still question why the low-level RTP demuxing shall be described in JSEP, instead of e.g., BUNDLE. Keep in mind that all BUNDLE implementations may not implement JSEP, but I still think we want the RTP demuxing to be done in the same way? Regards, Christer On 04/10/16 14:41, "rtcweb on behalf of Colin Perkins" wrote: > >> On 26 Sep 2016, at 10:35, Harald Alvestrand >>wrote: >>=20 >> Den 26. sep. 2016 11:14, skrev Magnus Westerlund: >>> Den 2016-09-26 kl. 10:48, skrev Harald Alvestrand: >>>> Den 23. sep. 2016 10:56, skrev Magnus Westerlund: >>>>> Hi, >>>>>=20 >>>>> I think the use cases looks fairly covering. >>>>>=20 >>>>> I want to add an alternative way of thinking on how the SDES item >>>>>(MID, >>>>> RID) related demultiplexing part is handled. So the RID and MID in >>>>>RTP >>>>> header extensions or in RTSP SDES packets results in these values >>>>>being >>>>> bound to the SSRC until further notice. So packets arriving without >>>>> actual RTP header extensions can still be handled according to the >>>>>SSRCs >>>>> associated SDES items. From my perspective all the cases with MID and >>>>> RID can be handled on a per packet basis rules without latching the >>>>>SSRC >>>>> to a specific receiver. Instead what is "latched" is the SDES values >>>>>to >>>>> the SSRC. Still at the point of change there needs to take the >>>>> combination of SSRC and Seq into account to avoid miss routing >>>>>packets. >>>>>=20 >>>>> So my general handling algorithm would be this sequence: >>>>>=20 >>>>> 1. Check if RTP header extensions update any SDES item for the SSRC. >>>>> a. If they do, mark the Sequence number and keep the old SDES item >>>>>as >>>>> valid prior to this extended sequence number. >>>>>=20 >>>>> 2. Determine the set of relevant SDES items that applies for this >>>>> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID >>>>>and >>>>> RID. >>>>>=20 >>>>> 3. Perform the demuxing algorithm >>>>=20 >>>> I don't understand this as written. >>>> When an RTP packet arrives before the RTCP packet containing SDES, we >>>> can't latch to the content of the RTCP packet; we haven't seen it yet. >>>=20 >>> So if neither RTP header extension nor RTCP SDES item with RID/MID for >>> that SSRC has been received, then you don't have that information and >>> you will have to either queue or drop that packet if the relation isn't >>> otherwise clear through PT or SSRC signalling in SDP. >>>=20 >>>>=20 >>>> You can, in theory, latch RID and MID for the SSRC to the values in >>>>the >>>> SDES packet you haven't seen yet, but that seems somewhat backwards. >>>>=20 >>>> The problematic sequence is: >>>>=20 >>>> 1) RTP packet(s) with header extensions >>>> 2) RTP packet(s) without header extensions >>>> 3) SDES RTCP packet >>>=20 >>> I don't see why the above is problematic. Step one gives you the SDES >>> item for that SSRC. Thus in step 2 one knows that the SSRC has the >>> MID/RID value that you need. >>>=20 >>> I don't understand why you are not binding the SDES info from the RTP >>> header extension to the SSRC. >>=20 >> OK, I had missed the change of the RID header extension from being its >> own header extension to being a component of the SDES header extension >>only. >>=20 >> Then it all makes sense! Thanks! > >I think I agree with Magnus. RTP flows are based around SSRCs, so the key >to demultiplexing is that RTP packets are grouped by SSRC, then that SSRC >is mapped to some higher level role based on some combination of >signalled SSRC, MID, RID, etc. > >I=B9d suggest that the right way to write Section 7 of JSEP is not =B3how = to >route RTP packets=B2, as RTP packets are always grouped by SSRC, but rathe= r >how to map SSRCs to higher-level roles, based on updates of the mapping >received in SDP, RTCP SDES, and RTP header extensions. > >--=20 >Colin Perkins >https://csperkins.org/ > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Oct 4 05:09:31 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A8E129838 for ; Tue, 4 Oct 2016 05:09:29 -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 wM8qKHu6rVMD for ; Tue, 4 Oct 2016 05:09:24 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17A8129837 for ; Tue, 4 Oct 2016 05:09:24 -0700 (PDT) Received: from [130.209.247.112] (port=60071 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1brOX9-0004uP-84; Tue, 04 Oct 2016 13:09:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 4 Oct 2016 13:09:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75570489-55C6-4B55-97B5-E0E718F9D130@csperkins.org> References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:09:29 -0000 > On 4 Oct 2016, at 13:00, Christer Holmberg = wrote: >=20 > I still question why the low-level RTP demuxing shall be described in > JSEP, instead of e.g., BUNDLE. >=20 > Keep in mind that all BUNDLE implementations may not implement JSEP, = but I > still think we want the RTP demuxing to be done in the same way? Don=E2=80=99t you need both?=20 BUNDLE would specify how to map an RTP SSRC onto something described in = SDP, using the combination of a=3Dssrc: lines, and the information = carried in RTCP and RTP header extensions (MID, RID, etc.). That is, it = maps SSRC -> =E2=80=9Crole=E2=80=9D. JSEP would specify how to map that =E2=80=9Crole=E2=80=9D onto the = concepts visible in the Javascript API. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 4 05:19:07 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D141129838 for ; Tue, 4 Oct 2016 05:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GofhD-hHCGhi for ; Tue, 4 Oct 2016 05:19:04 -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 56506129835 for ; Tue, 4 Oct 2016 05:19:04 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-25-57f39e361cda Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 08.52.31035.63E93F75; Tue, 4 Oct 2016 14:19:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 14:18:09 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCABLS/gIAAB1yAgAAFnACADLXmgIAAOXmA///OXwCAADaFAA== Date: Tue, 4 Oct 2016 12:18:09 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <75570489-55C6-4B55-97B5-E0E718F9D130@csperkins.org> In-Reply-To: <75570489-55C6-4B55-97B5-E0E718F9D130@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <76881C572C132449B5691B7B900B8E1C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7pa7ZvM/hBpfaDSyWvzzBaHGsr4vN Yu2/dnYHZo8rE66weky7f5/NY8mSn0wBzFFcNimpOZllqUX6dglcGUem7Gct6GCvmPbzPUsD 40nWLkZODgkBE4nmcwtZuhi5OIQE1jNKzPl9hhXCWcQocXXjIcYuRg4ONgELie5/2iANIgKq EjuO/2MEsZkFgiV6uyaDDRIWMJBY2PaVHaRcRMBQoqtPHqK8TmJ52zV2EJtFQEXi/6udLCA2 r4C1RNP6zYwQqyawSlw5chZsJqeAo8SCq/fBGhgFxCS+n1rDBLFLXOLWk/lMEEcLSCzZc54Z whaVePn4H9gNogJ6Et+/zoaKK0p8fLUP6k49iRtTp7BB2NYSf+YcYoGwtSWWLXzNDHGQoMTJ mU9YJjCKz0KybhaS9llI2mchaZ+FpH0BI+sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAY PLjlt+oOxstvHA8xCnAwKvHwJqR8ChdiTSwrrsw9xCjBwawkwis/93O4EG9KYmVValF+fFFp TmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYwC56dO3HPm3FYL2XeBS+Rnbf9s eqryfcaXF7Fdpb68xace5TnUd2os+sDzRnuFuUfeJO5034WXstYUy/UL/Zc9pZ2z2Wu+vdzT GztqvKc7rdBjev3mykfhVUwdx1bmPp7z6UTApSsJmeuP3NNdGP/X686+h1cCNYMd10qeOXyL 7fxEZdWVXmICSizFGYmGWsxFxYkAKlnn/b0CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:19:06 -0000 Hi, >> On 4 Oct 2016, at 13:00, Christer Holmberg >> wrote: >>=20 >> I still question why the low-level RTP demuxing shall be described in >> JSEP, instead of e.g., BUNDLE. >>=20 >> Keep in mind that all BUNDLE implementations may not implement JSEP, >>but I >> still think we want the RTP demuxing to be done in the same way? > >Don=B9t you need both? Yes. >BUNDLE would specify how to map an RTP SSRC onto something described in >SDP, using the combination of a=3Dssrc: lines, and the information carried >in RTCP and RTP header extensions (MID, RID, etc.). That is, it maps SSRC >-> =B3role=B2. Yes. >JSEP would specify how to map that =B3role=B2 onto the concepts visible in >the Javascript API. Yes. But, based on the discussions it seems like JSEP would define what you suggest should be done in BUNDLE. Regards, Christer From nobody Tue Oct 4 05:23:36 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60BF12983B for ; Tue, 4 Oct 2016 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 nCua9zHQ1PH7 for ; Tue, 4 Oct 2016 05:23:34 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D46129835 for ; Tue, 4 Oct 2016 05:23:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 722047CAD7E; Tue, 4 Oct 2016 14:23:32 +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 C8e9aMVGOM9z; Tue, 4 Oct 2016 14:23:31 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805] (unknown [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805]) by mork.alvestrand.no (Postfix) with ESMTPSA id 998C77CAD7C; Tue, 4 Oct 2016 14:23:31 +0200 (CEST) To: Christer Holmberg , Colin Perkins References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> From: Harald Alvestrand Message-ID: <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> Date: Tue, 4 Oct 2016 14:23:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:23:36 -0000 Den 04. okt. 2016 14:00, skrev Christer Holmberg: > Hi, > > I still question why the low-level RTP demuxing shall be described in > JSEP, instead of e.g., BUNDLE. > > Keep in mind that all BUNDLE implementations may not implement JSEP, but I > still think we want the RTP demuxing to be done in the same way? Does BUNDLE say how to handle RID? Seriously, please get BUNDLE out the door and don't tangle it in any more new stuff. From nobody Tue Oct 4 05:29:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8947912983E for ; Tue, 4 Oct 2016 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8NHH_iD8urE for ; Tue, 4 Oct 2016 05:29: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 38D6912983C for ; Tue, 4 Oct 2016 05:29:11 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-44-57f3a094c93e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id F1.4A.02458.490A3F75; Tue, 4 Oct 2016 14:29:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Tue, 4 Oct 2016 14:29:07 +0200 From: Christer Holmberg To: Harald Alvestrand , Colin Perkins Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCABLS/gIAAB1yAgAAFnACADLXmgIAAOXmA///SXACAADWZAA== Date: Tue, 4 Oct 2016 12:29:07 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> In-Reply-To: <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2427295338216D47A089BF4B3554BE54@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7iO7UBZ/DDX4fVbNY/vIEo8Wxvi42 i7X/2tkdmD2uTLjC6jHt/n02jyVLfjIFMEdx2aSk5mSWpRbp2yVwZbzfcJyt4DBLxeWLn5kb GPcxdzFyckgImEjc2X2TvYuRi0NIYD2jxJfdU9ggnEWMEgfvTQbKcHCwCVhIdP/TBmkQEQiU 2L2qkR3EZhZQl7iz+ByYLSxgILGw7StYuYiAoURXnzxEeZ1Ey6IjrCA2i4CKxOZp11lAbF4B a4mP7++C2UICE1gllv9wBbE5BRwlls15AlbPKCAm8f3UGiaIVeISt57MZ4K4WUBiyZ7zUPeL Srx8/A+sXlRAT+L719lQcUWJnWfbmSF6DSTen5sPZVtLbDz1A8rWlli28DUzxD2CEidnPmGZ wCg+C8m6WUjaZyFpn4WkfRaS9gWMrKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAiPw4Jbf VjsYDz53PMQowMGoxMObkPIpXIg1say4MvcQowQHs5IIb/e8z+FCvCmJlVWpRfnxRaU5qcWH GKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MEbwmCRnGR74r8PcwpV+fGKGpNux8FMH c5auLVk2rVxTN8tDe0Fb/Len9TcVVOYqhL5t/1UdKRe/aYq35d/9XGe5tyaluqqWpHAzuLmn 5vP/vOPQ6sCUuluiTOanv/0uno0GfdbcJv58lufca5gPrZz41cTz9JPWTX0ql9jsT96WuHiq bp+OEktxRqKhFnNRcSIAzUrNQrwCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 12:29:12 -0000 Hi, >>I still question why the low-level RTP demuxing shall be described in >> JSEP, instead of e.g., BUNDLE. >>=20 >> Keep in mind that all BUNDLE implementations may not implement JSEP, >>but I >> still think we want the RTP demuxing to be done in the same way? > >Does BUNDLE say how to handle RID? No. Cullen wanted more text, though, but I am not sure whether that covered RID. >Seriously, please get BUNDLE out the door and don't tangle it in any >more new stuff. If that was meant to me, I will pretend I didn=B9t see it=8A Regards, Christer From nobody Tue Oct 4 06:05:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2F129851 for ; Tue, 4 Oct 2016 06:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 LX0tXG_U9YAP for ; Tue, 4 Oct 2016 06:05:42 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D38112984D for ; Tue, 4 Oct 2016 06:05:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 354657C0023; Tue, 4 Oct 2016 15:05:40 +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 tRKw0XDL20kf; Tue, 4 Oct 2016 15:05:39 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805] (unknown [IPv6:2001:470:de0a:1:e132:a5b6:9a7c:d805]) by mork.alvestrand.no (Postfix) with ESMTPSA id 57E4D7C001C; Tue, 4 Oct 2016 15:05:39 +0200 (CEST) To: Christer Holmberg , Colin Perkins References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> From: Harald Alvestrand Message-ID: Date: Tue, 4 Oct 2016 15:05:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:05:43 -0000 Den 04. okt. 2016 14:29, skrev Christer Holmberg: > Hi, > >>> I still question why the low-level RTP demuxing shall be described in >>> JSEP, instead of e.g., BUNDLE. >>> >>> Keep in mind that all BUNDLE implementations may not implement JSEP, >>> but I >>> still think we want the RTP demuxing to be done in the same way? >> >> Does BUNDLE say how to handle RID? > > No. Cullen wanted more text, though, but I am not sure whether that > covered RID. > >> Seriously, please get BUNDLE out the door and don't tangle it in any >> more new stuff. > > If that was meant to me, I will pretend I didn¹t see itŠ It's actually a grave concern of mine - more addressed to the chairs of the relevant WGs than to anyone else. Any open document is a magnet for new functionality, and any new functionality delays the document's publication. The bundle document, with its associated changes in registration procedures for SDP attributes (the mux category), needs to be seen as stable. RFC publication is the best way to make it so. Datatracker says we've been working on this document since 2011. It's now at version -32, and was in state "Minor updates needed to address WGLC comments" in May. If we can segregate new requests for functionality into other documents, I think that is a win. Harald From nobody Tue Oct 4 06:43:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADF6129855 for ; Tue, 4 Oct 2016 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9aO-iCEkuil for ; Tue, 4 Oct 2016 06:43:47 -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 119FE1288B8 for ; Tue, 4 Oct 2016 06:43:46 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-9e-57f3b20f0af9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 2D.9A.02458.F02B3F75; Tue, 4 Oct 2016 15:43:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 15:43:43 +0200 From: Christer Holmberg To: Harald Alvestrand , Colin Perkins Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCABLS/gIAAB1yAgAAFnACADLXmgIAAOXmA///SXACAADWZAP//1iwAgAA+rAA= Date: Tue, 4 Oct 2016 13:43:43 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <1B0B245F5CFFDF408B3D14F95A4EA551@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7iq7gps/hBrefylssf3mC0eJYXxeb xdp/7ewOzB5XJlxh9Zh2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4Mt6/289ScE2i4uF0tgbG FokuRg4OCQETiRdvA7oYuTiEBNYzSsy7cJEZwlnEKLH4wyUWkCI2AQuJ7n/aXYycHCICgRK7 VzWyg9jMAuoSdxafA7OFBQwkFrZ9ZQcpFxEwlOjqkwcZIyLQxSjx4/FBZpAaFgEViW/3vzKB 1PAKWEusbeUFCQsJ/GSV2HOlEsTmFHCUWLylhQ3EZhQQk/h+ag0TxCpxiVtP5oPZEgICEkv2 nGeGsEUlXj7+xwpiiwroSXz/Ohsqrijx8dU+RpBVzAKaEut36UOY1hItG7ggJipKTOl+CHY8 r4CgxMmZT1gmMIrPQrJsFkLzLITmWUiaZyFpXsDIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1 ZBMjMOoObvlttYPx4HPHQ4wCHIxKPLwJKZ/ChVgTy4orcw8xSnAwK4nwZm/4HC7Em5JYWZVa lB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD48x3M/6qOmzgV+kQEvmb Mi3nfunS+Vej2AxDNl394cmx6i1TrMuMN/6+Har79WZJL7npxSGhNufm5FXs4tNm3EnccU53 9osfBi0Ttj/VYr5m/v277dTAtI+a+T1mn9l+vQuvd3vUrmR+L153/Q1emzWz0kuXvi3T/C6x RnBNX5DBbaVvG9/826DEUpyRaKjFXFScCAC2cVratgIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:43:49 -0000 SGksDQoNCj4+Pj5JIHN0aWxsIHF1ZXN0aW9uIHdoeSB0aGUgbG93LWxldmVsIFJUUCBkZW11eGlu ZyBzaGFsbCBiZSBkZXNjcmliZWQgaW4NCj4+Pj4gSlNFUCwgaW5zdGVhZCBvZiBlLmcuLCBCVU5E TEUuDQo+Pj4+DQo+Pj4+IEtlZXAgaW4gbWluZCB0aGF0IGFsbCBCVU5ETEUgaW1wbGVtZW50YXRp b25zIG1heSBub3QgaW1wbGVtZW50IEpTRVAsDQo+Pj4+IGJ1dCBJDQo+Pj4+IHN0aWxsIHRoaW5r IHdlIHdhbnQgdGhlIFJUUCBkZW11eGluZyB0byBiZSBkb25lIGluIHRoZSBzYW1lIHdheT8NCj4+ Pg0KPj4+IERvZXMgQlVORExFIHNheSBob3cgdG8gaGFuZGxlIFJJRD8NCj4+IA0KPj4gTm8uIEN1 bGxlbiB3YW50ZWQgbW9yZSB0ZXh0LCB0aG91Z2gsIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIg dGhhdA0KPj4gY292ZXJlZCBSSUQuDQo+PiANCj4+PiBTZXJpb3VzbHksIHBsZWFzZSBnZXQgQlVO RExFIG91dCB0aGUgZG9vciBhbmQgZG9uJ3QgdGFuZ2xlIGl0IGluIGFueQ0KPj4+IG1vcmUgbmV3 IHN0dWZmLg0KPj4gDQo+PiBJZiB0aGF0IHdhcyBtZWFudCB0byBtZSwgSSB3aWxsIHByZXRlbmQg SSBkaWRuwrl0IHNlZSBpdMWgDQo+DQo+SXQncyBhY3R1YWxseSBhIGdyYXZlIGNvbmNlcm4gb2Yg bWluZSAtIG1vcmUgYWRkcmVzc2VkIHRvIHRoZSBjaGFpcnMgb2YNCj50aGUgcmVsZXZhbnQgV0dz IHRoYW4gdG8gYW55b25lIGVsc2UuDQo+DQo+QW55IG9wZW4gZG9jdW1lbnQgaXMgYSBtYWduZXQg Zm9yIG5ldyBmdW5jdGlvbmFsaXR5LCBhbmQgYW55IG5ldw0KPmZ1bmN0aW9uYWxpdHkgZGVsYXlz IHRoZSBkb2N1bWVudCdzIHB1YmxpY2F0aW9uLg0KPg0KPlRoZSBidW5kbGUgZG9jdW1lbnQsIHdp dGggaXRzIGFzc29jaWF0ZWQgY2hhbmdlcyBpbiByZWdpc3RyYXRpb24NCj5wcm9jZWR1cmVzIGZv ciBTRFAgYXR0cmlidXRlcyAodGhlIG11eCBjYXRlZ29yeSksIG5lZWRzIHRvIGJlIHNlZW4gYXMN Cj5zdGFibGUuIFJGQyBwdWJsaWNhdGlvbiBpcyB0aGUgYmVzdCB3YXkgdG8gbWFrZSBpdCBzby4N Cj4NCj5EYXRhdHJhY2tlciBzYXlzIHdlJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGRvY3VtZW50 IHNpbmNlIDIwMTEuIEl0J3MNCj5ub3cgYXQgdmVyc2lvbiAtMzIsIGFuZCB3YXMgaW4gc3RhdGUg Ik1pbm9yIHVwZGF0ZXMgbmVlZGVkIHRvIGFkZHJlc3MNCj5XR0xDIGNvbW1lbnRzIiBpbiBNYXku DQo+DQo+SWYgd2UgY2FuIHNlZ3JlZ2F0ZSBuZXcgcmVxdWVzdHMgZm9yIGZ1bmN0aW9uYWxpdHkg aW50byBvdGhlciBkb2N1bWVudHMsDQo+SSB0aGluayB0aGF0IGlzIGEgd2luLg0KDQpJdOKAmXMg bm90IHRoZSBhZGRpdGlvbiBvZiBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0IGhhcyBjYXVzZWQgdGhl IGRlbGF5Lg0KV2hlbmV2ZXIgd2XigJl2ZSBkZWNpZGVkIHRvIGFkZCBzb21lIG5ldyBmdW5jdGlv bmFsaXR5LCB0aGUgcHJvY2VzcyBoYXMgYmVlbg0KcmF0aGVyIGZhc3QgYW5kIHNtb290aCAtIHRo YW5rcyB0byBldmVyeW9uZSB3aG8gaGF2ZSBwcm92aWRlZCB0ZXh0IGFuZA0KaW5wdXQuDQoNCldo YXQgaXMgY2F1c2luZyB0aGUgZGVsYXkgaXMgdGhlIG5ldmVyLWVuZGluZyByZXF1ZXN0cyBmb3Ig ZWRpdG9yaWFsDQpjaGFuZ2VzIChtYW55IG9mIHdoaWNoIGFyZSBub3QgZG9uZSB1c2luZyBhIHNp bXBsZSBzZWFyY2gvcmVwbGFjZSAtIHRoZXkNCm9mdGVuIHJlcXVpcmUgd2lkZXIgcmUtd3JpdGlu Zy9zdHJ1Y3R1cmluZykuIFdoZW5ldmVyIHBlcnNvbiBYIGhhcw0KcHJvdmlkZWQgY29tbWVudHMs IGFuZCBJ4oCZdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQsIHBlcnNvbiBZIHdhbnRzIHNvbWV0aGlu Zw0KZWxzZS4gSXQgd291bGQgaGF2ZSBiZWVuIG11Y2ggZWFzaWVyIGlmIHBlcnNvbiBZIHdvdWxk IGhhdmUgZ2l2ZW4gaGlzL2hlcg0KY29tbWVudHMgd2hlbiBwZXJzb24gWCBkaWQsIGFuZCB0aGVu IHdlIGNvdWxkIGhhdmUgZGlzY3Vzc2VkIGFuZCB0cmllZCB0bw0KZmluZCBzb21ldGhpbmcgdGhh dCBib3RoIFggYW5kIFkgYXJlIGhhcHB5IHdpdGguDQoNCk5vdGUgdGhhdCBJIEFNIHZlcnkgdGhh bmtmdWwgdGhhdCBwZW9wbGUgRE8gcmV2aWV3IHRoZSBkb2N1bWVudCAod2UgbmVlZA0KbW9yZSBv ZiB0aGF0KSwgYW5kIG1vc3Qgb2YgdGhlIGNvbW1lbnRzIGFyZSByZWFsbHkgZ29vZCwgYnV0IGJ5 IHVzaW5nIHRoZQ0KY3VycmVudCDigJxwcm9jZXNz4oCdIHdl4oCZbGwgbmV2ZXIgYmUgcmVhZHku IEFueXdheSwgSSB0aGluayB0aGF0IGRpc2N1c3Npb24NCmJlbG9uZ3MgdG8gTU1VU0lDLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KIA0KDQo= From nobody Tue Oct 4 07:51:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC59E1298B4; Tue, 4 Oct 2016 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] 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 idUsX9D2d4ju; Tue, 4 Oct 2016 07:51:51 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 76CCE1298B3; Tue, 4 Oct 2016 07:51:51 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1brR4O-0003XR-KY; Tue, 04 Oct 2016 16:51:48 +0200 Received: from ppp-94-66-14-119.home.otenet.gr ([94.66.14.119] helo=[192.168.32.102]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1brR4N-0005qK-Gf; Tue, 04 Oct 2016 16:51:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Tue, 4 Oct 2016 17:46:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> To: Harald Alvestrand X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 46905 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 331C1767A3713643C0C06A7EDB926FA907D357FF X-UiO-SPAM-Test: remote_host: 94.66.14.119 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , Mirja Kuehlewind , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 14:51:56 -0000 thanks! i agree with this update Sent from my iPhone > On 4. okt. 2016, at 10.35, Harald Alvestrand wrote:= >=20 > After listening to the (silent) list and considering the matter further, > I'm adding the following paragraph at the end of the "local > prioritization" section: >=20 > Note that this specification doesn't dictate when disparate streams > are to be "congestion controlled under the same congestion control > regime". The issue of coupling congestion controllers is explored > further in > [I-D.ietf-rmcat-coupled-cc]. >=20 > and adding that as an informational reference. >=20 >=20 > Den 30. sep. 2016 14:28, skrev Michael Welzl: >>=20 >>> On 30. sep. 2016, at 12.59, Harald Alvestrand wro= te: >>>=20 >>> Den 30. sep. 2016 12:31, skrev Michael Welzl: >>>>=20 >>>>> On 30. sep. 2016, at 11.41, Harald Alvestrand w= rote: >>>>>=20 >>>>> Wanting to ask .... >>>>>=20 >>>>> do you have commitment from some of the browser vendors that they inte= nd >>>>> to add -coupled to their congestion control code? >>>>=20 >>>> No committment, but I did have some hope that you guys at Google would b= e interested? >>>> Stefan was interested in coupling the data channel with the media chann= el, which is probably a straightforward way of adapting our coupling algorit= hm. >>>>=20 >>>> We=E2=80=99re going to work on this code ourselves; we already have pre= liminary code on coupling + shared bottleneck detection in Chromium, but thi= s is work in progress that was interrupted for a year due to a contract that= let us focus on coupling TCP for a while (which also works very well, BTW; w= e=E2=80=99ll provide an update at ICCRG in Seoul). So we=E2=80=99re (well: S= afiqul is) just about to get back to it. >>>>=20 >>>>=20 >>>>> That would go a long way towards allaying my fear that this would be >>>>> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. >>>>=20 >>>> I think what I=E2=80=99m asking for is a far cry from a MUST. >>>> It=E2=80=99s merely about putting a reference there such that implement= ers see both possibilities (coupling and/or dscp), not only one (dscp). >>>=20 >>> The DSCP section would be the wrong section for it anyway. >>>=20 >>> References to -coupled should be in the "local prioritization" section >>> (4.1). >>=20 >> I agree. I didn=E2=80=99t mean for this to be in the same section. >>=20 >>=20 >>> My worry about -coupled in the previous round is that it's a *specific* >>> instance of coupled congestion controllers (and experimental-track). >>>=20 >>> We don't yet know if it's *the* way. >>=20 >> Understood - but: >>=20 >> 1) draft-ietf-rmcat-coupled-cc doesn=E2=80=99t say that the algorithm in i= t is *the* way. I believe it correctly acknowledges that you could e.g. also= have a single congestion control instance for everything ("congestion manag= er=E2=80=9D style coupling). Both implementations have their pro=E2=80=99s a= nd con=E2=80=99s - our algorithm is easier in some ways, e.g. for turning on= and off (which is useful when coupling flows to multiple destinations). >>=20 >>=20 >> 2) as I said, we have lots of indications that this algorithm works for *= many* controllers with only minimal changes. >>=20 >> Some details: >> We successfully used it with NADA and GCC ( http://heim.ifi.uio.no/michaw= e/research/publications/noms2016.pdf ), but also TFRC and RAP ( http://heim= .ifi.uio.no/michawe/research/publications/csws14.pdf ), LEDBAT ( slide 31: h= ttp://heim.ifi.uio.no/michawe/research/publications/caia2014.pdf ), also LED= BAT combined with another congestion control (don=E2=80=99t remember which, m= aybe RAP), and most recently TCP. TCP is perhaps an extreme case because it h= as so many states. If you ignore all this and just blindly apply our algorit= hm, you get pretty much the behavior of E-TCP, which isn=E2=80=99t bad ( htt= p://www.isi.edu/div7/publication_files/effects_of_ensemble.pdf ). We have im= proved on it by correctly incorporating the states - this makes things bette= r, but note that all of this is better than simply leaving flows as they are= and let them compete against each other, in particular when the goal is to m= inimize latency. >>=20 >>=20 >> I=E2=80=99d find it pretty strange if this isn=E2=80=99t enough reason to= justify a mention of this possibility and a reference. >>=20 >>=20 >>> That said, I personally wouldn't worry too much about mentioning it, but= >>> it's a post-IESG change without IESG buy-in, so I'll want more >>> authorization to do that. >>=20 >> Sure >>=20 >> cheers, >> Michael >>=20 From nobody Tue Oct 4 14:58:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DFE1294F5 for ; Tue, 4 Oct 2016 14:58:38 -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 nOMMdtD9jaVS for ; Tue, 4 Oct 2016 14:58:35 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7006129439 for ; Tue, 4 Oct 2016 14:58:35 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id u68so52129078uau.2 for ; Tue, 04 Oct 2016 14:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HbYPi7HUfrP/5H2EIW4Ejv9z2iH97qNP1FKqP+B+J30=; b=NI2MxNa71hcPQflv+PEP7wny2VYl/6HynqkTidz92Noxk8fKkS+jCPKPEPx3iiY+Qn V/Doqb81sFA66f+VzeU15KN5w/GWS09o4jIFmZQPi7PFxcXfgz2PAk3AfrdNYs1ksjfs 2EXixWnSyP+wjU7gIxiCGL1Zwi/2W+abDJ5Y2kh+qCtXAxwLpHjAnHZlbU0PP30ST8R9 ftEbXP/xxWQ6HVL3+aVu/knRR8splfIZ6/dhHwh7cOe0KGex9H+bxkqrrjBJyRZ5ar+/ vTerRbkELNsSteV8Vt2RF1nhq6uZPgemqWgmyR0NMAPW1uMMEyClCN2+HcozJmLzxXbm 9QIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HbYPi7HUfrP/5H2EIW4Ejv9z2iH97qNP1FKqP+B+J30=; b=WKFZYnzMFOOBsZeUzQz0ER5NcNswO0917k9y4yJPcJHLR+dzpnh6IIT5TQl/xqY5tl ZPLT98fkoBjH8HGjFCetuJyVgRrH1YVvqcLwKd5FQi7FDXCnjb8QWQ3YcBzCMmq4iziI 0ro/i0mMTaRUQtzoLvyh4vn18xCLJB+QpXAOHefEEnYRWb+xNMjBx2mwy106UlFFY0bu kJs6z2JiG3SqML5sqUqXu1uTeKDhTLky0vvgUb6nQQ4DZvMnjJoGz9ExusnOoYCCC4IS SfZHxOaz2bM7L980JC9fnF6qgkiB8JUtLIIRbjxNdRPLxemiNBygFNgX1Iycwc2dm3so xSCQ== X-Gm-Message-State: AA6/9RmoNOtjwDjlSFLdSeYGAFBTbbJ76Ah5s8UJlifCs7WeuYuDaN4IGnNs+yHjR/4jIVttReijytPcaLi8og== X-Received: by 10.159.48.194 with SMTP id k2mr4077841uab.2.1475618314748; Tue, 04 Oct 2016 14:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.101 with HTTP; Tue, 4 Oct 2016 14:58:14 -0700 (PDT) In-Reply-To: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> From: Bernard Aboba Date: Tue, 4 Oct 2016 14:58:14 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f403045e329c79880e053e112986 Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 21:58:38 -0000 --f403045e329c79880e053e112986 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Harald said: "If we can segregate new requests for functionality into other documents, I think that is a win." [BA] In general, I agree with Harald. However, there is one issue that I do think that BUNDLE needs to address, which is what happens when there are non-unique PTs. JSEP Section 7 says: "If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m=3D section appears earliest in the local description." While this is one way of handling it, there are implementations that have solved the problem in a different way. For example, I believe that ORTC Lib maps to the RtpReceiver whose m=3D section contains no specified SSRCs. At this point, I do not feel strongly about *which* solution is chosen, but since we have multiple non-interoperable BUNDLE implementations, I would like the BUNDLE draft to add a sentence choosing one approach, which can be referenced in JSEP Section 7. On Tue, Oct 4, 2016 at 6:05 AM, Harald Alvestrand wrote: > Den 04. okt. 2016 14:29, skrev Christer Holmberg: > > Hi, > > > >>> I still question why the low-level RTP demuxing shall be described in > >>> JSEP, instead of e.g., BUNDLE. > >>> > >>> Keep in mind that all BUNDLE implementations may not implement JSEP, > >>> but I > >>> still think we want the RTP demuxing to be done in the same way? > >> > >> Does BUNDLE say how to handle RID? > > > > No. Cullen wanted more text, though, but I am not sure whether that > > covered RID. > > > >> Seriously, please get BUNDLE out the door and don't tangle it in any > >> more new stuff. > > > > If that was meant to me, I will pretend I didn=C2=B9t see it=C5=A0 > > It's actually a grave concern of mine - more addressed to the chairs of > the relevant WGs than to anyone else. > > Any open document is a magnet for new functionality, and any new > functionality delays the document's publication. > > The bundle document, with its associated changes in registration > procedures for SDP attributes (the mux category), needs to be seen as > stable. RFC publication is the best way to make it so. > > Datatracker says we've been working on this document since 2011. It's > now at version -32, and was in state "Minor updates needed to address > WGLC comments" in May. > > If we can segregate new requests for functionality into other documents, > I think that is a win. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403045e329c79880e053e112986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Harald said:=C2=A0

"If we can segregate new requests for functionality into = other documents,
I think = that is a win."

[BA] In general, I agr= ee with Harald.=C2=A0 However, there is one issue that I do think that BUND= LE needs to address, which is what happens when there are non-unique PTs.= =C2=A0 JSEP Section 7 says:=C2=A0

      "If any payload type could map to more than one Rtp=
Receiver, map to
      the RtpReceiver whose m=3D section appears earliest in the local=C2=
=A0description."


=
While this is one way of handling it, there are im=
plementations that have solved the problem in a different way.=C2=A0 For ex=
ample, I believe that ORTC Lib maps to the RtpReceiver whose m=3D section c=
ontains no specified SSRCs.=C2=A0

At this point, I do not feel strongly ab=
out *which* solution is chosen, but since we have multiple non-interoperabl=
e BUNDLE implementations, I would like the BUNDLE draft to add a sentence c=
hoosing one approach, which can be referenced in JSEP Section 7.=C2=A0

On = Tue, Oct 4, 2016 at 6:05 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Den = 04. okt. 2016 14:29, skrev Christer Holmberg:
> Hi,
>
>>> I still question why the low-level RTP demuxing shall be descr= ibed in
>>> JSEP, instead of e.g., BUNDLE.
>>>
>>> Keep in mind that all BUNDLE implementations may not implement= JSEP,
>>> but I
>>> still think we want the RTP demuxing to be done in the same wa= y?
>>
>> Does BUNDLE say how to handle RID?
>
> No. Cullen wanted more text, though, but I am not sure whether that > covered RID.
>
>> Seriously, please get BUNDLE out the door and don't tangle it = in any
>> more new stuff.
>
> If that was meant to me, I will pretend I didn=C2=B9t see it=C5=A0

It's actually a grave concern of mine - more addressed to the ch= airs of
the relevant WGs than to anyone else.

Any open document is a magnet for new functionality, and any new
functionality delays the document's publication.

The bundle document, with its associated changes in registration
procedures for SDP attributes (the mux category), needs to be seen as
stable. RFC publication is the best way to make it so.

Datatracker says we've been working on this document since 2011. It'= ;s
now at version -32, and was in state "Minor updates needed to address<= br> WGLC comments" in May.

If we can segregate new requests for functionality into other documents, I think that is a win.

Harald

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

--f403045e329c79880e053e112986-- From nobody Wed Oct 5 01:18:38 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075181293EE for ; Wed, 5 Oct 2016 01:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cndfgcc4mbAC for ; Wed, 5 Oct 2016 01:18:35 -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 D61DC127A91 for ; Wed, 5 Oct 2016 01:18:34 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-06-57f4b759021a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 85.CF.31035.957B4F75; Wed, 5 Oct 2016 10:18:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 10:18:08 +0200 From: Christer Holmberg To: Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCABLS/gIAAB1yAgAAFnACADLXmgIAAOXmA///SXACAADWZAP//1iwAgACUzwCAAOE7AA== Date: Wed, 5 Oct 2016 08:18:08 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> <46F5ACCF-8701-41F1-A8A4-85796EFF9B07@csperkins.org> <00d7ff8e-e6dc-7231-334f-833af1727cd7@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D41A9339106EAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7t27k9i/hBsvvClhs2Pef2WL5yxOM Fsf6utgs1v5rZ3dg8bgy4Qqrx7T799k8ds66y+6xZMlPpgCWKC6blNSczLLUIn27BK6MD5t/ shSsy6r4s/MlawPjzvQuRk4OCQETicVvmpi6GLk4hATWM0rMOPSWBcJZxChxfdE89i5GDg42 AQuJ7n/aIA0iAuES79ufsYDYzAJeEs937mAEsYUFDCQWtn0FKxcRMJTo6pMHGSMiMIlR4ljH RzaQGhYBFYmfk66wg9i8AtYSM7e1Qi0+wCbR/uMNWBGnQKDEwmfnwIoYBcQkvp9awwSxTFzi 1pP5TBBXC0gs2XOeGcIWlXj5+B8riC0qoCfx/etsZpAjJASUJKZtTQMxmQUSJFbN44FYKyhx cuYTlgmMorOQDJ2FUDULSRVEWFNi/S59iGpFiSndD9khbA2J1jlzoWxriUVfX7Ihq1nAyLGK UbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBSD275rbqD8fIbx0OMAhyMSjy8D7Z+DhdiTSwr rsw9xCjBwawkwuuw7Uu4EG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KL YLJMHJxSDYwyDMdmRphrNC34EKe+LTPyA7ts3OMTVsqz+jabrbG0Pim6/v7FluniSy9t3BU0 Z0bPR6tvL6ZbPYyRl2fPvvsyryHPWbdF2DQ0a7+gY+XM82cm2HZ9/vK96qJhyuk5+mLVazf8 KbUPmjrn9xG2F/dYGp+yaElx65zujahSqHvuJGbxofaF5SolluKMREMt5qLiRACvGJ9G0AIA AA== Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 08:18:38 -0000 --_000_D41A9339106EAchristerholmbergericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxzbyB3YW50IHRvIHBvaW50IG91dCB0aGF0IEJVTkRMRSBhbHJlYWR5IGhhdmUg YSBzZWN0aW9uIG9uIGhvdyB0byBkZW11eCBSVFAsIHNvIGl04oCZcyBub3QgY29tcGxldGVseSBu ZXcgZnVuY3Rpb25hbGl0eSDigJMgaXTigJlzIHRvIG1ha2Ugc3VyZSB0aGUgZXhpc3RpbmcgZnVu Y3Rpb25hbGl0eSBpcyBjb3JyZWN0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBC ZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5IDUgT2N0b2JlciAyMDE2IGF0IDAwOjU4DQpU bzogSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRA YWx2ZXN0cmFuZC5ubz4+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4sIENv bGluIFBlcmtpbnMgPGNzcEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz4+ LCAicnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IiA8cnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEpTRVA6 IFJUUCBkZW11eCBhbGdvcml0aG1zDQoNCkhhcmFsZCBzYWlkOg0KDQoiSWYgd2UgY2FuIHNlZ3Jl Z2F0ZSBuZXcgcmVxdWVzdHMgZm9yIGZ1bmN0aW9uYWxpdHkgaW50byBvdGhlciBkb2N1bWVudHMs DQpJIHRoaW5rIHRoYXQgaXMgYSB3aW4uIg0KDQpbQkFdIEluIGdlbmVyYWwsIEkgYWdyZWUgd2l0 aCBIYXJhbGQuICBIb3dldmVyLCB0aGVyZSBpcyBvbmUgaXNzdWUgdGhhdCBJIGRvIHRoaW5rIHRo YXQgQlVORExFIG5lZWRzIHRvIGFkZHJlc3MsIHdoaWNoIGlzIHdoYXQgaGFwcGVucyB3aGVuIHRo ZXJlIGFyZSBub24tdW5pcXVlIFBUcy4gIEpTRVAgU2VjdGlvbiA3IHNheXM6DQoNCg0KICAgICAg IklmIGFueSBwYXlsb2FkIHR5cGUgY291bGQgbWFwIHRvIG1vcmUgdGhhbiBvbmUgUnRwUmVjZWl2 ZXIsIG1hcCB0bw0KICAgICAgdGhlIFJ0cFJlY2VpdmVyIHdob3NlIG09IHNlY3Rpb24gYXBwZWFy cyBlYXJsaWVzdCBpbiB0aGUgbG9jYWwgZGVzY3JpcHRpb24uIg0KDQoNCg0KV2hpbGUgdGhpcyBp cyBvbmUgd2F5IG9mIGhhbmRsaW5nIGl0LCB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQg aGF2ZSBzb2x2ZWQgdGhlIHByb2JsZW0gaW4gYSBkaWZmZXJlbnQgd2F5LiAgRm9yIGV4YW1wbGUs IEkgYmVsaWV2ZSB0aGF0IE9SVEMgTGliIG1hcHMgdG8gdGhlIFJ0cFJlY2VpdmVyIHdob3NlIG09 IHNlY3Rpb24gY29udGFpbnMgbm8gc3BlY2lmaWVkIFNTUkNzLg0KDQoNCkF0IHRoaXMgcG9pbnQs IEkgZG8gbm90IGZlZWwgc3Ryb25nbHkgYWJvdXQgKndoaWNoKiBzb2x1dGlvbiBpcyBjaG9zZW4s IGJ1dCBzaW5jZSB3ZSBoYXZlIG11bHRpcGxlIG5vbi1pbnRlcm9wZXJhYmxlIEJVTkRMRSBpbXBs ZW1lbnRhdGlvbnMsIEkgd291bGQgbGlrZSB0aGUgQlVORExFIGRyYWZ0IHRvIGFkZCBhIHNlbnRl bmNlIGNob29zaW5nIG9uZSBhcHByb2FjaCwgd2hpY2ggY2FuIGJlIHJlZmVyZW5jZWQgaW4gSlNF UCBTZWN0aW9uIDcuDQoNCk9uIFR1ZSwgT2N0IDQsIDIwMTYgYXQgNjowNSBBTSwgSGFyYWxkIEFs dmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5u bz4+IHdyb3RlOg0KRGVuIDA0LiBva3QuIDIwMTYgMTQ6MjksIHNrcmV2IENocmlzdGVyIEhvbG1i ZXJnOg0KPiBIaSwNCj4NCj4+PiBJIHN0aWxsIHF1ZXN0aW9uIHdoeSB0aGUgbG93LWxldmVsIFJU UCBkZW11eGluZyBzaGFsbCBiZSBkZXNjcmliZWQgaW4NCj4+PiBKU0VQLCBpbnN0ZWFkIG9mIGUu Zy4sIEJVTkRMRS4NCj4+Pg0KPj4+IEtlZXAgaW4gbWluZCB0aGF0IGFsbCBCVU5ETEUgaW1wbGVt ZW50YXRpb25zIG1heSBub3QgaW1wbGVtZW50IEpTRVAsDQo+Pj4gYnV0IEkNCj4+PiBzdGlsbCB0 aGluayB3ZSB3YW50IHRoZSBSVFAgZGVtdXhpbmcgdG8gYmUgZG9uZSBpbiB0aGUgc2FtZSB3YXk/ DQo+Pg0KPj4gRG9lcyBCVU5ETEUgc2F5IGhvdyB0byBoYW5kbGUgUklEPw0KPg0KPiBOby4gQ3Vs bGVuIHdhbnRlZCBtb3JlIHRleHQsIHRob3VnaCwgYnV0IEkgYW0gbm90IHN1cmUgd2hldGhlciB0 aGF0DQo+IGNvdmVyZWQgUklELg0KPg0KPj4gU2VyaW91c2x5LCBwbGVhc2UgZ2V0IEJVTkRMRSBv dXQgdGhlIGRvb3IgYW5kIGRvbid0IHRhbmdsZSBpdCBpbiBhbnkNCj4+IG1vcmUgbmV3IHN0dWZm Lg0KPg0KPiBJZiB0aGF0IHdhcyBtZWFudCB0byBtZSwgSSB3aWxsIHByZXRlbmQgSSBkaWRuwrl0 IHNlZSBpdMWgDQoNCkl0J3MgYWN0dWFsbHkgYSBncmF2ZSBjb25jZXJuIG9mIG1pbmUgLSBtb3Jl IGFkZHJlc3NlZCB0byB0aGUgY2hhaXJzIG9mDQp0aGUgcmVsZXZhbnQgV0dzIHRoYW4gdG8gYW55 b25lIGVsc2UuDQoNCkFueSBvcGVuIGRvY3VtZW50IGlzIGEgbWFnbmV0IGZvciBuZXcgZnVuY3Rp b25hbGl0eSwgYW5kIGFueSBuZXcNCmZ1bmN0aW9uYWxpdHkgZGVsYXlzIHRoZSBkb2N1bWVudCdz IHB1YmxpY2F0aW9uLg0KDQpUaGUgYnVuZGxlIGRvY3VtZW50LCB3aXRoIGl0cyBhc3NvY2lhdGVk IGNoYW5nZXMgaW4gcmVnaXN0cmF0aW9uDQpwcm9jZWR1cmVzIGZvciBTRFAgYXR0cmlidXRlcyAo dGhlIG11eCBjYXRlZ29yeSksIG5lZWRzIHRvIGJlIHNlZW4gYXMNCnN0YWJsZS4gUkZDIHB1Ymxp Y2F0aW9uIGlzIHRoZSBiZXN0IHdheSB0byBtYWtlIGl0IHNvLg0KDQpEYXRhdHJhY2tlciBzYXlz IHdlJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGRvY3VtZW50IHNpbmNlIDIwMTEuIEl0J3MNCm5v dyBhdCB2ZXJzaW9uIC0zMiwgYW5kIHdhcyBpbiBzdGF0ZSAiTWlub3IgdXBkYXRlcyBuZWVkZWQg dG8gYWRkcmVzcw0KV0dMQyBjb21tZW50cyIgaW4gTWF5Lg0KDQpJZiB3ZSBjYW4gc2VncmVnYXRl IG5ldyByZXF1ZXN0cyBmb3IgZnVuY3Rpb25hbGl0eSBpbnRvIG90aGVyIGRvY3VtZW50cywNCkkg dGhpbmsgdGhhdCBpcyBhIHdpbi4NCg0KSGFyYWxkDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_D41A9339106EAchristerholmbergericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSw8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWxzbyB3YW50IHRvIHBvaW50IG91dCB0aGF0IEJV TkRMRSBhbHJlYWR5IGhhdmUgYSBzZWN0aW9uIG9uIGhvdyB0byBkZW11eCBSVFAsIHNvIGl04oCZ cyBub3QgY29tcGxldGVseSBuZXcgZnVuY3Rpb25hbGl0eSDigJMgaXTigJlzIHRvIG1ha2Ugc3Vy ZSB0aGUgZXhpc3RpbmcgZnVuY3Rpb25hbGl0eSBpcyBjb3JyZWN0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNo cmlzdGVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkJlcm5hcmQgQWJvYmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSI+YmVybmFyZC5hYm9iYUBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+V2VkbmVzZGF5IDUgT2N0b2JlciAyMDE2IGF0IDAwOjU4PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+SGFyYWxkIEFsdmVzdHJhbmQgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVzdHJhbmQubm88 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkNo cmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OywgQ29saW4g UGVya2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnIj5jc3BAY3NwZXJr aW5zLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5y dGN3ZWJAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3J0Y3dlYl0gSlNFUDogUlRQIGRlbXV4IGFs Z29yaXRobXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPkhhcmFsZCBzYWlkOiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ JnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPklmIHdlIGNhbiBzZWdyZWdhdGUg bmV3IHJlcXVlc3RzIGZvciBmdW5jdGlvbmFsaXR5IGludG8gb3RoZXIgZG9jdW1lbnRzLDwvc3Bh bj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPkkgdGhpbmsgdGhh dCBpcyBhIHdpbi48L3NwYW4+JnF1b3Q7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5b QkFdIEluIGdlbmVyYWwsIEkgYWdyZWUgd2l0aCBIYXJhbGQuJm5ic3A7IEhvd2V2ZXIsIHRoZXJl IGlzIG9uZSBpc3N1ZSB0aGF0IEkgZG8gdGhpbmsgdGhhdCBCVU5ETEUgbmVlZHMgdG8gYWRkcmVz cywgd2hpY2ggaXMgd2hhdCBoYXBwZW5zIHdoZW4gdGhlcmUgYXJlIG5vbi11bmlxdWUgUFRzLiZu YnNwOyBKU0VQIFNlY3Rpb24gNyBzYXlzOiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21h cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPiAgICAgICZx dW90O0lmIGFueSBwYXlsb2FkIHR5cGUgY291bGQgbWFwIHRvIG1vcmUgdGhhbiBvbmUgUnRwUmVj ZWl2ZXIsIG1hcCB0bw0KICAgICAgdGhlIFJ0cFJlY2VpdmVyIHdob3NlIG09IHNlY3Rpb24gYXBw ZWFycyBlYXJsaWVzdCBpbiB0aGUgbG9jYWwmbmJzcDtkZXNjcmlwdGlvbi4mcXVvdDs8L3ByZT4N CjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21h cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxicj48L3By ZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4 O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxicj48 L3ByZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMz M3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy aWY7Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+V2hpbGUgdGhpcyBpcyBvbmUg d2F5IG9mIGhhbmRsaW5nIGl0LCB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSBz b2x2ZWQgdGhlIHByb2JsZW0gaW4gYSBkaWZmZXJlbnQgd2F5LiZuYnNwOyBGb3IgZXhhbXBsZSwg SSBiZWxpZXZlIHRoYXQgT1JUQyBMaWIgbWFwcyB0byB0aGUgUnRwUmVjZWl2ZXIgd2hvc2UgbT0g c2VjdGlvbiBjb250YWlucyBubyBzcGVjaWZpZWQgU1NSQ3MuJm5ic3A7PC9zcGFuPjxicj48L3By ZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4 O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+PGJyPjwvc3Bhbj48L3ByZT4NCjxw cmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdp bi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+QXQgdGhpcyBwb2ludCwgSSBkbyBub3QgZmVl bCBzdHJvbmdseSBhYm91dCAqd2hpY2gqIHNvbHV0aW9uIGlzIGNob3NlbiwgYnV0IHNpbmNlIHdl IGhhdmUgbXVsdGlwbGUgbm9uLWludGVyb3BlcmFibGUgQlVORExFIGltcGxlbWVudGF0aW9ucywg SSB3b3VsZCBsaWtlIHRoZSBCVU5ETEUgZHJhZnQgdG8gYWRkIGEgc2VudGVuY2UgY2hvb3Npbmcg b25lIGFwcHJvYWNoLCB3aGljaCBjYW4gYmUgcmVmZXJlbmNlZCBpbiBKU0VQIFNlY3Rpb24gNy4m bmJzcDs8L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBPY3QgNCwgMjAxNiBhdCA2OjA1IEFN LCBIYXJhbGQgQWx2ZXN0cmFuZCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRv OmhhcmFsZEBhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayI+aGFyYWxkQGFsdmVzdHJhbmQu bm88L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8c3BhbiBjbGFzcz0iIj5EZW4gMDQuIG9rdC4gMjAxNiAxNDoy OSwgc2tyZXYgQ2hyaXN0ZXIgSG9sbWJlcmc6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IEkgc3RpbGwgcXVlc3Rpb24gd2h5IHRoZSBsb3ctbGV2ZWwgUlRQIGRlbXV4 aW5nIHNoYWxsIGJlIGRlc2NyaWJlZCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyBKU0VQLCBpbnN0ZWFk IG9mIGUuZy4sIEJVTkRMRS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgS2Vl cCBpbiBtaW5kIHRoYXQgYWxsIEJVTkRMRSBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBpbXBsZW1l bnQgSlNFUCw8YnI+DQomZ3Q7Jmd0OyZndDsgYnV0IEk8YnI+DQomZ3Q7Jmd0OyZndDsgc3RpbGwg dGhpbmsgd2Ugd2FudCB0aGUgUlRQIGRlbXV4aW5nIHRvIGJlIGRvbmUgaW4gdGhlIHNhbWUgd2F5 Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRG9lcyBCVU5ETEUgc2F5IGhvdyB0byBoYW5k bGUgUklEPzxicj4NCiZndDs8YnI+DQomZ3Q7IE5vLiBDdWxsZW4gd2FudGVkIG1vcmUgdGV4dCwg dGhvdWdoLCBidXQgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoYXQ8YnI+DQomZ3Q7IGNvdmVyZWQg UklELjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBTZXJpb3VzbHksIHBsZWFzZSBnZXQgQlVORExF IG91dCB0aGUgZG9vciBhbmQgZG9uJ3QgdGFuZ2xlIGl0IGluIGFueTxicj4NCiZndDsmZ3Q7IG1v cmUgbmV3IHN0dWZmLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHRoYXQgd2FzIG1lYW50IHRvIG1l LCBJIHdpbGwgcHJldGVuZCBJIGRpZG7CuXQgc2VlIGl0xaA8YnI+DQo8YnI+DQo8L3NwYW4+SXQn cyBhY3R1YWxseSBhIGdyYXZlIGNvbmNlcm4gb2YgbWluZSAtIG1vcmUgYWRkcmVzc2VkIHRvIHRo ZSBjaGFpcnMgb2Y8YnI+DQp0aGUgcmVsZXZhbnQgV0dzIHRoYW4gdG8gYW55b25lIGVsc2UuPGJy Pg0KPGJyPg0KQW55IG9wZW4gZG9jdW1lbnQgaXMgYSBtYWduZXQgZm9yIG5ldyBmdW5jdGlvbmFs aXR5LCBhbmQgYW55IG5ldzxicj4NCmZ1bmN0aW9uYWxpdHkgZGVsYXlzIHRoZSBkb2N1bWVudCdz IHB1YmxpY2F0aW9uLjxicj4NCjxicj4NClRoZSBidW5kbGUgZG9jdW1lbnQsIHdpdGggaXRzIGFz c29jaWF0ZWQgY2hhbmdlcyBpbiByZWdpc3RyYXRpb248YnI+DQpwcm9jZWR1cmVzIGZvciBTRFAg YXR0cmlidXRlcyAodGhlIG11eCBjYXRlZ29yeSksIG5lZWRzIHRvIGJlIHNlZW4gYXM8YnI+DQpz dGFibGUuIFJGQyBwdWJsaWNhdGlvbiBpcyB0aGUgYmVzdCB3YXkgdG8gbWFrZSBpdCBzby48YnI+ DQo8YnI+DQpEYXRhdHJhY2tlciBzYXlzIHdlJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGRvY3Vt ZW50IHNpbmNlIDIwMTEuIEl0J3M8YnI+DQpub3cgYXQgdmVyc2lvbiAtMzIsIGFuZCB3YXMgaW4g c3RhdGUgJnF1b3Q7TWlub3IgdXBkYXRlcyBuZWVkZWQgdG8gYWRkcmVzczxicj4NCldHTEMgY29t bWVudHMmcXVvdDsgaW4gTWF5Ljxicj4NCjxicj4NCklmIHdlIGNhbiBzZWdyZWdhdGUgbmV3IHJl cXVlc3RzIGZvciBmdW5jdGlvbmFsaXR5IGludG8gb3RoZXIgZG9jdW1lbnRzLDxicj4NCkkgdGhp bmsgdGhhdCBpcyBhIHdpbi48YnI+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0i Izg4ODg4OCI+PGJyPg0KSGFyYWxkPGJyPg0KPC9mb250Pjwvc3Bhbj4NCjxkaXYgY2xhc3M9IkhP RW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vPHdicj5saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D41A9339106EAchristerholmbergericssoncom_-- From nobody Thu Oct 6 06:55:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0576129523 for ; Thu, 6 Oct 2016 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKGhfUuJpbOU for ; Thu, 6 Oct 2016 06:55:21 -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 6037412964D for ; Thu, 6 Oct 2016 06:55:11 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-2c-57f657bd7d00 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 76.DC.02458.DB756F75; Thu, 6 Oct 2016 15:55:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.319.2; Thu, 6 Oct 2016 15:55:09 +0200 To: "rtcweb@ietf.org" From: Magnus Westerlund Message-ID: Date: Thu, 6 Oct 2016 15:55:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGbFdV3dv+Ldwg/4OE4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfPfRraCLp6KWzdOsDcwPuXsYuTkkBAwkZjd+Zqti5GLQ0hg PaPE7RerWSGcZYwS336cZAapEhFQl7j88AI7iM0mYCFx80cjG4gtLBAscXblFFYQm1fAXuL2 ic1MIDaLgIrEsc0XwWpEBWIkrj97xAZRIyhxcuYTli5GDg5moPoHW8tAwswC8hLNW2eDrRIS 0JZoaOpgncDIOwtJxyyEjllIOhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAycg1t+ W+1gPPjc8RCjAAejEg/vAvuv4UKsiWXFlbmHGCU4mJVEeDnCvoUL8aYkVlalFuXHF5XmpBYf YpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwKh17keHXCDzh20fshSjbk278DPh1RHz Tw11N+UL/+Ynih6ffy/qcYmK+KYvx28vmGNxUXCScrpB9ge1Hbwfbuhd9Et9cEFxd94Mh+M+ ZYrRLAzr1BWXaU1QkgnZbeOoO2G+RcCHxQ+szNoftuRd8rb5cuIB15SGDEnx466XxZls10xy u2iz8YUSS3FGoqEWc1FxIgCrDFxoGAIAAA== Archived-At: Subject: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:55:23 -0000 WG, After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and RID as SDES items that this do exposes labels that previously only have existed in the signalling plane in the media plane. And especially in the RTP header extensions, where even if the media payload is encrypted the header extension is not encrypted. The risk with this is primarily a privacy and fingerprinting risk. And the proposed mitgation is encryption of the RTP header extensions in both the bundle and avtext-rid documents. This leads to the conclusion that for RTCWeb, we must consider to act on these recommendations and decide on which implementation and usage requirement the protection of these field should have. My proposal is that implementation and use of RFC6904 encryption of the RTP header extensions are REQUIRED. For RTCP it is actually unclear if there is mandatory to use encrypted SRTCP. I think it should be required and that can be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch. Opinions? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Oct 6 07:10:09 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C941296B6 for ; Thu, 6 Oct 2016 07:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 HKxxpF6wBWQX for ; Thu, 6 Oct 2016 07:10:05 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 AA96F12969F for ; Thu, 6 Oct 2016 07:09:32 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bs9MY-00085I-Ul; Thu, 06 Oct 2016 16:09:30 +0200 Received: from ppp-94-66-13-227.home.otenet.gr ([94.66.13.227] helo=[192.168.32.95]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bs9MY-0007JM-7N; Thu, 06 Oct 2016 16:09:30 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Thu, 6 Oct 2016 17:09:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3B4EEF3A-AF5E-4DA6-8142-BDE0B6E7E075@ifi.uio.no> References: <147557055077.12851.1347339442333163275.idtracker@ietfa.amsl.com> To: Harald Alvestrand X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 12 sum msgs/h 5 total rcpts 46944 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2360B9ECB9DACF46F1A724CF7435686DE84B506C X-UiO-SPAM-Test: remote_host: 94.66.13.227 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Mirja Kuehlewind \(IETF\)" , "rtcweb@ietf.org" , "rtcweb-chairs@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-16.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 14:10:08 -0000 but but!! sorry for missing this: i said it would be fair to cite the paper that identifies the dscp blackholi= ng problem; you said ok, if i give you the xml bit for it; i did; you still d= on't cite it. please do. Sent from my iPhone > On 4. okt. 2016, at 11.47, Harald Alvestrand wrote:= >=20 >=20 > I believe this version closes all post-IESG open issues on -transports. >=20 > Thank you for your consideration. >=20 > -------- Videresendt melding -------- > Emne: New Version Notification for draft-ietf-rtcweb-transports-16.txt > Dato: Tue, 04 Oct 2016 01:42:30 -0700 > Fra: internet-drafts@ietf.org > Til: Harald Alvestrand >=20 >=20 > A new version of I-D, draft-ietf-rtcweb-transports-16.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. >=20 > Name: draft-ietf-rtcweb-transports > Revision: 16 > Title: Transports for WebRTC > Document date: 2016-10-04 > Group: rtcweb > Pages: 20 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-16.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > Htmlized: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-1= 6 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-transports-16 >=20 > Abstract: > This document describes the data transport protocols used by WebRTC, > including the protocols used for interaction with intermediate boxes > such as firewalls, relays and NAT boxes. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 6 12:07:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04D2129766; Thu, 6 Oct 2016 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 jgdRTRaiUjg0; Thu, 6 Oct 2016 12:07:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC88129593; Thu, 6 Oct 2016 12:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E87EA7C034F; Thu, 6 Oct 2016 21:07:42 +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 Df5LOtlAT0Wx; Thu, 6 Oct 2016 21:07:41 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:e45c:bc65:19eb:aec7] (unknown [IPv6:2001:470:de0a:1:e45c:bc65:19eb:aec7]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2ED927C01FA; Thu, 6 Oct 2016 21:07:41 +0200 (CEST) To: Michael Welzl References: <147557055077.12851.1347339442333163275.idtracker@ietfa.amsl.com> <3B4EEF3A-AF5E-4DA6-8142-BDE0B6E7E075@ifi.uio.no> From: Harald Alvestrand Message-ID: <49d396bf-52a6-a2a5-22aa-05ea6e96d326@alvestrand.no> Date: Thu, 6 Oct 2016 21:07:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3B4EEF3A-AF5E-4DA6-8142-BDE0B6E7E075@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Mirja Kuehlewind \(IETF\)" , "rtcweb@ietf.org" , "rtcweb-chairs@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-16.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:07:48 -0000 On 10/06/2016 04:09 PM, Michael Welzl wrote: > but but!! sorry for missing this: > > i said it would be fair to cite the paper that identifies the dscp blackholing problem; you said ok, if i give you the xml bit for it; i did; you still don't cite it. please do. Oops. I didn't file an issue for it, which I should have done. So I forgot. > > Sent from my iPhone > >> On 4. okt. 2016, at 11.47, Harald Alvestrand wrote: >> >> >> I believe this version closes all post-IESG open issues on -transports. >> >> Thank you for your consideration. >> >> -------- Videresendt melding -------- >> Emne: New Version Notification for draft-ietf-rtcweb-transports-16.txt >> Dato: Tue, 04 Oct 2016 01:42:30 -0700 >> Fra: internet-drafts@ietf.org >> Til: Harald Alvestrand >> >> >> A new version of I-D, draft-ietf-rtcweb-transports-16.txt >> has been successfully submitted by Harald Alvestrand and posted to the >> IETF repository. >> >> Name: draft-ietf-rtcweb-transports >> Revision: 16 >> Title: Transports for WebRTC >> Document date: 2016-10-04 >> Group: rtcweb >> Pages: 20 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-16.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-16 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-16 >> >> Abstract: >> This document describes the data transport protocols used by WebRTC, >> including the protocols used for interaction with intermediate boxes >> such as firewalls, relays and NAT boxes. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Fri Oct 7 10:12:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F2B1294FE for ; Fri, 7 Oct 2016 10:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWw9HK7kjbwc for ; Fri, 7 Oct 2016 10:12:01 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D33129555 for ; Fri, 7 Oct 2016 10:12:00 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f193so44532914wmg.0 for ; Fri, 07 Oct 2016 10:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=naDt7lCuhnd2sC532+5A6HDNlswdz7s1agisNK0ArTk=; b=liHiQI64l35kfmTlSJZzfau4tj3Fa0x7Vm8q3r74YU1KBaSOo02AxcffdwHry9MeWZ iq2C9jypmfojAeoqya1RfnMuJl6OZ3O2N86btOoeebz5EF9dlAqh12tajYFYt3jq9uaP y7LPk5PfY3U+IIZWF9cpvlCc27R5MLNcERZP6NgVf/ik1APh4AilhNlH8sIQrrwPM9uR RnEztc9HG7btnVkxQMlhdYbprYw7e9/kSMlLrJkqudA+Azrx4Bk5snhjwyvTFsKfVhBv eWgV7L0O+yuFSm/FRA7N1gkQYdWgaAlUbLTAl5cx112aWEHdSAhRDIOq1/PzceqOnnB7 1Axg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=naDt7lCuhnd2sC532+5A6HDNlswdz7s1agisNK0ArTk=; b=lgLeRJUTKflLhH7Vc9pmZZWj5yBLQWkZ1FF73Fe0GgCy1vJnkVeaSjsk3dI6c5Uaue H6sgV/V7YsMvYBhd7Dv5WwhcQPYJi6iE0j10OPMYXiBWt2NxGl7F2NUS9qV7oRAhjf2e gIhr1ce0BRq2bjXoJUh4fxWYgwui32QewOvuDsreP8PSu9QaOWcOjp+d2efJmSKKLoH3 VoCNPkfztXvm7CnGSwWTWoo+tifB3C6H/Fg6RF9ugfqukJngbUhq0EK2h2ZTWwgiwna/ vM+zrUfOMfd2cM3Tga0r0iqwqJWyWsiD7SZuiP+RVLXZQrei3Qm5NE0FKyfTB9NSikU5 yfQg== X-Gm-Message-State: AA6/9RkI6ZcvF5K/jHhA/NNWOEt73S4B1dEbSl3FLiPHOSfUkSfiJw6U1/eNXrxfzvIyav+9p+Xddu36RV7BCOeo X-Received: by 10.194.157.226 with SMTP id wp2mr22119087wjb.48.1475860319002; Fri, 07 Oct 2016 10:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.73 with HTTP; Fri, 7 Oct 2016 10:11:38 -0700 (PDT) From: Justin Uberti Date: Fri, 7 Oct 2016 10:11:38 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0122f5480db9cb053e4982f4 Archived-At: Subject: [rtcweb] Clarification on JSEP addTrack algorithm change X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:12:03 -0000 --089e0122f5480db9cb053e4982f4 Content-Type: text/plain; charset=UTF-8 At IETF 96, we discussed a modification to how addTrack would match new MSTs to m= sections (details at the link). At the time, I proposed the following text: *If the PeerConnection is in the have-remote-offer state, the track will be attached to the first compatible transceiver that was created by setRemoteDescription and does not have a local track. Otherwise, a new transceiver will be created.* The intent here was to only perform automatic track matching on m= sections that were added by a newly received offer/reoffer (and not on existing a=recvonly m= sections). However, Peter Thatcher pointed out that this text was somewhat ambiguous and would allow an existing a=recvonly m= section to be matched during a reoffer. To address this, Peter and I have agreed on the following revised text: *If the PeerConnection is in the have-remote-offer state, the track will be attached to the first compatible transceiver that was created by the most recent setRemoteDescription and does not have a local track. Otherwise, a new transceiver will be created.* This is being tracked in JSEP issue 288 . --089e0122f5480db9cb053e4982f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At IETF 96, we discussed a modification to how addTrack would match new M= STs to m=3D sections (details at the link).

At the time,= I proposed the following text:
If the PeerConnection is = in the have-remote-offer state, the track will be attached to the first com= patible transceiver that was created by setRemoteDescription and does not h= ave a local track. Otherwise, a new transceiver will be created.
<= /div>

The intent here was to only perform automat= ic track matching on m=3D sections that were added by a newly received offe= r/reoffer (and not on existing a=3Drecvonly m=3D sections). However, Peter = Thatcher pointed out that this text was somewhat ambiguous and would allow = an existing a=3Drecvonly m=3D section to be matched during a reoffer.
=

To address this, Peter and I have agreed on the followi= ng revised text:
If the PeerConnection is in the have-remote-o= ffer state, the track will be attached to the first compatible transceiver = that was created by the most recent setRemoteDescription and does no= t have a local track. Otherwise, a new transceiver will be created.
=

This is being tracked in JSEP=C2=A0issue 288.
=

--089e0122f5480db9cb053e4982f4-- From nobody Fri Oct 7 10:42:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F001129674 for ; Fri, 7 Oct 2016 10:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uNV0bg6qI8cj for ; Fri, 7 Oct 2016 10:42:01 -0700 (PDT) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.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 9E067129694 for ; Fri, 7 Oct 2016 10:42:01 -0700 (PDT) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 942CB60EF2; Fri, 7 Oct 2016 13:41:55 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 41D7860AF4; Fri, 7 Oct 2016 13:41:55 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.90.15] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 07 Oct 2016 13:41:55 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 7 Oct 2016 10:41:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:42:03 -0000 How are these a significant fingerprinting problem ? > On Oct 6, 2016, at 7:55 AM, Magnus Westerlund = wrote: >=20 > WG, >=20 > After discussion in AVTEXT and MMUSIC regarding the inclusion of MID = and RID as SDES items that this do exposes labels that previously only = have existed in the signalling plane in the media plane. And especially = in the RTP header extensions, where even if the media payload is = encrypted the header extension is not encrypted. >=20 > The risk with this is primarily a privacy and fingerprinting risk. And = the proposed mitgation is encryption of the RTP header extensions in = both the bundle and avtext-rid documents. >=20 > This leads to the conclusion that for RTCWeb, we must consider to act = on these recommendations and decide on which implementation and usage = requirement the protection of these field should have. >=20 > My proposal is that implementation and use of RFC6904 encryption of = the RTP header extensions are REQUIRED. For RTCP it is actually unclear = if there is mandatory to use encrypted SRTCP. I think it should be = required and that can be clarified in Section 5.5 of = draft-ietf-rtcweb-security-arch. >=20 >=20 > Opinions? >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 7 10:53:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2451296B8 for ; Fri, 7 Oct 2016 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwMGy1_ry-v3 for ; Fri, 7 Oct 2016 10:53:36 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB61D1296B5 for ; Fri, 7 Oct 2016 10:53:35 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w3so9448206ywg.1 for ; Fri, 07 Oct 2016 10:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gcy9gVJDlW9JQnJJE/uu+BDprh47YdMqygDlzNBPqxU=; b=JWNt6nk5i+Nb5evfJvmupKdWSRkBT21tHe8hApa3/aSSF9smTqa/r7k7BjV8jufB0n zVj/ZZzJHs2cLlOVCmWfGRSAVpgaAfZjyCLV6lC737GAE8ULCQ8cfE7TS8KN8D/uf+T9 23lm99czrzp33bcM8SIq0bp9DWgGgLL/74QAE4hjNes72yznM61M50FfGbFZCc2tKCTM 90ScoSCSxiAH5f9kDX2DdQ6SAExz2JAQLTEALZh8nP0ON7+fLU/2MO6gkJRLs0zGPBXU pWnXEs/obWJ8vPp1o2YFgsioD6uNrUx//TZXmp8RnUGfDeEfmk47RJS0RR0W4bO2hXaE Gopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gcy9gVJDlW9JQnJJE/uu+BDprh47YdMqygDlzNBPqxU=; b=fvRbdKLSEm/16+6+rdeBrtcavFeJyTkrdJAoxEiiEIjcnpr+qXsEqSBgGlfrV8T1FL JGrtcIdUCV2pNah/E1Bc8tfMShnhGS1ZVb5yCXYoS6SAtQ4luUMLL+rERCg19sNLi7yx na/NUGViRb+/oeMUke+D/yHTYcJHhR/Zebcge/jb/BDVVroJOXrc8l9c95fYQeeef4FL GFYDtKivCGqqj146n9mpWetXzgx1Uscm8VqIC1coPo00pFNp3UyRMSBh1aKF6aJjfH0B sVoCZjXLl+ZadrmDKqW79pVJT9hV1gjahPFGnsZCMcd0JyoUwgjUAB58y8IIl64pYNgR A3bg== X-Gm-Message-State: AA6/9RmLTk6dmyQoKvJoGrM9Gox6T3uB0oaZmGCYQqXMgBigaD0OcHKik9bXVMBghZtEsJyxp1O44Bm5LpoMKw== X-Received: by 10.129.125.198 with SMTP id y189mr15705362ywc.234.1475862815066; Fri, 07 Oct 2016 10:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 10:52:54 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Oct 2016 10:52:54 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a114926a0d48637053e4a1639 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on JSEP addTrack algorithm change X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:53:38 -0000 --001a114926a0d48637053e4a1639 Content-Type: text/plain; charset=UTF-8 This is fine with me, but I think we should modify the *text* to make clear what the intent is. Perhaps something like this: "For example, if a PeerConnection receives an offer with an m= section that is send-recv a call to addTrack() prior to calling createAnswer() can attach a track to that transceiver. However, after createAnswer() and setLocalDescription() have been called, any call to addTrack() will create a new transceiver even if the new track would otherwise be compatible" On Fri, Oct 7, 2016 at 10:11 AM, Justin Uberti wrote: > At IETF 96, we discussed a modification > > to how addTrack would match new MSTs to m= sections (details at the link). > > At the time, I proposed the following text: > *If the PeerConnection is in the have-remote-offer state, the track will > be attached to the first compatible transceiver that was created by > setRemoteDescription and does not have a local track. Otherwise, a new > transceiver will be created.* > > The intent here was to only perform automatic track matching on m= > sections that were added by a newly received offer/reoffer (and not on > existing a=recvonly m= sections). However, Peter Thatcher pointed out that > this text was somewhat ambiguous and would allow an existing a=recvonly m= > section to be matched during a reoffer. > > To address this, Peter and I have agreed on the following revised text: > *If the PeerConnection is in the have-remote-offer state, the track will > be attached to the first compatible transceiver that was created by the > most recent setRemoteDescription and does not have a local track. > Otherwise, a new transceiver will be created.* > > This is being tracked in JSEP issue 288 > . > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114926a0d48637053e4a1639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is fine with me, but I think we should modify the *te= xt* to make clear what the intent is.

Perhaps something = like this:
"For example, if a PeerConnection receives an off= er with an m=3D section that is send-recv
a call to addTrack() pr= ior to calling createAnswer() can attach a track to that transceiver.
=
However, after createAnswer() and setLocalDescription() have been call= ed, any call
to addTrack() will create a new transceiver even if = the new track would otherwise be compatible"

=

O= n Fri, Oct 7, 2016 at 10:11 AM, Justin Uberti <juberti@google.com>= wrote:
At IETF 9= 6, we discussed a modification to how addTrack would match new MSTs to m= =3D sections (details at the link).

At the time, I propo= sed the following text:
If the PeerConnection is in the h= ave-remote-offer state, the track will be attached to the first compatible = transceiver that was created by setRemoteDescription and does not have a lo= cal track. Otherwise, a new transceiver will be created.

The intent here was to only perform automatic track= matching on m=3D sections that were added by a newly received offer/reoffe= r (and not on existing a=3Drecvonly m=3D sections). However, Peter Thatcher= pointed out that this text was somewhat ambiguous and would allow an exist= ing a=3Drecvonly m=3D section to be matched during a reoffer.
To address this, Peter and I have agreed on the following revis= ed text:
If the PeerConnection is in the have-remote-offer sta= te, the track will be attached to the first compatible transceiver that was= created by the most recent setRemoteDescription and does not have a= local track. Otherwise, a new transceiver will be created.

This is being tracked in JSEP=C2=A0issue 288.<= /div>



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

--001a114926a0d48637053e4a1639-- From nobody Fri Oct 7 11:23:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90112944A for ; Fri, 7 Oct 2016 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 PuBwD_romYTB for ; Fri, 7 Oct 2016 11:23:41 -0700 (PDT) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 A418B128B44 for ; Fri, 7 Oct 2016 11:23:41 -0700 (PDT) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E518DC054E; Fri, 7 Oct 2016 14:23:40 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 44A9AC050F; Fri, 7 Oct 2016 14:23:40 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.90.15] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 07 Oct 2016 14:23:40 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <243c777f-46f9-4053-1588-7e6b58a06c8c@ericsson.com> Date: Fri, 7 Oct 2016 11:23:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71419d1f-af1d-46e9-401d-81c5df73fc49@ericsson.com> <58510E68-A045-4312-B3B3-3468E83C8EB7@iii.ca> <243c777f-46f9-4053-1588-7e6b58a06c8c@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:23:43 -0000 > On Oct 7, 2016, at 1:41 AM, Magnus Westerlund = wrote: >=20 > Den 2016-10-06 kl. 23:59, skrev Cullen Jennings: >>=20 >> I'm not getting the problem here and mandating 6904 is not an easy >> thing to do. >=20 > So, lets be clear on what I have proposed. For bundle in general it is = RECOMMENDED to encrypt MIDs in RTP header extensions. I have also = proposed that for RTCWeb implementation and use should be mandated. I = was not clear in what applies when an WebRTC endpoint talks to a legacy = endpoint what is expected here. I guess this is the thorny issue. >=20 >>=20 >> I'm not getting what the issue is here. If mid are random, or are >> just a count of n'th m-line in the sdp, what is the problem with >> exposing them to people are getting the media? >=20 > The issue is that these identifiers are going from having only been = visiable in the signalling messages to be visible also on the RTP media = plane. And without RFC6904 even if one uses SRTP, these values are = exposed. This have several different effects as I see it. So if the = generation algorithm are not strictly defined, the implementation gets = possible to fingerprint. In addition the device gets to be fingerprinted = based on the number of streams offered and their identifiers. Thus, it = is not only what is actually used that is exposed, but what was = originally offered, i.e. the full offer leaks into unencrypted domain on = the media plane. Note, this later can't be dealt with any mid id = creation rules, it will still leak. Thus devices that have more exotic = configurations when it comes to media streams, i.e. number of cameras = etc this can still be fingerprinted by passive attacks from third = parties. >=20 > It is the passive attack from third parties that has me worried here. = A peer in the signalling has massively more powerful fingerprinting, but = that requires one to be in the signalling context, not passively observe = traffic that goes past. >=20 I'm still not getting the fingerprint problem. How is this different = than PT and SSRC. Yes, I agree the MID and RID - which were always = intended to go in the RTP packet need to be generated not to have = sensitive information in them.=20 From nobody Fri Oct 7 11:54:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808F71296E2 for ; Fri, 7 Oct 2016 11:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yld6-b5bxaI2 for ; Fri, 7 Oct 2016 11:54:04 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B73D1296DF for ; Fri, 7 Oct 2016 11:54:04 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e20so19215144ybb.0 for ; Fri, 07 Oct 2016 11:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OteNt/HfUYBDc56LbmkloloWWJspoftN0/Xa8CVXKIY=; b=tXDjAGaHYxT3WwhrM5LbU/IbJMfWXvLJTkwVP8bvPKoyerPIX7JTYD33dvQRet98tD Xi/txd0n2tAKhCb+itmceJH4v5dI4urI3gkQ7kc69JzFh3STS6BzFLZSXNoGYybVSUSi 0qiECah6HGCWyRw4Aix4vp3YzPc+xdEh8977STgRp0w7WNddX9GINMARKsHmLByE3VbZ Yt5bJhzhRa8BZwrIA7UfNpp/bID+5SFN4ELVzpWodsl7GkPMUVZkCB4vuB/y53hQVtRS 8fAxGfha30L0nCzurrTcPg9oqHbzUBMqS4OenDMK9ZrDg3UlFz6itXXyIQM6IX9lD3CI S43A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OteNt/HfUYBDc56LbmkloloWWJspoftN0/Xa8CVXKIY=; b=Jc137H4nylxwxejU2Hxugx3maUsGcLbuRW8MevhX9kwKS/rc4AGnYSumW/fQvteyvR e5eMFJ85EN+9hBLp6HeRg6FL23atzItv29H4lMbiFzjl5jFjnak8cLzDpeZzT9Rf0IVu JPS+2SqCWlASKaGbFRSx49Bi/WYzyR/bs+YsOcN5lTx6cCqA8pEawxpPFfQenq/e8jup 5CpxemsMqlu0J4rFGZ8eQX6jWL+gjs4pufSQZYTM85GNJheaMRVkqd74jH/veJv/CD4z Oq5k8Kx97npGpqAtt/r4JhOzI6mYtqSzwZZMXMmSMpY42d98su8lpqholiAeOv5D1+Th kYEg== X-Gm-Message-State: AA6/9Rlyx3y9ONKRflxppodtpsNQcTZDi06c6Sh+9D6YTzSc9P8SVVJpUS5nAJIzun8TbhC2OKGwUQwDGmjj0A== X-Received: by 10.37.103.139 with SMTP id b133mr17430888ybc.107.1475866443681; Fri, 07 Oct 2016 11:54:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 11:53:23 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Oct 2016 11:53:23 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a1142f87a1ce10e053e4aef0c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on JSEP addTrack algorithm change X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:54:06 -0000 --001a1142f87a1ce10e053e4aef0c Content-Type: text/plain; charset=UTF-8 Upon reflection I think this is clear enough On Fri, Oct 7, 2016 at 10:52 AM, Eric Rescorla wrote: > This is fine with me, but I think we should modify the *text* to make > clear what the intent is. > > Perhaps something like this: > "For example, if a PeerConnection receives an offer with an m= section > that is send-recv > a call to addTrack() prior to calling createAnswer() can attach a track to > that transceiver. > However, after createAnswer() and setLocalDescription() have been called, > any call > to addTrack() will create a new transceiver even if the new track would > otherwise be compatible" > > > > On Fri, Oct 7, 2016 at 10:11 AM, Justin Uberti wrote: > >> At IETF 96, we discussed a modification >> >> to how addTrack would match new MSTs to m= sections (details at the link). >> >> At the time, I proposed the following text: >> *If the PeerConnection is in the have-remote-offer state, the track will >> be attached to the first compatible transceiver that was created by >> setRemoteDescription and does not have a local track. Otherwise, a new >> transceiver will be created.* >> >> The intent here was to only perform automatic track matching on m= >> sections that were added by a newly received offer/reoffer (and not on >> existing a=recvonly m= sections). However, Peter Thatcher pointed out that >> this text was somewhat ambiguous and would allow an existing a=recvonly m= >> section to be matched during a reoffer. >> >> To address this, Peter and I have agreed on the following revised text: >> *If the PeerConnection is in the have-remote-offer state, the track will >> be attached to the first compatible transceiver that was created by the >> most recent setRemoteDescription and does not have a local track. >> Otherwise, a new transceiver will be created.* >> >> This is being tracked in JSEP issue 288 >> . >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a1142f87a1ce10e053e4aef0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Upon reflection I think this is clear enough

On Fri, Oct 7, 2016 at 10= :52 AM, Eric Rescorla <ekr@rtfm.com> wrote:
This is fine with me, but I think we should = modify the *text* to make clear what the intent is.

Perh= aps something like this:
"For example, if a PeerConnection r= eceives an offer with an m=3D section that is send-recv
a call to= addTrack() prior to calling createAnswer() can attach a track to that tran= sceiver.
However, after createAnswer() and setLocalDescription() = have been called, any call
to addTrack() will create a new transc= eiver even if the new track would otherwise be compatible"
<= br>


On Fri, Oct 7, 2016 at 10:11 AM, Justin= Uberti <juberti@google.com> wrote:
At IETF 96,= we discussed a modification to how addTrack would match new MSTs to m=3D= sections (details at the link).

At the time, I proposed= the following text:
If the PeerConnection is in the have= -remote-offer state, the track will be attached to the first compatible tra= nsceiver that was created by setRemoteDescription and does not have a local= track. Otherwise, a new transceiver will be created.
<= i>
The intent here was to only perform automatic track ma= tching on m=3D sections that were added by a newly received offer/reoffer (= and not on existing a=3Drecvonly m=3D sections). However, Peter Thatcher po= inted out that this text was somewhat ambiguous and would allow an existing= a=3Drecvonly m=3D section to be matched during a reoffer.

To address this, Peter and I have agreed on the following revised = text:
If the PeerConnection is in the have-remote-offer state,= the track will be attached to the first compatible transceiver that was cr= eated by the most recent setRemoteDescription and does not have a lo= cal track. Otherwise, a new transceiver will be created.
=
This is being tracked in JSEP=C2=A0issue 288.



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


--001a1142f87a1ce10e053e4aef0c-- From nobody Fri Oct 7 20:32:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4C129435 for ; Fri, 7 Oct 2016 20:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr0iUaEeeKZl for ; Fri, 7 Oct 2016 20:32:55 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D83129407 for ; Fri, 7 Oct 2016 20:32:53 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id qn10so26085489pac.2 for ; Fri, 07 Oct 2016 20:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qu7lAwn1E4ks0610mwtbByB6E0yTGENNaUF8PVzHcKg=; b=y84LE2Eg0aSHdmSHgD9a07TKI77LGizMCv9tKFHaNevdd6x2DXD9F4d3Yl6bcXiMRq wZ/T7qqSKu65wuxjqeitMRNq3DOGbJXxQc34VV0XKASrhF4+bMESjRLGchHLWxOvitzw JopmtW3QhtFQ/YcwvApAEB+kS/bGFOhZ5PYnwwehGZcR6DvaAyQEMY/WmRGCEeOiTdtU rSk1hh2XU37rUiqNZFZw4APUcnvrMXMb84Vubc419OJ9yNvPH7WYu/AXetbP6NOHO07/ KN1DYCV2iXm4FkTm6IXRaU2Jcu0JDI+Pik/omBADKuviET/Zp9VobNUKBlpjFVC1wbk9 FHRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qu7lAwn1E4ks0610mwtbByB6E0yTGENNaUF8PVzHcKg=; b=X/QJkWzES9LkoZT2jNe9ghECFyxxaKqtt1fVZHyKWhN9CTrX6pViQGW5lukLUBagEc iRJkiwGCbEXLCZW92Icrab9+Km7CkKofMMTy2zDdYcZbedfGn36yJTlzuBM/aj22znQ3 hQeSu3ROWzWE29ZUD2Q0mdb6nBbizhBWvvgVex6//A+CMCvOZZuNTXl2PpteA8q2uyno 6Qy37k4OtMpWhcwL+xZ7w7azhMLFERckthLJzhvnQK2nKunkHXsvJ+qSpih+hlTltY6t aZPx+egLd9OaEuiTe92MF3XMy7yCSgnuryLW/2nkAqsba3TlP9US1tko//iMFaAUo3tb nxiQ== X-Gm-Message-State: AA6/9RnWKt1GADxRijSuSnX11eKLhgMsM9ovbs96ibdn6sRXBAOPePBJ73Dv18u0eC2i7g== X-Received: by 10.67.3.102 with SMTP id bv6mr35363853pad.61.1475897573412; Fri, 07 Oct 2016 20:32:53 -0700 (PDT) Received: from [192.168.1.105] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id u10sm17201366pau.32.2016.10.07.20.32.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Oct 2016 20:32:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Fri, 7 Oct 2016 20:32:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cullen Jennings Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 03:32:58 -0000 I don't see how snooping the MID and RID would provide info that could not b= e obtained in other ways. For example, an observer can tell audio from video= traffic just by looking at packet sizes. Similarly, simulcast streams will o= riginate from different SSRCs so no need to snoop the RID to figure out that= there are multiple streams being sent (or even which ones are related since= traffic will be correlated). > On Oct 7, 2016, at 10:41, Cullen Jennings wrote: >=20 >=20 > How are these a significant fingerprinting problem ? >=20 >=20 >> On Oct 6, 2016, at 7:55 AM, Magnus Westerlund wrote: >>=20 >> WG, >>=20 >> After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and R= ID as SDES items that this do exposes labels that previously only have exist= ed in the signalling plane in the media plane. And especially in the RTP hea= der extensions, where even if the media payload is encrypted the header exte= nsion is not encrypted. >>=20 >> The risk with this is primarily a privacy and fingerprinting risk. And th= e proposed mitgation is encryption of the RTP header extensions in both the b= undle and avtext-rid documents. >>=20 >> This leads to the conclusion that for RTCWeb, we must consider to act on t= hese recommendations and decide on which implementation and usage requiremen= t the protection of these field should have. >>=20 >> My proposal is that implementation and use of RFC6904 encryption of the R= TP header extensions are REQUIRED. For RTCP it is actually unclear if there i= s mandatory to use encrypted SRTCP. I think it should be required and that c= an be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch. >>=20 >>=20 >> Opinions? >>=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Oct 8 07:44:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFA3127A90 for ; Sat, 8 Oct 2016 07:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAB0cHMENIb8 for ; Sat, 8 Oct 2016 07:44:27 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11067129539 for ; Sat, 8 Oct 2016 07:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3723; q=dns/txt; s=iport; t=1475937867; x=1477147467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lNAkD0rz+P967Wvqh+GNgiKQ9VUZUdc6Up/hOOY1Afw=; b=OFLNnSqeU4Ckhyysjgi1BwGIuNF8sEDFm4W8etZdsaJ1WMKjmqYASU/A 8SCmlW2y1l12fKkM7Nm6hTKECN4RMX0WhcswQQgBYCXM8qgXmg1MI8yCo EDM/pKFkKfWVkSKq4BHZJgfn4xQ/7nlX/1jpdCVCZNkun1/wueyGXgsiV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBVBflX/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfI0zlwGHW4xWggsbC4UwSgKBejgUAQIBAQEBAQE?= =?us-ascii?q?BXieEYQEBAQMBAQEBCWILBQkCAgEIGCcHGwYGCxQRAgQOBYg2Aw8IDrwNDYNkA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFhjiBfYJYgkeCAIMwgi8FiDuGOopVNQG?= =?us-ascii?q?McYMLCo9qiGOEFIN+AR42S4JrHBmBOnKHfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,461,1473120000"; d="scan'208";a="333228647" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Oct 2016 14:44:26 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u98EiQvQ031867 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Oct 2016 14:44:26 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Oct 2016 09:44:25 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Sat, 8 Oct 2016 09:44:25 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSIRSvyLgtO7YE+0OQTKhN6ScPbaCeosTH Date: Sat, 8 Oct 2016 14:44:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 14:44:29 -0000 MID and RID are similar to PT in this regard. They are all arbitrary values= that only have semantic meaning when combined with a media description in = external signaling. Any genuine concern over privacy or fingerprinting issu= es with MID and RID should first consider PT. I'm unaware of any concerns e= xpressed over unencrypted PT. Note that it is possible to use encrypted SRTCP to convey MID and RID witho= ut including them in SRTP packets. One proposed version of the RTP demux ru= les has explicitly noted this approach of using RTCP to latch MID/RID to an= SSRC even if RTP does not contain those header extensions for that SSRC.=20 Mandating encrypted SRTCP seems more palatable than mandating encrypted RTP= header extensions. But I don't think a good case has been made yet for eit= her, especially considering PT is always unencrypted.=20 Mo On Oct 7, 2016, at 11:33 PM, Bernard Aboba wrote: I don't see how snooping the MID and RID would provide info that could not = be obtained in other ways. For example, an observer can tell audio from vid= eo traffic just by looking at packet sizes. Similarly, simulcast streams wi= ll originate from different SSRCs so no need to snoop the RID to figure out= that there are multiple streams being sent (or even which ones are related= since traffic will be correlated). > On Oct 7, 2016, at 10:41, Cullen Jennings wrote: >=20 >=20 > How are these a significant fingerprinting problem ? >=20 >=20 >> On Oct 6, 2016, at 7:55 AM, Magnus Westerlund wrote: >>=20 >> WG, >>=20 >> After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and= RID as SDES items that this do exposes labels that previously only have ex= isted in the signalling plane in the media plane. And especially in the RTP= header extensions, where even if the media payload is encrypted the header= extension is not encrypted. >>=20 >> The risk with this is primarily a privacy and fingerprinting risk. And t= he proposed mitgation is encryption of the RTP header extensions in both th= e bundle and avtext-rid documents. >>=20 >> This leads to the conclusion that for RTCWeb, we must consider to act on= these recommendations and decide on which implementation and usage require= ment the protection of these field should have. >>=20 >> My proposal is that implementation and use of RFC6904 encryption of the = RTP header extensions are REQUIRED. For RTCP it is actually unclear if ther= e is mandatory to use encrypted SRTCP. I think it should be required and th= at can be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch. >>=20 >>=20 >> Opinions? >>=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Oct 9 03:24:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E618912953B for ; Sun, 9 Oct 2016 03:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jid9zLHnD5xA for ; Sun, 9 Oct 2016 03:24:25 -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 BCC61129535 for ; Sun, 9 Oct 2016 03:24:24 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-f7-57fa1ad61ce7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id D0.0D.03250.6DA1AF75; Sun, 9 Oct 2016 12:24:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 12:24:22 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Bernard Aboba Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSH9lMExaUQsC7kESlGYxjwYhpQqCdIvSAgAClHACAALujgIABaqEw Date: Sun, 9 Oct 2016 10:24:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD3D9C8@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9Sve61K9wg9dTeC027PvPbPHiwRwm i7X/2tkdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZfyccJ2xYJJKxY//h9ka GC/JdjFyckgImEhMfDyTuYuRi0NIYD2jxLIze9kgnMWMEhtWrWfqYuTgYBOwkOj+pw3SICIQ IdHe/ZIJxGYWUJT4snw+G4gtLJAgsWveZBaImkSJ5tt9zCCtIgJuEmvvSoGYLAIqEkeuVYOY vAK+EndfeUIsusYo8frIQrBOTgFbiWtnpjGC2IwCYhLfT62B2iQucevJfCaIkwUkluw5zwxh i0q8fPyPFcJWklh0+zNUvZ7EjalT2CBsbYllC1+D1fMKCEqcnPmEZQKj6CwkY2chaZmFpGUW kpYFjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLj5uCW3wY7GF8+dzzEKMDBqMTDm5Dz M1yINbGsuDL3EKMEB7OSCO8h0V/hQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJ zU5NLUgtgskycXBKNTAK56gcKNjOfGxdpuYfrVq2OCb2efVsi57tFpY/HuzEylKx5tDzxNdB H5xqtL2esZxJerjkiG/s6ePxsQ8WiO/vtPnx0L8weomyfMdDvS1S1yz0KmeIB1de8+887pDy XYD7lthsJonzHMFVLu6B8/OcXNb2Xr97I2Byxt06rpsij9YeX3Ew+YISS3FGoqEWc1FxIgBW 9NG6lwIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 10:24:27 -0000 Hi, On the MMUSIC list Jonathan L informed the community about the following te= xt in RFC 7904 (SDES header extensions): "In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected." So, *IF* we assume that "any type of confidentiality protection" is enabled= for RTCP, I guess the answer is pretty clear, or? Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: 08 October 2016 17:44 To: Bernard Aboba Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID= and RID SDES items MID and RID are similar to PT in this regard. They are all arbitrary values= that only have semantic meaning when combined with a media description in = external signaling. Any genuine concern over privacy or fingerprinting issu= es with MID and RID should first consider PT. I'm unaware of any concerns e= xpressed over unencrypted PT. Note that it is possible to use encrypted SRTCP to convey MID and RID witho= ut including them in SRTP packets. One proposed version of the RTP demux ru= les has explicitly noted this approach of using RTCP to latch MID/RID to an= SSRC even if RTP does not contain those header extensions for that SSRC.=20 Mandating encrypted SRTCP seems more palatable than mandating encrypted RTP= header extensions. But I don't think a good case has been made yet for eit= her, especially considering PT is always unencrypted.=20 Mo On Oct 7, 2016, at 11:33 PM, Bernard Aboba wrote: I don't see how snooping the MID and RID would provide info that could not = be obtained in other ways. For example, an observer can tell audio from vid= eo traffic just by looking at packet sizes. Similarly, simulcast streams wi= ll originate from different SSRCs so no need to snoop the RID to figure out= that there are multiple streams being sent (or even which ones are related= since traffic will be correlated). > On Oct 7, 2016, at 10:41, Cullen Jennings wrote: >=20 >=20 > How are these a significant fingerprinting problem ? >=20 >=20 >> On Oct 6, 2016, at 7:55 AM, Magnus Westerlund wrote: >>=20 >> WG, >>=20 >> After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and= RID as SDES items that this do exposes labels that previously only have ex= isted in the signalling plane in the media plane. And especially in the RTP= header extensions, where even if the media payload is encrypted the header= extension is not encrypted. >>=20 >> The risk with this is primarily a privacy and fingerprinting risk. And t= he proposed mitgation is encryption of the RTP header extensions in both th= e bundle and avtext-rid documents. >>=20 >> This leads to the conclusion that for RTCWeb, we must consider to act on= these recommendations and decide on which implementation and usage require= ment the protection of these field should have. >>=20 >> My proposal is that implementation and use of RFC6904 encryption of the = RTP header extensions are REQUIRED. For RTCP it is actually unclear if ther= e is mandatory to use encrypted SRTCP. I think it should be required and th= at can be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch. >>=20 >>=20 >> Opinions? >>=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> --------------------------------------------------------------------- >> - Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ 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 Mon Oct 10 02:05:33 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3C129469 for ; Mon, 10 Oct 2016 02:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqDQvemxEezb for ; Mon, 10 Oct 2016 02:05:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D0E1294BA for ; Mon, 10 Oct 2016 02:05:26 -0700 (PDT) X-AuditID: c1b4fb25-14bff7000000793b-58-57fb59d49eb5 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 2D.8D.31035.4D95BF75; Mon, 10 Oct 2016 11:05:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.319.2; Mon, 10 Oct 2016 11:05:24 +0200 To: Christer Holmberg , "Mo Zanaty (mzanaty)" , Bernard Aboba References: <7594FB04B1934943A5C02806D1A2204B4BD3D9C8@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <51176963-4334-ace3-4bc3-cba9c4121379@ericsson.com> Date: Mon, 10 Oct 2016 11:05:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD3D9C8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7iu7VyN/hBiu6JC027PvPbPHiwRwm i7X/2tkdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcxpnM1YsF6oYv/HWawN jE/4uhg5OSQETCRWHPvJ1MXIxSEksJ5R4vaVNkYIZzmjxLFfRxlBqoQFEiR+zfkAlhAR6GGU 2H94HStIQkhgJpPEqjWRIDazgKLEl+Xz2UBsNgELiZs/GsFsXgF7iSdb7jOB2CwCqhIrDm4G 6xUViJG4/uwRVI2gxMmZT1hAbE4BP4kzj76wdzFyAM20l3iwtQxivLxE89bZzBBrtSUamjpY JzAKzELSPQuhYxaSjgWMzKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAkP14JbfqjsYL79x PMQowMGoxMO7oPVXuBBrYllxZe4hRgkOZiUR3j0hv8OFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYIzsaum5VPp1yprkMqPK3aKVN+4Hy52azsAlKJfx Z+ks/fUxq8Wa772reC8mMcVuTehKi8srO/LSzK8vVGSuvDOl0vLur1iHKqVUxfvCC27fnOy8 8XZlzQGHT6dmG5tPPpD23if2XfRcI47Ldp48T7N8mybn7ZT2bkloLg3rvNtd8PxUypM7vkos xRmJhlrMRcWJAF6e1f5RAgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 09:05:29 -0000 Den 2016-10-09 kl. 12:24, skrev Christer Holmberg: > Hi, > > On the MMUSIC list Jonathan L informed the community about the following text in RFC 7904 (SDES header extensions): > > "In RTP sessions where any type of confidentiality protection is > enabled for RTCP, the SDES item header extensions MUST also be > protected." > > So, *IF* we assume that "any type of confidentiality protection" is enabled for RTCP, I guess the answer is pretty clear, or? > Yes, from my perspective this is settled. RFC 7904 forces encryption of the MID value in an WebRTC context. If the RTCWeb WG do not agree with this, then it needs to work on changing RFC 7904. I do not support chaning that RFC's conclusion that information that is protected in RTCP needs to be protected also in RTP headers. When it comes to the information leakage and the fingerprinting possibilities of SSRCs, PTs etc, it is present and getting worse in multi-stream systems. So when you had a single media stream per endpoint and that used a random SSRC and one PT value during the life-time of the RTP session, there is very little information leakage here. The codec possibly leaks through PT, but the packet length, at least for audio leaks that information anyway. However, when one starts to have a endpoint that uses multiple media streams, and certain configurations of RTX and FEC, then the publicly visable fingerprinting surface from RTP streams goes up. Now both implementation choices as well as device hardware configurations starts to show in the unencrypted RTP headers. So MID and RID is one additional parameter that increases the potential for fingerprinting here. So what is the reason given that we protect the RTP payload and the RTCP packets with encryption, to not also protected the RTP header extensions? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Oct 13 11:12:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEBE129619 for ; Thu, 13 Oct 2016 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -117.517 X-Spam-Level: X-Spam-Status: No, score=-117.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arvFOITn5ViR for ; Thu, 13 Oct 2016 11:12:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D735F129558 for ; Thu, 13 Oct 2016 11:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2338; q=dns/txt; s=iport; t=1476382350; x=1477591950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kSONAUYBt7+2BiQLAxTXQvcbvY3Ig1QKQ3FNGp2YRGE=; b=XY4YQTzxUNcyKfHjKLrUc+NUWpYQ5BKaHvbeh6xQCbWU+GLxmI5L5o2B WEVwvv6szLyvOj15cc34W4LOFGMddxRy45WWXR60LxLNOme5DCxTxjsHm Qrw7iezVikmXpDtpMeMzz0KiHCesw6J7wDYU1hbI7s+qiXLRVGBEM2Oca A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAgDTzf9X/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAekMZY+HAuFMEoCggo8EAECAQEBAQEBAV4nhGE?= =?us-ascii?q?BAQEDAQEBAQliCwUJAgIBCBgnBxsMCxQRAgQOBYhKCA7DLgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFBYg1gliER4Mwgi8FiDyRRgGPfI91jHmDfgE1H1CCdRwZgTp?= =?us-ascii?q?yhwSBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,340,1473120000"; d="scan'208";a="333889889" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2016 18:12:30 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9DICTaL023342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 18:12:30 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 14:12:28 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 14:12:28 -0400 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSJX1b6MtzUuyRZUS84VuzdzWIrQ== Date: Thu, 13 Oct 2016 18:12:28 +0000 Message-ID: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.127.141] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02B355BC75A47343ABD71C78D82C06EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 18:12:33 -0000 I think this is huge complexity that is not currently supported and not nee= ded. How about we generate the RID such that the RID for the n'th m line is= n. Or generate it as a random number. Do you see any problem with this? I think this removes all the fingerprinting issues. I'm fine with advice th= at say how to generate the RID in a way that is privacy sensitive but I'm n= ot a fan of making RID require support for RTP header encryption.=20 > On Oct 6, 2016, at 7:55 AM, Magnus Westerlund wrote: >=20 > WG, >=20 > After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and = RID as SDES items that this do exposes labels that previously only have exi= sted in the signalling plane in the media plane. And especially in the RTP = header extensions, where even if the media payload is encrypted the header = extension is not encrypted. >=20 > The risk with this is primarily a privacy and fingerprinting risk. And th= e proposed mitgation is encryption of the RTP header extensions in both the= bundle and avtext-rid documents. >=20 > This leads to the conclusion that for RTCWeb, we must consider to act on = these recommendations and decide on which implementation and usage requirem= ent the protection of these field should have. >=20 > My proposal is that implementation and use of RFC6904 encryption of the R= TP header extensions are REQUIRED. For RTCP it is actually unclear if there= is mandatory to use encrypted SRTCP. I think it should be required and tha= t can be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch. >=20 >=20 > Opinions? >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 13 11:20:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326D212961B for ; Thu, 13 Oct 2016 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 DTOeEHtmgqXb for ; Thu, 13 Oct 2016 11:20:27 -0700 (PDT) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (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 15764129613 for ; Thu, 13 Oct 2016 11:20:26 -0700 (PDT) Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 11DFF4049E; Thu, 13 Oct 2016 14:20:24 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0ACE44019B; Thu, 13 Oct 2016 14:20:22 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.127.141] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Thu, 13 Oct 2016 14:20:24 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <51176963-4334-ace3-4bc3-cba9c4121379@ericsson.com> Date: Thu, 13 Oct 2016 12:20:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <882ABF6F-8590-4AA3-A7A3-447BCC9AA2A9@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4BD3D9C8@ESESSMB209.ericsson.se> <51176963-4334-ace3-4bc3-cba9c4121379@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 18:20:28 -0000 > On Oct 10, 2016, at 3:05 AM, Magnus Westerlund = wrote: >=20 > Den 2016-10-09 kl. 12:24, skrev Christer Holmberg: >> Hi, >>=20 >> On the MMUSIC list Jonathan L informed the community about the = following text in RFC 7904 (SDES header extensions): >>=20 >> "In RTP sessions where any type of confidentiality protection is >> enabled for RTCP, the SDES item header extensions MUST also be >> protected." >>=20 Just one note - I think you mean RFC 7941 here.=20 From nobody Thu Oct 13 12:05:26 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D8129552 for ; Thu, 13 Oct 2016 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnyjPfxqLVQg for ; Thu, 13 Oct 2016 12:05:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC65412949B for ; Thu, 13 Oct 2016 12:05:23 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-1c-57ffdaeeac55 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 5C.60.02458.EEADFF75; Thu, 13 Oct 2016 21:05:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Thu, 13 Oct 2016 21:05:18 +0200 From: Christer Holmberg To: Cullen Jennings , Magnus Westerlund Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSH9lMExaUQsC7kESlGYxjwYhpQqCdIvSAgAClHACAALujgIABaqEwgAFbTYCABVIPgIAALdsQ Date: Thu, 13 Oct 2016 19:05:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD68AC8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD3D9C8@ESESSMB209.ericsson.se> <51176963-4334-ace3-4bc3-cba9c4121379@ericsson.com> <882ABF6F-8590-4AA3-A7A3-447BCC9AA2A9@iii.ca> In-Reply-To: <882ABF6F-8590-4AA3-A7A3-447BCC9AA2A9@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdV/fjrf/hBotna1ls2Pef2eLD+h+M Fi8ezGGyWPuvnd2BxWPK742sHjtn3WX3WLLkJ5PH5fMfGQNYorhsUlJzMstSi/TtErgyOt7f ZS/oYq44ebuXpYFxHVMXIyeHhICJxIMlk5i7GLk4hATWM0ps733MAuEsYZSYNeEzexcjBweb gIVE9z9tkAYRgUiJr0vmsIGEmQWyJS7uBQsLCyRI7Jo3mQWiJFGi+XYfM4QdJXH7xlMwm0VA VaKt/TIbiM0r4CsxZe8HsLiQwH8mif9n60BsTgErifb292A1jAJiEt9PrQG7k1lAXOLWk/lQ NwtILNlznhnCFpV4+fgfK4StJNG45AkrRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlI xs5C0jILScssJC0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG08Etv612MB587niI UYCDUYmHd8Hp/+FCrIllxZW5hxglOJiVRHgnXAMK8aYkVlalFuXHF5XmpBYfYpTmYFES5zVb eT9cSCA9sSQ1OzW1ILUIJsvEwSnVwFgrqpCzNfnfFmZfv4ecj54FG5rpF0gFBs3uZOSQeJ37 vk93jcO8AzUyk788fiE3cbrGut/CJVcv/BB3FL8gOFfmWFLU/cBUPqvZvF+PB6YXS37vnR/o elhkz8wOpx1Hko6HG60STvtnLLvrxGPt/eu+MXz+47p0TWr45H0S02dKTVe1tLSYl6fEUpyR aKjFXFScCABttw4gogIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 19:05:25 -0000 >> On the MMUSIC list Jonathan L informed the community about the following= text in >> RFC 7904 (SDES header extensions): >>=20 >> "In RTP sessions where any type of confidentiality protection is >> enabled for RTCP, the SDES item header extensions MUST also be >> protected." >=20 > > Just one note - I think you mean RFC 7941 here.=20 Correct :) Regards, Christer From nobody Fri Oct 14 01:26:20 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E1A1296E3 for ; Fri, 14 Oct 2016 01:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxMNBYLC0QYc for ; Fri, 14 Oct 2016 01:26:17 -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 80C6512963D for ; Fri, 14 Oct 2016 01:26:17 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-df-580096a6bc69 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id B3.5A.31035.6A690085; Fri, 14 Oct 2016 10:26:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Fri, 14 Oct 2016 10:26:14 +0200 To: "Cullen Jennings (fluffy)" References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> From: Magnus Westerlund Message-ID: Date: Fri, 14 Oct 2016 10:26:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM2K7tO7yaQwRBi969Cw6JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZdxt7mIuaOWr+PhuG0sD40TuLkYODgkBE4kN O7W7GLk4hATWM0oc6ehngXCWM0p0HF3C3MXIySEskCDxa84HRhBbRMBQomnPPCYQW0igSOLE xc2sIDazgKLEl+Xz2UBsNgELiZs/GsFsXgF7iaurtoLVsAioSkw9cRxspqhAjMT1Z4+gagQl Ts58wgJicwrYSnxbsoQR5DhmoN4HW8sgxstLbH87hxlirbZEQ1MH6wRGgVlIumchdMxC0rGA kXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBAHtzyW3UH4+U3jocYBTgYlXh4F5z+Hy7E mlhWXJl7iFGCg1lJhHffJIYIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqem FqQWwWSZODilGhibovfdEXUNCuPake+sP8n2VgKf6zfZk4ciFnD7XjFa1/d5+WPRjSeurBBv PftZgM241n/H80fs4pHPl1duy6pMND3KZLBjmdzZzXsXTdV/8vXaOWWHp7Hb66ctXctqoJOw Tmnu+6Xv4tqfmM9c6zD59dfo/iJlud12DIcr2k+//X//ncgBm8vPlFiKMxINtZiLihMBQLZI f0QCAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 08:26:19 -0000 Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy): > > I think this is huge complexity that is not currently supported and > not needed. How about we generate the RID such that the RID for the > n'th m line is n. Or generate it as a random number. Do you see any > problem with this? > > I think this removes all the fingerprinting issues. I'm fine with > advice that say how to generate the RID in a way that is privacy > sensitive but I'm not a fan of making RID require support for RTP > header encryption. > So, let disregard the fingerprinting issue for now. It is clear that I am in the rough and that this whole issue would benefit from a broad review on what we leak when using ICE and RTP/RTCP. What I don't understand here is that people have argued and agreed that we should encrypt the RTP and RTCP packets per default. Then when we comes to RTP header extensions we are no longer ready to provide that protection per default by ensuring RFC6904 implementation support. So RID and MID may not be the most sensitive fields if it has well constructed values. Then we have the audio level extensions where Client to mixer is RECOMMENDED to be implemented and REQUIRES RFC6904. So what is the issue, is it that you currently lack RFC6904 implementations, and thus this require more implementation work, or are there additional reasons for wanting to expose this information? To conclude, I personally think default usage of RFC6904 on header extensions would be a good thing. I currently see no reasons for changing the requirements that RFC 7941 puts on WebRTC, forcing the usage of RFC6904 encryption. If you want to something else, please provide a proposal for what that alternative would be. Cheers Magnus Westerlund From nobody Fri Oct 14 06:08:10 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DF912948B for ; Fri, 14 Oct 2016 06:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -117.517 X-Spam-Level: X-Spam-Status: No, score=-117.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aG3rsuaOqm9 for ; Fri, 14 Oct 2016 06:08:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BE81295E8 for ; Fri, 14 Oct 2016 06:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3196; q=dns/txt; s=iport; t=1476450487; x=1477660087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=negfruZCNDm6eiMEI32vVF4w+UBauj0NyWqbhWkGlB4=; b=axQubKDnveXEUCKuim0byQ7hUzzmfxgdGk/S9Gm72+oJSDYnztzGrIQz SUMxUHqXxCOPXLsbLQ9OPDWrB3IJFZimjiKL9Q+JpXOHkC+sUw1TOhgdE WvLJR5+6zStFSa111EPMAjI1VsKwIJvojJ1mKISmftjBPJPicOA+2jc7u s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAL2ABY/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR2BUweNLZcFkimCD4IIhiICgg44FAECAQEBAQEBAV4?= =?us-ascii?q?nhGEBAQEDAXkFCwIBCBguMiUCBA4FiEoIwwoBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdiDoIglCER4Mwgi8FmgYBj3+BboRniSCMeYN+AR42UoJ6HBmBOnKHNYEAAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.31,493,1473120000"; d="scan'208";a="159918211" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2016 13:08:06 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9ED86Eq029555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Oct 2016 13:08:06 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Oct 2016 09:08:05 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Fri, 14 Oct 2016 09:08:05 -0400 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSJX1b6MtzUuyRZUS84VuzdzWIraCn4VEAgABOwoA= Date: Fri, 14 Oct 2016 13:08:05 +0000 Message-ID: <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.44.242] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 13:08:09 -0000 > On Oct 14, 2016, at 2:26 AM, Magnus Westerlund wrote: >=20 > Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy): >>=20 >> I think this is huge complexity that is not currently supported and >> not needed. How about we generate the RID such that the RID for the >> n'th m line is n. Or generate it as a random number. Do you see any >> problem with this? >>=20 >> I think this removes all the fingerprinting issues. I'm fine with >> advice that say how to generate the RID in a way that is privacy >> sensitive but I'm not a fan of making RID require support for RTP >> header encryption. >>=20 >=20 > So, let disregard the fingerprinting issue for now. It is clear that I am= in the rough and that this whole issue would benefit from a broad review o= n what we leak when using ICE and RTP/RTCP. That broad review was largely done as part of PERC.=20 >=20 > What I don't understand here is that people have argued and agreed that w= e should encrypt the RTP and RTCP packets per default. Then when we comes t= o RTP header extensions we are no longer ready to provide that protection p= er default by ensuring RFC6904 implementation support. So RID and MID may n= ot be the most sensitive fields if it has well constructed values. Then we = have the audio level extensions where Client to mixer is RECOMMENDED to be = implemented and REQUIRES RFC6904. So the audio levels are recommended in WebRTC but this MID stuff is a very = generic mechanism that will like be broadly used to deal with RTP lack of e= xtensibility of size PT space. Lot of stuff does not implement audio levels= and some stuff that implements it does not encrypt it. The 6904 mechanism = is not exactly elegant, not easy to implement, and doubles the size the hea= ders which is not great for audio. I think it is fair to say we might do it= differently if doing it over again.=20 >=20 > So what is the issue, is it that you currently lack RFC6904 implementatio= ns, and thus this require more implementation work, or are there additional= reasons for wanting to expose this information? Yes this adds needless security complexity that people don't see the value = in thus it becomes difficult to convince implementors to do it. >=20 > To conclude, I personally think default usage of RFC6904 on header extens= ions would be a good thing. I currently see no reasons for changing the req= uirements that RFC 7941 puts on WebRTC, forcing the usage of RFC6904 encryp= tion. If you want to something else, please provide a proposal for what tha= t alternative would be. Originally MID was not a SDES items, I'd propose just moving it back to a n= ormal RTP Header. In looking at trying to use this in deployments, it's har= d to see what value transporting it in RTCP as well as RTP provided. When = that was originally proposed, I don't think anyone realized that mean encry= pting it and did not really care if it was normal or SDES as it was about t= he same work. But if SDES means it needs to be encrypted, then I think we n= eed to reconsider that.=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 From nobody Fri Oct 14 08:03:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208AC12983C for ; Fri, 14 Oct 2016 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no 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 EJp7OrZ8dr1J for ; Fri, 14 Oct 2016 08:03:07 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 BAE8F129831 for ; Fri, 14 Oct 2016 08:03:00 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9EExFF0016712; Fri, 14 Oct 2016 11:02:57 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 2615ba2563-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2016 11:02:57 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 14 Oct 2016 10:02:55 -0500 From: Jonathan Lennox To: Cullen Jennings Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSJX1b6MtzUuyRZUS84VuzdzWIraCn4VEAgABOwoCAADDZgA== Date: Fri, 14 Oct 2016 15:02:56 +0000 Message-ID: References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> In-Reply-To: <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_AD4526C1A878471E8713A7DF1813027Dvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610140268 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:03:12 -0000 --_000_AD4526C1A878471E8713A7DF1813027Dvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMTQsIDIwMTYsIGF0IDk6MDggQU0sIEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KSA8 Zmx1ZmZ5QGNpc2NvLmNvbTxtYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpTbyB0 aGUgYXVkaW8gbGV2ZWxzIGFyZSByZWNvbW1lbmRlZCBpbiBXZWJSVEMgYnV0IHRoaXMgTUlEIHN0 dWZmIGlzIGEgdmVyeSBnZW5lcmljIG1lY2hhbmlzbSB0aGF0IHdpbGwgbGlrZSBiZSBicm9hZGx5 IHVzZWQgdG8gZGVhbCB3aXRoIFJUUCBsYWNrIG9mIGV4dGVuc2liaWxpdHkgb2Ygc2l6ZSBQVCBz cGFjZS4gTG90IG9mIHN0dWZmIGRvZXMgbm90IGltcGxlbWVudCBhdWRpbyBsZXZlbHMgYW5kIHNv bWUgc3R1ZmYgdGhhdCBpbXBsZW1lbnRzIGl0IGRvZXMgbm90IGVuY3J5cHQgaXQuIFRoZSA2OTA0 IG1lY2hhbmlzbSBpcyBub3QgZXhhY3RseSBlbGVnYW50LCBub3QgZWFzeSB0byBpbXBsZW1lbnQs IGFuZCBkb3VibGVzIHRoZSBzaXplIHRoZSBoZWFkZXJzIHdoaWNoIGlzIG5vdCBncmVhdCBmb3Ig YXVkaW8uIEkgdGhpbmsgaXQgaXMgZmFpciB0byBzYXkgd2UgbWlnaHQgZG8gaXQgZGlmZmVyZW50 bHkgaWYgZG9pbmcgaXQgb3ZlciBhZ2Fpbi4NCg0KTm90IGVsZWdhbnQgaXMgYSBtYXR0ZXIgb2Yg dGFzdGUsIGJ1dCBJIGhhdmUgdG8gZGlzYWdyZWUgd2l0aCB5b3VyIG90aGVyIHR3byBjbGFpbXMg YWJvdXQgNjkwNC4NCg0KSXQgZG9lc27igJl0IGV4cGFuZCB0aGUgc2l6ZSBvZiB0aGUgUlRQIGhl YWRlciBleHRlbnNpb25zIGF0IGFsbCwgb3ZlciB3aGF0IHN0YW5kYXJkIDUyODUgaGVhZGVyIGV4 dGVuc2lvbnMgZG8uIChOb3csIDUyODUgaXRzZWxmIGlzIGZhaXJseSBzcGFjZS13YXN0ZWZ1bCwg YnV0IHRoYXTigJlzIGEgc2VwYXJhdGUgaXNzdWUuKQ0KDQpBbmQgSSBkb27igJl0IHRoaW5rIGl0 IHdhcyB2ZXJ5IGhhcmQgdG8gaW1wbGVtZW50LCBlaXRoZXIg4oCUIHRoZSBwYXRjaCB0byBhZGQg aXQgdG8gbGlic3J0cCBpcyBvbmx5IDgwMCBsaW5lcyBvZiBjb2RlIChodHRwczovL2dpdGh1Yi5j b20vY2lzY28vbGlic3J0cC9jb21taXQvY2UzN2VmNjE0NDQ0MDAzNzBmNjk5YzQ0OTg1OTQ5YmE0 NDU1N2QwMCksIG1vcmUgdGhhbiBoYWxmIG9mIHdoaWNoIGlzIHRlc3QgY2FzZXMuDQoNCkFyZSB5 b3UgYWN0dWFsbHkgY3JpdGljaXppbmcgdGhlIDUyODUgbWVjaGFuaXNtIGl0c2VsZj8NCg0K4oCU DQpKb25hdGhhbiBMZW5ub3gNCmpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5Admlk eW8uY29tPg0KDQoNCg== --_000_AD4526C1A878471E8713A7DF1813027Dvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3Qg MTQsIDIwMTYsIGF0IDk6MDggQU0sIEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZsdWZmeUBjaXNjby5jb20iIGNsYXNzPSIiPmZsdWZmeUBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NClNvIHRoZSBhdWRpbyBsZXZlbHMgYXJlIHJlY29tbWVuZGVkIGluIFdlYlJUQyBidXQg dGhpcyBNSUQgc3R1ZmYgaXMgYSB2ZXJ5IGdlbmVyaWMgbWVjaGFuaXNtIHRoYXQgd2lsbCBsaWtl IGJlIGJyb2FkbHkgdXNlZCB0byBkZWFsIHdpdGggUlRQIGxhY2sgb2YgZXh0ZW5zaWJpbGl0eSBv ZiBzaXplIFBUIHNwYWNlLiBMb3Qgb2Ygc3R1ZmYgZG9lcyBub3QgaW1wbGVtZW50IGF1ZGlvIGxl dmVscyBhbmQgc29tZSBzdHVmZiB0aGF0IGltcGxlbWVudHMNCiBpdCBkb2VzIG5vdCBlbmNyeXB0 IGl0LiBUaGUgNjkwNCBtZWNoYW5pc20gaXMgbm90IGV4YWN0bHkgZWxlZ2FudCwgbm90IGVhc3kg dG8gaW1wbGVtZW50LCBhbmQgZG91YmxlcyB0aGUgc2l6ZSB0aGUgaGVhZGVycyB3aGljaCBpcyBu b3QgZ3JlYXQgZm9yIGF1ZGlvLiBJIHRoaW5rIGl0IGlzIGZhaXIgdG8gc2F5IHdlIG1pZ2h0IGRv IGl0IGRpZmZlcmVudGx5IGlmIGRvaW5nIGl0IG92ZXIgYWdhaW4uDQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Tm90IGVsZWdhbnQgaXMgYSBtYXR0ZXIgb2YgdGFzdGUsIGJ1dCBJIGhhdmUgdG8gZGlz YWdyZWUgd2l0aCB5b3VyIG90aGVyIHR3byBjbGFpbXMgYWJvdXQgNjkwNC48L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pkl0IGRvZXNu4oCZdCBleHBhbmQgdGhlIHNpemUg b2YgdGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyBhdCBhbGwsIG92ZXIgd2hhdCBzdGFuZGFyZCA1 Mjg1IGhlYWRlciBleHRlbnNpb25zIGRvLiAoTm93LCA1Mjg1IGl0c2VsZiBpcyBmYWlybHkgc3Bh Y2Utd2FzdGVmdWwsIGJ1dCB0aGF04oCZcyBhIHNlcGFyYXRlIGlzc3VlLik8L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgd2FzIHZl cnkgaGFyZCB0byBpbXBsZW1lbnQsIGVpdGhlciDigJQgdGhlIHBhdGNoIHRvIGFkZCBpdCB0byBs aWJzcnRwIGlzIG9ubHkgODAwIGxpbmVzIG9mIGNvZGUgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9jaXNjby9saWJzcnRwL2NvbW1pdC9jZTM3ZWY2MTQ0NDQwMDM3MGY2OTljNDQ5ODU5NDli YTQ0NTU3ZDAwIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vY2lzY28vbGlic3J0cC9jb21t aXQvY2UzN2VmNjE0NDQ0MDAzNzBmNjk5YzQ0OTg1OTQ5YmE0NDU1N2QwMDwvYT4pLA0KIG1vcmUg dGhhbiBoYWxmIG9mIHdoaWNoIGlzIHRlc3QgY2FzZXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5BcmUgeW91IGFjdHVhbGx5IGNyaXRpY2l6aW5nIHRoZSA1Mjg1IG1l Y2hhbmlzbSBpdHNlbGY/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj7i gJQmbmJzcDs8L2Rpdj4NCjxkaXY+Sm9uYXRoYW4gTGVubm94PC9kaXY+DQo8ZGl2PjxhIGhyZWY9 Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIGNsYXNzPSIiPmpvbmF0aGFuQHZpZHlvLmNvbTwv YT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD4526C1A878471E8713A7DF1813027Dvidyocom_-- From nobody Mon Oct 17 01:46:51 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE62212947F for ; Mon, 17 Oct 2016 01:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H41RHXr4BrRA for ; Mon, 17 Oct 2016 01:46:46 -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 9F1E612956D for ; Mon, 17 Oct 2016 01:46:46 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-e3-58048ff48156 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 09.D4.02551.4FF84085; Mon, 17 Oct 2016 10:46:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.319.2; Mon, 17 Oct 2016 10:46:37 +0200 To: "Cullen Jennings (fluffy)" References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> From: Magnus Westerlund Message-ID: <9d7c976f-ad3c-4731-1447-c2eaa934d711@ericsson.com> Date: Mon, 17 Oct 2016 10:46:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2K7me7XfpYIgz3PWS06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTw88p6pYKF2xZIfKxgbGDcpdTFyckgImEh8 3r2PrYuRi0NIYD2jxOMnHewQznJGiabdDUwgVcICCRK/5nxgBLFFBAwlmvbMY4Ious0ocXnH TTaQBLOAosSX5fPBbDYBC4mbPxrBbF4Be4kN92aB2SwCqhJ3bk0FGyoqECNx/dkjqBpBiZMz n7B0MXJwcArYShz+wwpiMgO1PthaBjFdXqJ562xmEFtIQFuioamDdQKjwCwkzbMQOmYh6VjA yLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzAkD275rbuDcfVrx0OMAhyMSjy8D5YxRQix JpYVV+YeYpTgYFYS4X1fwxIhxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTU gtQimCwTB6dUA+OSxoyA/AVKJ2Rbv+ztk+wW89D7t1DoipOPptT8rb+++aV+EGhwq+J5/8xX M2XGExH2w6FxjWe23/jVbsFSzHFNNS5g1mPFE6u+Hps61+jtDWft2SK5xvFzRF+sCO65+LBj ZuGMIEfl+N3sTpWbbq+Qr3+qsm21kE9S3Jun7qnnD02v3GT5Ok2JpTgj0VCLuag4EQAkw/eY RQIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 08:46:50 -0000 Den 2016-10-14 kl. 15:08, skrev Cullen Jennings (fluffy): > >> On Oct 14, 2016, at 2:26 AM, Magnus Westerlund >> wrote: >> >> Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy): >>> >>> I think this is huge complexity that is not currently supported >>> and not needed. How about we generate the RID such that the RID >>> for the n'th m line is n. Or generate it as a random number. Do >>> you see any problem with this? >>> >>> I think this removes all the fingerprinting issues. I'm fine >>> with advice that say how to generate the RID in a way that is >>> privacy sensitive but I'm not a fan of making RID require support >>> for RTP header encryption. >>> >> >> So, let disregard the fingerprinting issue for now. It is clear >> that I am in the rough and that this whole issue would benefit from >> a broad review on what we leak when using ICE and RTP/RTCP. > > That broad review was largely done as part of PERC. > I do not agree that review happened in that context. I can't remember that we discussed fingerprinting at all. We quickly put any effort of privacy in regards to that the communication occurs out of scope. All the focus in PERC is to my understanding on maintaining confidentiality of the media content as well as preventing third party injection, modifications (other than sub selection of content) and replay attacks. >> >> What I don't understand here is that people have argued and agreed >> that we should encrypt the RTP and RTCP packets per default. Then >> when we comes to RTP header extensions we are no longer ready to >> provide that protection per default by ensuring RFC6904 >> implementation support. So RID and MID may not be the most >> sensitive fields if it has well constructed values. Then we have >> the audio level extensions where Client to mixer is RECOMMENDED to >> be implemented and REQUIRES RFC6904. > > So the audio levels are recommended in WebRTC but this MID stuff is a > very generic mechanism that will like be broadly used to deal with > RTP lack of extensibility of size PT space. Lot of stuff does not > implement audio levels and some stuff that implements it does not > encrypt it. The 6904 mechanism is not exactly elegant, not easy to > implement, and doubles the size the headers which is not great for > audio. I think it is fair to say we might do it differently if doing > it over again. > I think Jonathan had an excellent reply on this. >> >> So what is the issue, is it that you currently lack RFC6904 >> implementations, and thus this require more implementation work, or >> are there additional reasons for wanting to expose this >> information? > > Yes this adds needless security complexity that people don't see the > value in thus it becomes difficult to convince implementors to do > it. > >> >> To conclude, I personally think default usage of RFC6904 on header >> extensions would be a good thing. I currently see no reasons for >> changing the requirements that RFC 7941 puts on WebRTC, forcing the >> usage of RFC6904 encryption. If you want to something else, please >> provide a proposal for what that alternative would be. > > Originally MID was not a SDES items, I'd propose just moving it back > to a normal RTP Header. In looking at trying to use this in > deployments, it's hard to see what value transporting it in RTCP as > well as RTP provided. When that was originally proposed, I don't > think anyone realized that mean encrypting it and did not really care > if it was normal or SDES as it was about the same work. But if SDES > means it needs to be encrypted, then I think we need to reconsider > that. > So, I think moving away from SDES item is a bad idea. As that would create additional implementation burden, rather than having the same processing for a number of SDES items of similar type. RID, MID and CNAME all need similar processing for initial startup handling. So moving RID out, while still having the other two just creates an additional cases to implement. When it comes to RTCP inclusion of these SDES items I know of two reasons. Reason one, is that one can actually use RTCP to send these for an SSRC prior to having RTP data to send for it. That enables one to have the association in place prior to actually having to handle media data. Reason two is the saftey net RTCP provides. It enables a receiver to detect if its state is out of sync. Yes, this could be realized using periodic repeats in the RTP header extension also. However, that doesn't work if the SSRC currently don't have any data to send. Considering the state that draft-ietf-avtext-rid is in. Deciding to change it to not be an SDES item is going be an equal if not greater hassle to actually pull it back to the WG to include a beef up of the security consdieration with an motivation why the rules in RFC7941 do not apply to it. Assuming that is what the consensus ends up being. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Oct 18 06:28:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6972129650 for ; Tue, 18 Oct 2016 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUW0RxcVSzyp for ; Tue, 18 Oct 2016 06:28:54 -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 A996312964D for ; Tue, 18 Oct 2016 06:28:53 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-44-58062392ac0d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 11.C1.02458.29326085; Tue, 18 Oct 2016 15:28:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 15:28:50 +0200 From: Christer Holmberg To: Magnus Westerlund , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSH9lMExaUQsC7kESlGYxjwYhpQqCmmXwAgADuiACAAE7CgIAEbfAAgAIVZQA= Date: Tue, 18 Oct 2016 13:28:50 +0000 Message-ID: References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> <9d7c976f-ad3c-4731-1447-c2eaa934d711@ericsson.com> In-Reply-To: <9d7c976f-ad3c-4731-1447-c2eaa934d711@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <036EFCC56A869C4EA8BE4E954E34F774@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7ru5kZbYIg91brSz2/F3EbtExmc3i 2vLXrBZr/7WzW+yc28HswOox5fdGVo+ds+6yeyzYVOqxZMlPJo9ZO5+wBLBGcdmkpOZklqUW 6dslcGVc3reGseC6fkVry3LWBsaNal2MnBwSAiYSZzo+MXYxcnEICaxnlDj4ZhkzhLOYUWLy 3MtMXYwcHGwCFhLd/7RBGkQE0iVmf7sEVsMMUtM1dycbSEJYIEHi15wPjBBFiRLNt/uYIWw/ ic2T/zKB2CwCqhIn9vWzgNi8AtYSL57MYoJYNpFJ4kH3KbAiTgEHiVnnP4LZjAJiEt9PrQGz mQXEJW49mc8EcbaAxJI955khbFGJl4//sYIcKiqgJ7HmfhhEWFGi/WkDI0SrnsSNqVPYIGxr iU+TJkDZ2hLLFr5mhrhHUOLkzCcsExjFZyHZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCkHtzy22oH48HnjocYBTgYlXh4E26yRAixJpYVV+YeYpTgYFYS 4WVWYosQ4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgTGf 08JWjElXPKlzleqkxTPPpD30s1Wq4KjxdC01vVrcuHGB7tUXd1LOLYpZeMlgToV7mcaB8juF WqkzeDbOFXcIrXBK094XMV11piVb3ZzZphd2LlhY+UfksIXyvd0np53TrZO5qfpndaDguvML 9ywXOCSyzOaeOnNfgOl8fcuWdOZSFrVPx5RYijMSDbWYi4oTAcWEI57QAgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:28:55 -0000 Hi, draft-ietf-avtext-rid also talks about encryption, and references RFC 7201. Any input from the authors of that document? Adam? Suhas? Peter? Regards, Christer On 17/10/16 11:46, "rtcweb on behalf of Magnus Westerlund" wrote: >Den 2016-10-14 kl. 15:08, skrev Cullen Jennings (fluffy): >> >>> On Oct 14, 2016, at 2:26 AM, Magnus Westerlund >>> wrote: >>> >>> Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy): >>>> >>>> I think this is huge complexity that is not currently supported >>>> and not needed. How about we generate the RID such that the RID >>>> for the n'th m line is n. Or generate it as a random number. Do >>>> you see any problem with this? >>>> >>>> I think this removes all the fingerprinting issues. I'm fine >>>> with advice that say how to generate the RID in a way that is >>>> privacy sensitive but I'm not a fan of making RID require support >>>> for RTP header encryption. >>>> >>> >>> So, let disregard the fingerprinting issue for now. It is clear >>> that I am in the rough and that this whole issue would benefit from >>> a broad review on what we leak when using ICE and RTP/RTCP. >> >> That broad review was largely done as part of PERC. >> > >I do not agree that review happened in that context. I can't remember >that we discussed fingerprinting at all. We quickly put any effort of >privacy in regards to that the communication occurs out of scope. All >the focus in PERC is to my understanding on maintaining confidentiality >of the media content as well as preventing third party injection, >modifications (other than sub selection of content) and replay attacks. > > > >>> >>> What I don't understand here is that people have argued and agreed >>> that we should encrypt the RTP and RTCP packets per default. Then >>> when we comes to RTP header extensions we are no longer ready to >>> provide that protection per default by ensuring RFC6904 >>> implementation support. So RID and MID may not be the most >>> sensitive fields if it has well constructed values. Then we have >>> the audio level extensions where Client to mixer is RECOMMENDED to >>> be implemented and REQUIRES RFC6904. >> >> So the audio levels are recommended in WebRTC but this MID stuff is a >> very generic mechanism that will like be broadly used to deal with >> RTP lack of extensibility of size PT space. Lot of stuff does not >> implement audio levels and some stuff that implements it does not >> encrypt it. The 6904 mechanism is not exactly elegant, not easy to >> implement, and doubles the size the headers which is not great for >> audio. I think it is fair to say we might do it differently if doing >> it over again. >> > >I think Jonathan had an excellent reply on this. > >>> >>> So what is the issue, is it that you currently lack RFC6904 >>> implementations, and thus this require more implementation work, or >>> are there additional reasons for wanting to expose this >>> information? >> >> Yes this adds needless security complexity that people don't see the >> value in thus it becomes difficult to convince implementors to do >> it. >> >>> >>> To conclude, I personally think default usage of RFC6904 on header >>> extensions would be a good thing. I currently see no reasons for >>> changing the requirements that RFC 7941 puts on WebRTC, forcing the >>> usage of RFC6904 encryption. If you want to something else, please >>> provide a proposal for what that alternative would be. >> >> Originally MID was not a SDES items, I'd propose just moving it back >> to a normal RTP Header. In looking at trying to use this in >> deployments, it's hard to see what value transporting it in RTCP as >> well as RTP provided. When that was originally proposed, I don't >> think anyone realized that mean encrypting it and did not really care >> if it was normal or SDES as it was about the same work. But if SDES >> means it needs to be encrypted, then I think we need to reconsider >> that. >> > >So, I think moving away from SDES item is a bad idea. As that would >create additional implementation burden, rather than having the same >processing for a number of SDES items of similar type. RID, MID and >CNAME all need similar processing for initial startup handling. So >moving RID out, while still having the other two just creates an >additional cases to implement. > >When it comes to RTCP inclusion of these SDES items I know of two reasons. > >Reason one, is that one can actually use RTCP to send these for an SSRC >prior to having RTP data to send for it. That enables one to have the >association in place prior to actually having to handle media data. > >Reason two is the saftey net RTCP provides. It enables a receiver to >detect if its state is out of sync. Yes, this could be realized using >periodic repeats in the RTP header extension also. However, that doesn't >work if the SSRC currently don't have any data to send. > >Considering the state that draft-ietf-avtext-rid is in. Deciding to >change it to not be an SDES item is going be an equal if not greater >hassle to actually pull it back to the WG to include a beef up of the >security consdieration with an motivation why the rules in RFC7941 do >not apply to it. Assuming that is what the consensus ends up being. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Oct 18 09:28:31 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71B129550 for ; Tue, 18 Oct 2016 09:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-Xo14mrVUAt for ; Tue, 18 Oct 2016 09:28:29 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92701296EA for ; Tue, 18 Oct 2016 09:28:23 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id t73so256838291oie.1 for ; Tue, 18 Oct 2016 09:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=DpcEEyN/YrmtWeteCLwpI4M985oe49N5XbCb9vDvXXc=; b=GFS8f5oF8hmP1Flu+wrKLnZ7Re4kEJxl+OCdY0TIDvWqYFwLnTZh5cP7S09sfWh2uV 07KBAvx3nAUSgYf0sNeH0Xtix/nlxS1DsQncmc+huuwD/9j5Cmi02KWUTKtpYllMLDi+ qN0CCCjP/x5MY09Txcc6sMHxDjLQeV+sZ5wZ8CrTpaafMfwtnIR3mw8BzwYdXaeKh0JU K0fpJOaZue7j9LRlv+fdw9P2uENLjY93X9i+7L1zUg8Zj8W7xScRMlLyseJLwnJhKP9K 3bzFOYn8irBPPl7RuW8iEp7FqthvK3w9iXb+q+JisbGLRIhbusoswNRl4fXRoXvIUmCm ExIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DpcEEyN/YrmtWeteCLwpI4M985oe49N5XbCb9vDvXXc=; b=H62p5mb7awj44FXAPeC3gBzf1bNv6a+lV4M1+1yanSXxBq420JyVLfWKbBfv7rujQ6 uvL8MACJ8E5OElrEjcYBo8ywE8oPF61PFafK0XsNF79/U9T7lVvuvq4k5GpcUusU5/Fd QehDmWzH6/pf4hLXW3BF1b/h/VBltPrQ3jPEGnZzGfJ/j2Rb2C6Jby1AWuln4Jq0cnh1 houx5y1oF1deqJMzqkt1NOQfsMObPB4uR6kk7MNxQ5v5rVX4vbSP2YjkfcrKMukfwpoB u7TcBqTAAXfsAhqpDjEG/sWo3pbQBCyT90QcgBlkRrItmVyeHuutn93jsqJrRu+wIu/j a+5A== X-Gm-Message-State: AA6/9Rl/te3fTdnia+3iztiCXjNMJWWtxEimd4sSfBClIeP/P6qw2vbbMxD2aGf07GJWoWrqF8QhbRL4GGkINw== X-Received: by 10.202.49.204 with SMTP id x195mr1016122oix.87.1476808102966; Tue, 18 Oct 2016 09:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.5 with HTTP; Tue, 18 Oct 2016 09:27:52 -0700 (PDT) From: Ted Hardie Date: Tue, 18 Oct 2016 09:27:52 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113cabd860fa72053f262edb Archived-At: Subject: [rtcweb] Agenda requests for IETF 97 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:28:30 -0000 --001a113cabd860fa72053f262edb Content-Type: text/plain; charset=UTF-8 Howdy, The chairs are currently putting together the draft agenda for Seoul. We expect the lion's share will go to JSEP, as we hope to have a WG last call issued before the meeting. We have also received an agenda request for adraft-copeland-rtcweb-p2p-idp-auth; if you have other agenda items to request time for, please let us or the list know. thanks, Ted --001a113cabd860fa72053f262edb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

The chairs are currentl= y putting together the draft agenda for Seoul.=C2=A0 We expect the lion'= ;s share will go to JSEP, as we hope to have a WG last call issued before t= he meeting.=C2=A0 We have also received an agenda request for adraft-copela= nd-rtcweb-p2p-idp-auth; if you have other agenda items to request time for,= please let us or the list know.

thanks,

Ted
<= /div> --001a113cabd860fa72053f262edb-- From nobody Tue Oct 18 10:14:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBC212962F for ; Tue, 18 Oct 2016 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21kTfjsw_TVH for ; Tue, 18 Oct 2016 10:14:52 -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 73ACF129559 for ; Tue, 18 Oct 2016 10:14:52 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-da-580658896a58 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id B0.0B.02458.98856085; Tue, 18 Oct 2016 19:14:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 19:14:49 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Agenda requests for IETF 97 Thread-Index: AQHSKVysZW9fCQ7CdUatEn09Bs/lEKCucu6g Date: Tue, 18 Oct 2016 17:14:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BDB3668@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BDB3668ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbE9Srcrgi3C4PldU4u1/9rZLRrn2jkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGRs3HWMquGdRcevHZMYGxgnmXYycHBICJhLT Pn5j72Lk4hASWM8osWjrcyhnMaPEzIt3WLsYOTjYBCwkuv9pgzSICHhIbPr7mxXEFhYwlLjc MQWsRETASGJiXz5EiZHE9M+7WEBsFgFViUfvn4LZvAK+El++XWAHKRcSCJCYuU0HxOQUCJTY fsYKpIJRQEzi+6k1TCA2s4C4xK0n85kgrhSQWLLnPDOELSrx8vE/VghbSWLR7c9MIGOYBfIl pn/Ig1gkKHFy5hOWCYzCs5BMmoVQNQtJFURYU2L9Ln2IakWJKd0P2SFsDYnWOXPZkcUXMLKv YhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMmINbflvtYDz43PEQowAHoxIPb8JNlggh1sSy 4srcQ4wSHMxKIrwiIWwRQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgt gskycXBKNTD2XDJOe6qexSi3c99dlp0RHK99O3qUv8geSF1xUFwyr2U22zEJ6bPHj56SvKQt cOm45AIzDeM9BarzbpeIr3/9qcP+sfnKxpu7DigH1c5dUvPmBO80lYA6HV+vsxwts7metLJN sWf4oMlZVefbvkRxyVQF251zHp/NaZXasHzq3YV5/tq1Kh1KLMUZiYZazEXFiQBcooZulAIA AA== Archived-At: Subject: Re: [rtcweb] Agenda requests for IETF 97 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:14:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BDB3668ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgKlJFQUxMWSogaG9wZSB3ZeKAmWxsIGJlIGFibGUgdG8gc29sdmUgdGhlIFJJRC9N SUQvU0RFUyBzZWN1cml0eSBpc3N1ZSBiZWZvcmUgS29yZWEsIGJ1dCBvdGhlcndpc2Ugd2Ugc2hv dWxkIGRlZmluaXRlbHkgdHJ5IHRvIHNvbHZlIHRoYXQgYXQgdGhlIG1lZXRpbmcuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogMTggT2N0b2JlciAyMDE2IDE5 OjI4DQpUbzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBBZ2VuZGEgcmVxdWVz dHMgZm9yIElFVEYgOTcNCg0KSG93ZHksDQpUaGUgY2hhaXJzIGFyZSBjdXJyZW50bHkgcHV0dGlu ZyB0b2dldGhlciB0aGUgZHJhZnQgYWdlbmRhIGZvciBTZW91bC4gIFdlIGV4cGVjdCB0aGUgbGlv bidzIHNoYXJlIHdpbGwgZ28gdG8gSlNFUCwgYXMgd2UgaG9wZSB0byBoYXZlIGEgV0cgbGFzdCBj YWxsIGlzc3VlZCBiZWZvcmUgdGhlIG1lZXRpbmcuICBXZSBoYXZlIGFsc28gcmVjZWl2ZWQgYW4g YWdlbmRhIHJlcXVlc3QgZm9yIGFkcmFmdC1jb3BlbGFuZC1ydGN3ZWItcDJwLWlkcC1hdXRoOyBp ZiB5b3UgaGF2ZSBvdGhlciBhZ2VuZGEgaXRlbXMgdG8gcmVxdWVzdCB0aW1lIGZvciwgcGxlYXNl IGxldCB1cyBvciB0aGUgbGlzdCBrbm93Lg0KdGhhbmtzLA0KVGVkDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BDB3668ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSAqPGI+UkVBTExZPC9iPiogaG9wZSB3 ZeKAmWxsIGJlIGFibGUgdG8gc29sdmUgdGhlIFJJRC9NSUQvU0RFUyBzZWN1cml0eSBpc3N1ZSBi ZWZvcmUgS29yZWEsIGJ1dCBvdGhlcndpc2Ugd2Ugc2hvdWxkIGRlZmluaXRlbHkgdHJ5DQogdG8g c29sdmUgdGhhdCBhdCB0aGUgbWVldGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIEhh cmRpZTxicj4NCjxiPlNlbnQ6PC9iPiAxOCBPY3RvYmVyIDIwMTYgMTk6Mjg8YnI+DQo8Yj5Ubzo8 L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBBZ2VuZGEg cmVxdWVzdHMgZm9yIElFVEYgOTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhvd2R5 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlRoZSBjaGFpcnMgYXJlIGN1cnJlbnRseSBwdXR0aW5nIHRvZ2V0 aGVyIHRoZSBkcmFmdCBhZ2VuZGEgZm9yIFNlb3VsLiZuYnNwOyBXZSBleHBlY3QgdGhlIGxpb24n cyBzaGFyZSB3aWxsIGdvIHRvIEpTRVAsIGFzIHdlIGhvcGUgdG8gaGF2ZSBhIFdHIGxhc3QgY2Fs bCBpc3N1ZWQgYmVmb3JlIHRoZSBtZWV0aW5nLiZuYnNwOyBXZSBoYXZlIGFsc28gcmVjZWl2ZWQg YW4gYWdlbmRhDQogcmVxdWVzdCBmb3IgYWRyYWZ0LWNvcGVsYW5kLXJ0Y3dlYi1wMnAtaWRwLWF1 dGg7IGlmIHlvdSBoYXZlIG90aGVyIGFnZW5kYSBpdGVtcyB0byByZXF1ZXN0IHRpbWUgZm9yLCBw bGVhc2UgbGV0IHVzIG9yIHRoZSBsaXN0IGtub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+dGhhbmtzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BDB3668ESESSMB209erics_-- From nobody Thu Oct 20 12:56:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0394129417 for ; Thu, 20 Oct 2016 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI-ak5PiteUV for ; Thu, 20 Oct 2016 12:56:55 -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 E95FC129423 for ; Thu, 20 Oct 2016 12:56:54 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-1b-580921853c65 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 9C.E4.02458.48129085; Thu, 20 Oct 2016 21:56:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 21:56:51 +0200 From: Christer Holmberg To: Magnus Westerlund , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items Thread-Index: AQHSH9lMExaUQsC7kESlGYxjwYhpQqCmmXwAgADuiACAAE7CgIAEbfAAgAWTWCA= Date: Thu, 20 Oct 2016 19:56:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BDC0CF2@ESESSMB209.ericsson.se> References: <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com> <9d7c976f-ad3c-4731-1447-c2eaa934d711@ericsson.com> In-Reply-To: <9d7c976f-ad3c-4731-1447-c2eaa934d711@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7im6rImeEwbLN4hYdk9ks1v5rZ3dg 8pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mj5NbGYsmGVYMfHhFLYGxuPqXYycHBICJhKX Xy9hB7GFBNYzSiw8It7FyAVkL2aU2PDxNVMXIwcHm4CFRPc/bZAaEYF0idnfLjGD2MwCihJf ls9nA7GFBRIkds2bzAJRkyjRfLuPGcL2k1i98QDYfBYBVYmOaWcZQWxeAV+JVX2HmSF2TWSS eNB9igkkwSngIDHr/Ecwm1FATOL7qTVMEMvEJW49mc8EcbSAxJI955khbFGJl4//sULYShJr D29ngajXk7gxdQobhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTi 4tx0IyO91KLM5OLi/Dy9vNSSTYzAKDm45bfVDsaDzx0PMQpwMCrx8D54wx4hxJpYVlyZe4hR goNZSYR3sTxnhBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTByc Ug2MqffrzXtZJuzP7uTPn+X49cmp91fDX02+6zm34QJfdK7RkuxiYbYjdREPW0we/fDlnnkr 4tjFv2vV7sUuuma5tq3z+5mF3utPb17ZWDZnQ/SKhAWbj7OdWnJd1n/RH5XiItaUw0ddVpTe ehFVdGfpFhNbbTVzs67dvbMavOXs7Fc5WzzTXF12VImlOCPRUIu5qDgRAIZU4AOOAgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:56:58 -0000 Hi, I'd like some guidance on how to move forward and try to solve this issue. = I really don't want us to switch to another mechanism at this point. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlun= d Sent: 17 October 2016 11:47 To: Cullen Jennings (fluffy) Cc: RTCWeb IETF Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID= and RID SDES items Den 2016-10-14 kl. 15:08, skrev Cullen Jennings (fluffy): > >> On Oct 14, 2016, at 2:26 AM, Magnus Westerlund=20 >> wrote: >> >> Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy): >>> >>> I think this is huge complexity that is not currently supported and=20 >>> not needed. How about we generate the RID such that the RID for the=20 >>> n'th m line is n. Or generate it as a random number. Do you see any=20 >>> problem with this? >>> >>> I think this removes all the fingerprinting issues. I'm fine with=20 >>> advice that say how to generate the RID in a way that is privacy=20 >>> sensitive but I'm not a fan of making RID require support for RTP=20 >>> header encryption. >>> >> >> So, let disregard the fingerprinting issue for now. It is clear that=20 >> I am in the rough and that this whole issue would benefit from a=20 >> broad review on what we leak when using ICE and RTP/RTCP. > > That broad review was largely done as part of PERC. > I do not agree that review happened in that context. I can't remember that = we discussed fingerprinting at all. We quickly put any effort of privacy in= regards to that the communication occurs out of scope. All the focus in PE= RC is to my understanding on maintaining confidentiality of the media conte= nt as well as preventing third party injection, modifications (other than s= ub selection of content) and replay attacks. >> >> What I don't understand here is that people have argued and agreed=20 >> that we should encrypt the RTP and RTCP packets per default. Then=20 >> when we comes to RTP header extensions we are no longer ready to=20 >> provide that protection per default by ensuring RFC6904=20 >> implementation support. So RID and MID may not be the most sensitive=20 >> fields if it has well constructed values. Then we have the audio=20 >> level extensions where Client to mixer is RECOMMENDED to be=20 >> implemented and REQUIRES RFC6904. > > So the audio levels are recommended in WebRTC but this MID stuff is a=20 > very generic mechanism that will like be broadly used to deal with RTP=20 > lack of extensibility of size PT space. Lot of stuff does not=20 > implement audio levels and some stuff that implements it does not=20 > encrypt it. The 6904 mechanism is not exactly elegant, not easy to=20 > implement, and doubles the size the headers which is not great for=20 > audio. I think it is fair to say we might do it differently if doing=20 > it over again. > I think Jonathan had an excellent reply on this. >> >> So what is the issue, is it that you currently lack RFC6904=20 >> implementations, and thus this require more implementation work, or=20 >> are there additional reasons for wanting to expose this information? > > Yes this adds needless security complexity that people don't see the=20 > value in thus it becomes difficult to convince implementors to do it. > >> >> To conclude, I personally think default usage of RFC6904 on header=20 >> extensions would be a good thing. I currently see no reasons for=20 >> changing the requirements that RFC 7941 puts on WebRTC, forcing the=20 >> usage of RFC6904 encryption. If you want to something else, please=20 >> provide a proposal for what that alternative would be. > > Originally MID was not a SDES items, I'd propose just moving it back=20 > to a normal RTP Header. In looking at trying to use this in=20 > deployments, it's hard to see what value transporting it in RTCP as=20 > well as RTP provided. When that was originally proposed, I don't=20 > think anyone realized that mean encrypting it and did not really care=20 > if it was normal or SDES as it was about the same work. But if SDES=20 > means it needs to be encrypted, then I think we need to reconsider=20 > that. > So, I think moving away from SDES item is a bad idea. As that would create = additional implementation burden, rather than having the same processing fo= r a number of SDES items of similar type. RID, MID and CNAME all need simil= ar processing for initial startup handling. So moving RID out, while still = having the other two just creates an additional cases to implement. When it comes to RTCP inclusion of these SDES items I know of two reasons. Reason one, is that one can actually use RTCP to send these for an SSRC pri= or to having RTP data to send for it. That enables one to have the associat= ion in place prior to actually having to handle media data. Reason two is the saftey net RTCP provides. It enables a receiver to detect= if its state is out of sync. Yes, this could be realized using periodic re= peats in the RTP header extension also. However, that doesn't work if the S= SRC currently don't have any data to send. Considering the state that draft-ietf-avtext-rid is in. Deciding to change = it to not be an SDES item is going be an equal if not greater hassle to act= ually pull it back to the WG to include a beef up of the security consdiera= tion with an motivation why the rules in RFC7941 do not apply to it. Assumi= ng that is what the consensus ends up being. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 21 11:03:36 2016 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 D7FE51294C0; Fri, 21 Oct 2016 11:03:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147707301487.28145.3793735303307641632.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 11:03:34 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-17.txt Pages : 94 Date : 2016-10-21 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-17 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 21 12:26:36 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44112948F for ; Fri, 21 Oct 2016 12:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CAQyJ2rjSGw for ; Fri, 21 Oct 2016 12:26:31 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98C612946B for ; Fri, 21 Oct 2016 12:26:30 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u124so111731742ywg.3 for ; Fri, 21 Oct 2016 12:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=pQj62limJH2vLO5UYC/OHKcddY/NAUpx514pCigWd6A=; b=LEUIp8Qw0K8XonYlxG+evgbWKEAxm8dKiwQV7KCr09vhKl2DeutIJuiVUwDszTC6Pk wl6czTiMns3Kx1ytapNsRWE0sw83tjVN0m0tg2RvyeoI/KhAUEDTALBZPHlE5WpSY/+0 RFkHgcEyboZvZn2jr/Hdecwpn6oJhbvlFIUiylcrQI7fYUTY9FrkVRTZbMCpyjzMTqYq v4QfJXDvuPJexhjnZTjWCKl29IfzS+qyX4OBQ2PuQiuVSWNOSyOw7vU2jloKKtvj2tkw FT8YwCaC2PKpLQ0dIdrl47mMElP963+N9TVDPgAnRSH3dJhNH9gdBepXTsYeWqAb05Pd az/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pQj62limJH2vLO5UYC/OHKcddY/NAUpx514pCigWd6A=; b=lr/MTVcc08/xKQpJemaQE/HA3lFFvMYIO6o42K4lvE5frtvi4KlkLriTd7o9i1sRSI QS5mEupYFHDI4sWk1byBqgN3ByXcbGXbVXBNCgtyn2gH6L+f1YHNMiUbIXyD0cWaOXlV /nOHISbRfyPJgADYj20zV/MVoK1NsVa3NWzt+WbcXQwtmpCvhfrGgKsORP9zAGxmn/LG oT3dp6ZCtac/+7oyd5WD05qmXX18iTPWJsX1ZlDqueqvHDPX/gmC3WbGtP9ipTZTaz6t 40StRQLxog3szJHNTJgGrAYvu+nAhK/jXZYPSxbjKeloB0m2ryfq+1ekH08SqJXCRG5p GXfg== X-Gm-Message-State: AA6/9RmqZe/j+wDvsqwq3Z/Y1FGpgJaS7b6waNhd7P+3No/B+amQNJvw+898y0X2c0NBs3WMbSMvACeoDtMTgg== X-Received: by 10.202.236.149 with SMTP id k143mr5608720oih.127.1477077990052; Fri, 21 Oct 2016 12:26:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.5 with HTTP; Fri, 21 Oct 2016 12:25:59 -0700 (PDT) From: Ted Hardie Date: Fri, 21 Oct 2016 12:25:59 -0700 Message-ID: To: "rtcweb@ietf.org" , Alissa Cooper , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a1134e308e71835053f6504b3 Archived-At: Subject: [rtcweb] Working Group Last Call: JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 19:26:35 -0000 --001a1134e308e71835053f6504b3 Content-Type: text/plain; charset=UTF-8 The chairs would like to start a working group last call on draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. Please review thoroughly, as working through the last comments will be the major effort of our working group meeting in Seoul. >From a process perspective, we will be working through the comments as issues against the github repo. In order to accommodate folks who do not use github, the chairs will enter a new issue for any issue raised on the mailing list. That means that if you are raising a new issue, please send it to the list with a new subject line so that the chairs catch it. If you prefer, you may also enter the issues at https://github.com/rtcweb-wg/jsep. If you do so, please send a copy of the issue to the mailing list so that conversation and resolution occurs here. This has been a long road, but this a very major milestone. Thanks to the authors for their work so far. regards, Ted, Cullen, Sean A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-17.txt Pages : 94 Date : 2016-10-21 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-17 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 --001a1134e308e71835053f6504b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs would like to start a working group l= ast call on draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 K= ST.
=C2=A0
Please review thoroughly, as working through the last com= ments will be the major effort of our working group meeting in Seoul.
From a process perspective, we will be working through the comments= as issues against the github repo.=C2=A0 In order to accommodate folks who= do not use github, the chairs will enter a new issue for any issue raised = on the mailing list.=C2=A0 That means that if you are raising a new issue, = please send it to the list with a new subject line so that the chairs catch= it.

If you prefer, you may also enter the issues at https://github.com/rtcweb-wg/jsep.=C2=A0 If you do so, please send a copy of the issue to the mailing list = so that conversation and resolution occurs here.

This has been a lon= g road, but this a very major milestone.=C2=A0 Thanks to the authors for th= eir work so far.

regards,

Ted, Cullen, Sean


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 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-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 94
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-10-21

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtc= web-jsep-17

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


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

--001a1134e308e71835053f6504b3-- From nobody Fri Oct 21 16:26:00 2016 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 5774112984B; Fri, 21 Oct 2016 16:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207735.28214.16046871599298303251.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:17 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] rtcweb - Requested sessions have been scheduled for IETF 97 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:18 -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 (2:00:00) Monday, Afternoon Session II 1550-1750 Room Name: Grand Ballroom 3 size: 175 --------------------------------------------- rtcweb Session 2 (1:00:00) Wednesday, Afternoon Session II 1520-1620 Room Name: Studio 4 size: 100 --------------------------------------------- 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: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen ianaplan dane opsawg Special Requests: --------------------------------------------------------- From nobody Sun Oct 23 19:15:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7B1294AA for ; Sun, 23 Oct 2016 19:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.254 X-Spam-Level: X-Spam-Status: No, score=-101.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, USER_IN_WHITELIST=-100] autolearn=no 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 8FD1-XBQl1Bx for ; Sun, 23 Oct 2016 19:15:30 -0700 (PDT) Received: from smtp81.ord1c.emailsrvr.com (smtp81.ord1c.emailsrvr.com [108.166.43.81]) (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 C8E1B12946B for ; Sun, 23 Oct 2016 19:15:30 -0700 (PDT) Received: from smtp27.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 446A340126; Sun, 23 Oct 2016 22:15:30 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp27.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0D1CC400ED; Sun, 23 Oct 2016 22:15:26 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.41.128] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Sun, 23 Oct 2016 22:15:30 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_E3E96035-83E4-40DB-A40E-F509BB65D52C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476E6187@ESESSMB209.ericsson.se> Date: Sun, 23 Oct 2016 20:15:19 -0600 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B476E6187@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: Associate answer with offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:15:34 -0000 --Apple-Mail=_E3E96035-83E4-40DB-A40E-F509BB65D52C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One way to deal with this is, the JS app doing the signalling needs to = take care of being able to deal with it.=20 > On Jul 26, 2016, at 3:35 AM, Christer Holmberg = > = wrote: >=20 > Hi, > =20 > Assume the following: > =20 > 1) Alice calls createOffer(), and sends the generated offer = (offer X) towards Bob. > 2) Alice calls createOffer() again, and sends the generated offer = (offer Y) towards Bob. > 3) Alice receives an answer from Bob. > =20 > How does Alice know whether the answer is associated with offer X (in = which case I assume Alice should discard it) or with offer Y? > =20 > Since JSEP allows multiple outstanding offers (per section 3.2), there = needs to be a mechanism for associating an answer with a specific offer. > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_E3E96035-83E4-40DB-A40E-F509BB65D52C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

One way to deal with = this is, the JS app doing the signalling needs to take care of being = able to deal with it. 


On Jul 26, 2016, at 3:35 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
 
Assume = the following:
 
1)      Alice calls = createOffer(), and sends the generated offer (offer X) towards Bob.
2)      Alice calls = createOffer() again, and sends the generated offer (offer Y) towards = Bob.
3)      Alice = receives an answer from Bob.
 
How does Alice know whether the answer = is associated with offer X (in which case I assume Alice should discard = it) or with offer Y?
 
Since JSEP allows multiple outstanding offers (per section = 3.2), there needs to be a mechanism for associating an answer with a = specific offer.
 
Regards,
 
Christer
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_E3E96035-83E4-40DB-A40E-F509BB65D52C-- From nobody Mon Oct 24 12:12:37 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30DC1299B4 for ; Mon, 24 Oct 2016 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi3v-mskfulG for ; Mon, 24 Oct 2016 12:12:31 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 F2D691299BB for ; Mon, 24 Oct 2016 12:12:30 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id s49so132962965qta.0 for ; Mon, 24 Oct 2016 12:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ehwxG0Goq/DzcMPmdi33oG5ud4Md511UNbZXxNHFgC8=; b=NII+W54Q4VIxjA6PoRKcXjuRB/XTUMrSIff2z1vxLH6yA1r6WDU6GzF8x1pGy82bY4 7KazQLSJui8sslKvY9ipCmiwvKob2NjnbESNPGk8882Mo+TtyF4LkZGXpcvTi76aT1Em /Bdca4nGkbrhUDLWKl/kgv7lUFBH0XZvjv2XhjzP/T0cDEjj4FYh1bmD9MqYkA7R19Y5 +e4PHyvGBR4JtgWhupEVjhvvV0F/otgsmudFqnj1RKsTi1p2b4LMTZVPZkeHN57ctBUC ebhou/t+266Qiuhspcqu4WPe9orAFpXEzhMfcGOcPWvbXRndleHejMdOgtH+DqJJCPpa 7bTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ehwxG0Goq/DzcMPmdi33oG5ud4Md511UNbZXxNHFgC8=; b=BfivlpozF6qdN7bIPEEzyXnxDqgk1pMQ+iU7QyDCPNHZgALmHUpC/5FYLC7Ny5e5cx DCZ6EznpSUHb0gOOnKqcfFF/UenMsiEHlWKDiUIvxAoED6DFDw5jX6OKQRbvAbqB3MZu LciDNn0i8PHkUQORYrrXtHPWy9jNo0uX05s9zt1JRiUTEYDkBhaBeXfLisU2z4OfKn41 Y6/aE/wFFVKg/qt589vhCzoJ2dtR1jtM8dT3Honlb52in6r5pEI1UEZp8+VrHTbuo5b2 03bHwvWyObP5XW5P6+go6r1cZ1gZ737wgVwOF6MZ/nBwcLKQjGyUNsAuNz/9vpLjn1H0 jcHQ== X-Gm-Message-State: ABUngvesZGobpznvQdUPaNA9IVMdr1tePQ5Xnt46i+W891leagywd/Xpdgf0XxZF5jruJabF2qgzOzNJ8e9R8SG4 X-Received: by 10.200.40.162 with SMTP id i31mr16657408qti.70.1477336349869; Mon, 24 Oct 2016 12:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.43 with HTTP; Mon, 24 Oct 2016 12:12:29 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B476E6187@ESESSMB209.ericsson.se> From: Taylor Brandstetter Date: Mon, 24 Oct 2016 12:12:29 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a1140817059905d053fa12c95 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: Associate answer with offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:12:33 -0000 --001a1140817059905d053fa12c95 Content-Type: text/plain; charset=UTF-8 I don't think JSEP section 3.2 allows multiple outstanding offers. To quote: "In [RFC3264], the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point. For example, when using SIP for signaling, if one offer is sent, then cancelled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer." RFC 3264 states that an agent MUST be prepared to receive media after sending an offer (even before receiving an answer). So allowing multiple outstanding offers would severely complicate this. My assumption was that there is only one outstanding offer, which is the one last applied via setLocalDescription. On Sun, Oct 23, 2016 at 7:15 PM, Cullen Jennings wrote: > > One way to deal with this is, the JS app doing the signalling needs to > take care of being able to deal with it. > > > On Jul 26, 2016, at 3:35 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > Assume the following: > > 1) Alice calls createOffer(), and sends the generated offer (offer > X) towards Bob. > 2) Alice calls createOffer() again, and sends the generated offer > (offer Y) towards Bob. > 3) Alice receives an answer from Bob. > > How does Alice know whether the answer is associated with offer X (in > which case I assume Alice should discard it) or with offer Y? > > Since JSEP allows multiple outstanding offers (per section 3.2), there > needs to be a mechanism for associating an answer with a specific offer. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1140817059905d053fa12c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=C2=A0don't think JSEP section 3.2 allows multiple ou= tstanding offers. To quote:

=C2=A0 =C2=A0"In [RFC3264], the con= straint at the signaling level is that only one
=C2=A0 =C2=A0offer can b= e outstanding for a given session, but at the media stack
=C2=A0 =C2=A0l= evel, a new offer can be generated at any point.=C2=A0 For example, when=C2=A0 =C2=A0using SIP for signaling, if one offer is sent, then cancelled= using a
=C2=A0 =C2=A0SIP CANCEL, another offer can be generated even th= ough no answer was
=C2=A0 =C2=A0received for the first offer."
<= br>RFC 3264 states that an agent MUST be prepared to receive media after se= nding an offer (even before receiving an answer). So allowing multiple outs= tanding offers would severely complicate this. My assumption was that there= is only one outstanding offer, which is the one last applied via setLocalD= escription.=C2=A0

=
On Sun, Oct 23, 2016 at 7:15 PM, Cullen Je= nnings <fluffy@cisco.com> wrote:

One way to deal wi= th this is, the JS app doing the signalling needs to take care of being abl= e to deal with it.=C2=A0


On Jul 26, 2016, at 3:35 AM, Christer Holmb= erg <christer.holmberg@ericsson.com> wrote:

Hi,=
=C2=A0
Assume the followin= g:
=C2=A0
1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Alice calls createOffer(), an= d sends the generated offer (offer X) towards Bob.
2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Alice calls creat= eOffer() again, and sends the generated offer (offer Y) towards Bob.=
3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Alice receives an answer from Bob.
=C2= =A0
How does Alice know whether the answer is associa= ted with offer X (in which case I assume Alice should discard it) or with o= ffer Y?
=C2=A0
= Since JSEP allows multiple outstanding offers (per section 3.2), there need= s to be a mechanism for associating an answer with a specific offer.=
=C2=A0
Regards,<= u>
=C2=A0
Christer
_________= ______________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


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

--001a1140817059905d053fa12c95-- From nobody Mon Oct 24 12:37:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7AC127076 for ; Mon, 24 Oct 2016 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0TIKUO5DDaS for ; Mon, 24 Oct 2016 12:37:50 -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 84EF51295AA for ; Mon, 24 Oct 2016 12:37:49 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-45-580e630af2e7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id AF.31.02551.A036E085; Mon, 24 Oct 2016 21:37:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Mon, 24 Oct 2016 21:37:45 +0200 From: Christer Holmberg To: Taylor Brandstetter , Cullen Jennings Thread-Topic: [rtcweb] JSEP: Associate answer with offer Thread-Index: AdHexV6/LpEDnFnISjqdHvLt16PumROxlU2AACOGLoAABP6coA== Date: Mon, 24 Oct 2016 19:37:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BDCA0F2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B476E6187@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BDCA0F2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7pS53Ml+EwbXr2haXVzxkteiYzGax 9l87uwOzx5TfG1k9Fmwq9Viy5CdTAHMUl01Kak5mWWqRvl0CV8aZfavYCtpmM1bsWfuesYHx yzTGLkZODgkBE4lNExqYuxi5OIQE1jNKTLi0hhHCWcwoMW9LJ2sXIwcHm4CFRPc/bZAGEYFg ibtNv5lAbGYBRYkvy+ezgdjCAuYSaz/fY4KosZCYOH8dlO0ksa1vDzPIGBYBVYnbE6xBwrwC vhI/HrUyQaw6zihxpf0YWD2nQKDEicZmdhCbUUBM4vupNVC7xCVuPZnPBHG0gMSSPeeZIWxR iZeP/7FC2EoSaw9vZ4Goz5d49XE6G8QyQYmTM5+wTGAUmYVk1CwkZbOQlM0COpVZQFNi/S79 WVBfTul+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgpB3c8lt3 B+Pq146HGAU4GJV4eBV8+CKEWBPLiitzDzFKcDArifDejgUK8aYkVlalFuXHF5XmpBYfYpTm YFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwBjmJXb17vpTr93PeOrMWbCd6cv1/VqeM5x3 NHe/eeyk3VXB+eZzy45aqaDtc+xunoyvt3GRdvyhPefKgdOBXcUdWnuK1p1W5T89vf9+esx7 hluPDZoM/vLWr74nUXA/brZ6pCPLIv4HB92ak75efXV7FtvzBZMXLM2vdJ0VcGOXthb7J9d1 7CpKLMUZiYZazEXFiQAiGrltsAIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: Associate answer with offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:37:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BDCA0F2ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGF5bG9yLA0KDQpXaGF0IHlvdSBzYXkgbWFrZXMgc2Vuc2UuDQoNCkkgd2FzIHRoaW5raW5n IHRoZSBzYW1lIHRoaW5nLCBhbmQgSSB0aGluayBpdCBzaG91bGQgYmUgY2xhcmlmaWVkIHRoYXQg Y3JlYXRlT2ZmZXIoKSBkb2VzbuKAmXQgcmVhbGx5ICBnZW5lcmF0ZSBhbiBvZmZlciBpbiBhIDMy NjQgbWVhbmluZyDigJMgY3JlYXRlT2ZmZXIoKSArIHNldExvY2FsRGVzY3JpcHRpb24oKSBkb2Vz Lg0KDQpBbmQsIGFmdGVyIHlvdeKAmXZlIGNhbGxlZCBzZXRMb2NhbERlc2NyaXB0aW9uKCkgaXQg ZG9lc27igJl0IG1hdHRlciBob3cgbWFueSB0aW1lcyB5b3UgY2FsbCBjcmVhdGVPZmZlcigpIGFn YWluIOKAkyBub3RoaW5nIHdpbGwgY2hhbmdlIHVudGlsIHlvdSBjYWxsIHNldExvY2FsRGVzY3Jp cHRpb24oKSBhZ2Fpbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogVGF5bG9yIEJy YW5kc3RldHRlciBbbWFpbHRvOmRlYWRiZWVmQGdvb2dsZS5jb21dDQpTZW50OiAyNCBPY3RvYmVy IDIwMTYgMjI6MTINClRvOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+DQpDYzog Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFJUQ1dl YiBJRVRGIDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNFUDogQXNz b2NpYXRlIGFuc3dlciB3aXRoIG9mZmVyDQoNCkkgZG9uJ3QgdGhpbmsgSlNFUCBzZWN0aW9uIDMu MiBhbGxvd3MgbXVsdGlwbGUgb3V0c3RhbmRpbmcgb2ZmZXJzLiBUbyBxdW90ZToNCg0KICAgIklu IFtSRkMzMjY0XSwgdGhlIGNvbnN0cmFpbnQgYXQgdGhlIHNpZ25hbGluZyBsZXZlbCBpcyB0aGF0 IG9ubHkgb25lDQogICBvZmZlciBjYW4gYmUgb3V0c3RhbmRpbmcgZm9yIGEgZ2l2ZW4gc2Vzc2lv biwgYnV0IGF0IHRoZSBtZWRpYSBzdGFjaw0KICAgbGV2ZWwsIGEgbmV3IG9mZmVyIGNhbiBiZSBn ZW5lcmF0ZWQgYXQgYW55IHBvaW50LiAgRm9yIGV4YW1wbGUsIHdoZW4NCiAgIHVzaW5nIFNJUCBm b3Igc2lnbmFsaW5nLCBpZiBvbmUgb2ZmZXIgaXMgc2VudCwgdGhlbiBjYW5jZWxsZWQgdXNpbmcg YQ0KICAgU0lQIENBTkNFTCwgYW5vdGhlciBvZmZlciBjYW4gYmUgZ2VuZXJhdGVkIGV2ZW4gdGhv dWdoIG5vIGFuc3dlciB3YXMNCiAgIHJlY2VpdmVkIGZvciB0aGUgZmlyc3Qgb2ZmZXIuIg0KDQpS RkMgMzI2NCBzdGF0ZXMgdGhhdCBhbiBhZ2VudCBNVVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUg bWVkaWEgYWZ0ZXIgc2VuZGluZyBhbiBvZmZlciAoZXZlbiBiZWZvcmUgcmVjZWl2aW5nIGFuIGFu c3dlcikuIFNvIGFsbG93aW5nIG11bHRpcGxlIG91dHN0YW5kaW5nIG9mZmVycyB3b3VsZCBzZXZl cmVseSBjb21wbGljYXRlIHRoaXMuIE15IGFzc3VtcHRpb24gd2FzIHRoYXQgdGhlcmUgaXMgb25s eSBvbmUgb3V0c3RhbmRpbmcgb2ZmZXIsIHdoaWNoIGlzIHRoZSBvbmUgbGFzdCBhcHBsaWVkIHZp YSBzZXRMb2NhbERlc2NyaXB0aW9uLg0KDQpPbiBTdW4sIE9jdCAyMywgMjAxNiBhdCA3OjE1IFBN LCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb208bWFpbHRvOmZsdWZmeUBjaXNjby5j b20+PiB3cm90ZToNCg0KT25lIHdheSB0byBkZWFsIHdpdGggdGhpcyBpcywgdGhlIEpTIGFwcCBk b2luZyB0aGUgc2lnbmFsbGluZyBuZWVkcyB0byB0YWtlIGNhcmUgb2YgYmVpbmcgYWJsZSB0byBk ZWFsIHdpdGggaXQuDQoNCg0KT24gSnVsIDI2LCAyMDE2LCBhdCAzOjM1IEFNLCBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCkFzc3VtZSB0aGUgZm9sbG93 aW5nOg0KDQoxKSAgICAgIEFsaWNlIGNhbGxzIGNyZWF0ZU9mZmVyKCksIGFuZCBzZW5kcyB0aGUg Z2VuZXJhdGVkIG9mZmVyIChvZmZlciBYKSB0b3dhcmRzIEJvYi4NCjIpICAgICAgQWxpY2UgY2Fs bHMgY3JlYXRlT2ZmZXIoKSBhZ2FpbiwgYW5kIHNlbmRzIHRoZSBnZW5lcmF0ZWQgb2ZmZXIgKG9m ZmVyIFkpIHRvd2FyZHMgQm9iLg0KMykgICAgICBBbGljZSByZWNlaXZlcyBhbiBhbnN3ZXIgZnJv bSBCb2IuDQoNCkhvdyBkb2VzIEFsaWNlIGtub3cgd2hldGhlciB0aGUgYW5zd2VyIGlzIGFzc29j aWF0ZWQgd2l0aCBvZmZlciBYIChpbiB3aGljaCBjYXNlIEkgYXNzdW1lIEFsaWNlIHNob3VsZCBk aXNjYXJkIGl0KSBvciB3aXRoIG9mZmVyIFk/DQoNClNpbmNlIEpTRVAgYWxsb3dzIG11bHRpcGxl IG91dHN0YW5kaW5nIG9mZmVycyAocGVyIHNlY3Rpb24gMy4yKSwgdGhlcmUgbmVlZHMgdG8gYmUg YSBtZWNoYW5pc20gZm9yIGFzc29jaWF0aW5nIGFuIGFuc3dlciB3aXRoIGEgc3BlY2lmaWMgb2Zm ZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BDCA0F2ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu Lm0yODU3NTIwMDUzODY1MDc4NDY3YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOm1fMjg1NzUyMDA1Mzg2NTA3ODQ2N2FwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgVGF5bG9yLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCB5b3Ugc2F5IG1ha2VzIHNl bnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB3YXMgdGhpbmtp bmcgdGhlIHNhbWUgdGhpbmcsIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgdGhh dCBjcmVhdGVPZmZlcigpIGRvZXNu4oCZdCByZWFsbHkmbmJzcDsgZ2VuZXJhdGUgYW4gb2ZmZXIg aW4gYSAzMjY0IG1lYW5pbmcNCiDigJMgY3JlYXRlT2ZmZXIoKSAmIzQzOyBzZXRMb2NhbERlc2Ny aXB0aW9uKCkgZG9lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFu ZCwgYWZ0ZXIgeW914oCZdmUgY2FsbGVkIHNldExvY2FsRGVzY3JpcHRpb24oKSBpdCBkb2VzbuKA mXQgbWF0dGVyIGhvdyBtYW55IHRpbWVzIHlvdSBjYWxsIGNyZWF0ZU9mZmVyKCkgYWdhaW4g4oCT IG5vdGhpbmcgd2lsbCBjaGFuZ2UNCiB1bnRpbCB5b3UgY2FsbCBzZXRMb2NhbERlc2NyaXB0aW9u KCkgYWdhaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUYXlsb3IgQnJhbmRzdGV0dGVyIFttYWlsdG86 ZGVhZGJlZWZAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNCBPY3RvYmVyIDIwMTYg MjI6MTI8YnI+DQo8Yj5Ubzo8L2I+IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1ZmZ5QGNpc2NvLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBSVENXZWIgSUVURiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUDogQXNzb2NpYXRlIGFuc3dl ciB3aXRoIG9mZmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSZuYnNw O2Rvbid0IHRoaW5rIEpTRVAgc2VjdGlvbiAzLjIgYWxsb3dzIG11bHRpcGxlIG91dHN0YW5kaW5n IG9mZmVycy4gVG8gcXVvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyZxdW90O0luIFtSRkMz MjY0XSwgdGhlIGNvbnN0cmFpbnQgYXQgdGhlIHNpZ25hbGluZyBsZXZlbCBpcyB0aGF0IG9ubHkg b25lPGJyPg0KJm5ic3A7ICZuYnNwO29mZmVyIGNhbiBiZSBvdXRzdGFuZGluZyBmb3IgYSBnaXZl biBzZXNzaW9uLCBidXQgYXQgdGhlIG1lZGlhIHN0YWNrPGJyPg0KJm5ic3A7ICZuYnNwO2xldmVs LCBhIG5ldyBvZmZlciBjYW4gYmUgZ2VuZXJhdGVkIGF0IGFueSBwb2ludC4mbmJzcDsgRm9yIGV4 YW1wbGUsIHdoZW48YnI+DQombmJzcDsgJm5ic3A7dXNpbmcgU0lQIGZvciBzaWduYWxpbmcsIGlm IG9uZSBvZmZlciBpcyBzZW50LCB0aGVuIGNhbmNlbGxlZCB1c2luZyBhPGJyPg0KJm5ic3A7ICZu YnNwO1NJUCBDQU5DRUwsIGFub3RoZXIgb2ZmZXIgY2FuIGJlIGdlbmVyYXRlZCBldmVuIHRob3Vn aCBubyBhbnN3ZXIgd2FzPGJyPg0KJm5ic3A7ICZuYnNwO3JlY2VpdmVkIGZvciB0aGUgZmlyc3Qg b2ZmZXIuJnF1b3Q7PGJyPg0KPGJyPg0KUkZDIDMyNjQgc3RhdGVzIHRoYXQgYW4gYWdlbnQgTVVT VCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIG1lZGlhIGFmdGVyIHNlbmRpbmcgYW4gb2ZmZXIgKGV2 ZW4gYmVmb3JlIHJlY2VpdmluZyBhbiBhbnN3ZXIpLiBTbyBhbGxvd2luZyBtdWx0aXBsZSBvdXRz dGFuZGluZyBvZmZlcnMgd291bGQgc2V2ZXJlbHkgY29tcGxpY2F0ZSB0aGlzLiBNeSBhc3N1bXB0 aW9uIHdhcyB0aGF0IHRoZXJlIGlzIG9ubHkgb25lIG91dHN0YW5kaW5nIG9mZmVyLCB3aGljaA0K IGlzIHRoZSBvbmUgbGFzdCBhcHBsaWVkIHZpYSBzZXRMb2NhbERlc2NyaXB0aW9uLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1 biwgT2N0IDIzLCAyMDE2IGF0IDc6MTUgUE0sIEN1bGxlbiBKZW5uaW5ncyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZsdWZmeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5mbHVmZnlAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T25lIHdheSB0byBkZWFsIHdpdGggdGhpcyBpcywgdGhlIEpTIGFw cCBkb2luZyB0aGUgc2lnbmFsbGluZyBuZWVkcyB0byB0YWtlIGNhcmUgb2YgYmVpbmcgYWJsZSB0 byBkZWFsIHdpdGggaXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyNiwgMjAxNiwgYXQgMzozNSBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1 bWUgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 Im0yODU3NTIwMDUzODY1MDc4NDY3YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWxpY2UNCiBjYWxscyBjcmVhdGVPZmZlcigpLCBhbmQg c2VuZHMgdGhlIGdlbmVyYXRlZCBvZmZlciAob2ZmZXIgWCkgdG93YXJkcyBCb2IuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4yKTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0ibTI4NTc1MjAwNTM4NjUwNzg0NjdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbGljZQ0KIGNhbGxzIGNyZWF0ZU9mZmVyKCkg YWdhaW4sIGFuZCBzZW5kcyB0aGUgZ2VuZXJhdGVkIG9mZmVyIChvZmZlciBZKSB0b3dhcmRzIEJv Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjMpPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJtMjg1NzUyMDA1Mzg2NTA3ODQ2N2FwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFsaWNlDQogcmVjZWl2ZXMg YW4gYW5zd2VyIGZyb20gQm9iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Ib3cgZG9lcyBBbGljZSBrbm93IHdoZXRoZXIgdGhlIGFuc3dlciBpcyBhc3NvY2lh dGVkIHdpdGggb2ZmZXIgWCAoaW4gd2hpY2ggY2FzZSBJIGFzc3VtZSBBbGljZSBzaG91bGQgZGlz Y2FyZCBpdCkgb3Igd2l0aCBvZmZlciBZPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5TaW5jZSBKU0VQIGFsbG93cyBtdWx0aXBsZSBvdXRzdGFuZGluZyBvZmZl cnMgKHBlciBzZWN0aW9uIDMuMiksIHRoZXJlIG5lZWRzIHRvIGJlIGEgbWVjaGFuaXNtIGZvciBh c3NvY2lhdGluZyBhbiBhbnN3ZXIgd2l0aCBhIHNwZWNpZmljIG9mZmVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izk1NEY3MiI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1 NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BDCA0F2ESESSMB209erics_-- From nobody Mon Oct 24 18:52:16 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7874D129A68 for ; Mon, 24 Oct 2016 18:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-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 7qvDKrSebs5l for ; Mon, 24 Oct 2016 18:52:13 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [58.83.224.37]) by ietfa.amsl.com (Postfix) with ESMTP id A820F128DF6 for ; Mon, 24 Oct 2016 18:52:12 -0700 (PDT) Received: from wangaj (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id JeBTOgDX3wNOug5YtJcVAA--.12899S2; Tue, 25 Oct 2016 09:50:06 +0800 (CST) From: "Aijun Wang" To: Date: Tue, 25 Oct 2016 09:52:04 +0800 Message-ID: <015401d22e62$628e6ea0$27ab4be0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0155_01D22EA5.70B1AEA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdIuYmJq+BcBOVV9RryBr1gXz79Qxg== Content-Language: zh-cn X-CM-TRANSID: JeBTOgDX3wNOug5YtJcVAA--.12899S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Jr45ZFyxWw4kKw48tr15twb_yoWkJFg_ur WrJrZxKrs8XrnrGF4YgrWaqr9agw429F10k3y5Xrs2ka4rZw4DGan2qr15Xr1fGry8uFn8 Jr95Jry0krW3GjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb38YjsxI4VWkCwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2 x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWx JVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VCjz4 8v1sIEY20_GF1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMx8GjcxK6IxK 0xIIj40E5I8CrwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1l IxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWI evJa73UjIFyTuYvjxUUBTYUUUUU X-CM-SenderInfo: 5zdqwthlmx0qxwvl0wxkxdh0lujou0/ Archived-At: Subject: [rtcweb] OARS solution for webrtc application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Oct 2016 01:52:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0155_01D22EA5.70B1AEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, all respectable RTCWEB experts: Here we propose one draft that can cover peer to peer communication scenario under various complex network environment(Cone/Symmetry NAT, IPv4&IPv6 Coexistence etc.) with the unified solution. https://tools.ietf.org/html/draft-wang-rtcweb-oars-00 This document proposes a new relay-based NAT traversal architecture called OARS which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787 ] [RFC5382 ] NAT devices. The key mechanism in OARS is the newly defined "Couple" operation (using STUN [RFC5389 ] message format) which allows the Relay servers to be easily incorporated into existing CGN/CDN nodes which are already deployed within the network in a distributed manner. One brief introduction can be accessed at https://www.ietf.org/proceedings/96/slides/slides-96-tram-1.pdf, wish to hear your valuable comments on this topic. Best Regards. Aijun Wang China Telecom Beijing Research Institute Network R&D and Operation Support Department ------=_NextPart_000_0155_01D22EA5.70B1AEA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all respectable RTCWEB = experts:

 

Here we = propose one draft that can cover peer to peer communication scenario = under various complex network environment(Cone/Symmetry NAT, = IPv4&IPv6 Coexistence etc.) with the unified solution. =

https://to= ols.ietf.org/html/draft-wang-rtcweb-oars-00

 

This document =
proposes a new relay-based NAT traversal architecture called OARS which =
could simplify the data communication =
process
    =
between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] =
NAT devices.  The key mechanism in OARS is =
the
    newly defined "Couple" operation =
(using STUN [RFC5389] message format) which allows the Relay =
servers to be easily incorporated
    =
into existing CGN/CDN nodes which are already deployed within the =
network in a distributed manner.

 

One brief introduction can be = accessed at = https://www.ietf.org/proceedings/96/slides/slides-96-tram-1.pdf, = wish to hear your valuable comments on this = topic.

 

 

Best Regards.

 

Aijun Wang

China Telecom Beijing Research = Institute

Network R&D and Operation Support = Department

 

 

------=_NextPart_000_0155_01D22EA5.70B1AEA0-- From nobody Tue Oct 25 10:42:46 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E1C129871 for ; Tue, 25 Oct 2016 10:42:45 -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, HTML_MESSAGE=0.001, 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 JYGKSfm3xs2M for ; Tue, 25 Oct 2016 10:42:42 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0679129863 for ; Tue, 25 Oct 2016 10:42:42 -0700 (PDT) Received: from [130.209.247.112] (port=52094 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bz5kE-0005dP-DU; Tue, 25 Oct 2016 18:42:40 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4D33ECE-2B42-4A49-A04B-50FA1132FCB1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 25 Oct 2016 18:42:32 +0100 Message-Id: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org> References: To: Ted Hardie X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working Group Last Call: JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Oct 2016 17:42:45 -0000 --Apple-Mail=_F4D33ECE-2B42-4A49-A04B-50FA1132FCB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is a well written draft. I think Section 6 needs work, along the = lines of the recent discussion and updates to BUNDLE, but the rest of = the document seems to be in good shape. Section 6 says: Note: The following algorithm does not yet have WG consensus but is included here as something concrete for the working group to discuss. I don=E2=80=99t think what=E2=80=99s written here is right yet. The RTP = specification has rules for forming RTP packets into RTP streams based = on their SSRC, and for associating RTCP packets with RTP streams. = Similarly, BUNDLE, as of -35, has rules for mapping RTP streams to m=3D = sections based on the MID. This section seems to be trying to replicate = these, rather than building on them.=20 I think this section should leave the mapping from RTP/RTCP packets to = RTP streams to RTP, and the mapping from RTP streams to m=3D sections to = SDP (and BUNDLE, if used). It should talk instead about how RTP streams = associated with m=3D sections are mapped onto RtpSenders and = RtpReceivers. This may sound like just a terminology difference, but I = think it=E2=80=99s important to get the layering and division of = responsibilities right, if the protocol is to be maintainable and = extensible. I also had some minor nits on the rest of the document: - Section 5.1.1, 1st paragraph: The list of mandatory to implement = standards is =E2=80=9Cderived from the requirements outlined in = [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D. Should the draft say somewhere = that =E2=80=9CRTP media transport MUST be implemented according to = [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D?=20 - Section 5.1.1: It=E2=80=99s easy to skim-read R-5 this as =E2=80=9CMUST=E2= =80=9D, since all the other requirements are MUST. It might be more = visually distinct if written as =E2=80=9CSHALL NOT=E2=80=9D rather than = =E2=80=9CMUST NOT=E2=80=9D. - Section 5.1.1: R-16 should be removed. - Section 5.2.1, top of page 38: The header extension is in Section 14 = of BUNDLE, not Section 11 (also second bullet point on page 39). - Section 5.8, 3rd bullet on page 60: I suggest changing =E2=80=9CIf the = MID header extension is supported, prepare to demux RTP data intended = for this media section=E2=80=9C to =E2=80=9C=E2=80=A6prepare to demux = RTP streams intended=E2=80=A6=E2=80=9D, to match the recent discussion = around terminology in BUNDLE. Colin > On 21 Oct 2016, at 20:25, Ted Hardie wrote: >=20 > The chairs would like to start a working group last call on = draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. > =20 > Please review thoroughly, as working through the last comments will be = the major effort of our working group meeting in Seoul. >=20 > =46rom a process perspective, we will be working through the comments = as issues against the github repo. In order to accommodate folks who do = not use github, the chairs will enter a new issue for any issue raised = on the mailing list. That means that if you are raising a new issue, = please send it to the list with a new subject line so that the chairs = catch it. >=20 > If you prefer, you may also enter the issues at = https://github.com/rtcweb-wg/jsep . = If you do so, please send a copy of the issue to the mailing list so = that conversation and resolution occurs here. >=20 > This has been a long road, but this a very major milestone. Thanks to = the authors for their work so far. >=20 > regards, >=20 > Ted, Cullen, Sean >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers of the IETF. >=20 > Title : Javascript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-17.txt > Pages : 94 > Date : 2016-10-21 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ = >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-17 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_F4D33ECE-2B42-4A49-A04B-50FA1132FCB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

This = is a well written draft. I think Section 6 needs work, along the lines = of the recent discussion and updates to BUNDLE, but the rest of the = document seems to be in good shape.

Section 6 says:

   Note: The = following algorithm does not yet have WG consensus but is
   included here as something concrete for the = working group to discuss.

I don=E2=80=99t think what=E2=80=99s = written here is right yet. The RTP specification has rules for forming = RTP packets into RTP streams based on their SSRC, and for associating = RTCP packets with RTP streams. Similarly, BUNDLE, as of -35, has rules = for mapping RTP streams to m=3D sections based on the MID. This section = seems to be trying to replicate these, rather than building on = them. 

I = think this section should leave the mapping from RTP/RTCP packets to RTP = streams to RTP, and the mapping from RTP streams to m=3D sections to SDP = (and BUNDLE, if used). It should talk instead about how RTP streams = associated with m=3D sections are mapped onto RtpSenders and = RtpReceivers. This may sound like just a terminology difference, but I = think it=E2=80=99s important to get the layering and division of = responsibilities right, if the protocol is to be maintainable and = extensible.


I also had some minor nits on the rest = of the document:

- Section 5.1.1, 1st paragraph: The list of = mandatory to implement standards is =E2=80=9Cderived from the = requirements outlined in [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D. Should = the draft say somewhere that =E2=80=9CRTP media transport MUST be = implemented according to [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D? 
=

- Section 5.1.1: = It=E2=80=99s easy to skim-read R-5 this as =E2=80=9CMUST=E2=80=9D, since = all the other requirements are MUST. It might be more visually distinct = if written as  =E2=80=9CSHALL NOT=E2=80=9D rather than =E2=80=9CMUST = NOT=E2=80=9D.

- = Section 5.1.1: R-16 should be removed.

- Section 5.2.1, top of page 38: The = header extension is in Section 14 of BUNDLE, not Section 11 (also second = bullet point on page 39).

- Section 5.8, 3rd bullet on page 60: I suggest changing = =E2=80=9CIf the MID header extension is supported, prepare to demux RTP = data intended for this media section=E2=80=9C to =E2=80=9C=E2=80=A6prepare= to demux RTP streams intended=E2=80=A6=E2=80=9D, to match the recent = discussion around terminology in BUNDLE.

Colin




On 21 Oct 2016, at 20:25, Ted = Hardie <ted.ietf@gmail.com> wrote:

The chairs would like to = start a working group last call on draft-ietf-rtcweb-jset-17 to end on = November 9th, 2016, 17:00 KST.
 
Please = review thoroughly, as working through the last comments will be the = major effort of our working group meeting in Seoul.

=46rom a process perspective, we will be working = through the comments as issues against the github repo.  In order = to accommodate folks who do not use github, the chairs will enter a new = issue for any issue raised on the mailing list.  That means that if = you are raising a new issue, please send it to the list with a new = subject line so that the chairs catch it.

If you prefer, you may also enter the issues at https://github.com/rtcweb-wg/jsep.  If you do so, = please send a copy of the issue to the mailing list so that conversation = and resolution occurs here.

This has been a long road, = but this a very major milestone.  Thanks to the authors for their = work so far.

regards,

Ted, Cullen, Sean


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

        Title          =  : Javascript Session Establishment Protocol
        Authors         : = Justin Uberti
                    =       Cullen Jennings
                    =       Eric Rescorla
        Filename        : = draft-ietf-rtcweb-jsep-17.txt
        Pages          =  : 94
        Date          =   : 2016-10-21

Abstract:
   This document describes the mechanisms for allowing a = Javascript
   application to control the signaling plane of a multimedia = session
   via the interface specified in the W3C RTCPeerConnection = API, and
   discusses how this relates to existing signaling = protocols.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17

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


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

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

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

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



-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_F4D33ECE-2B42-4A49-A04B-50FA1132FCB1-- From nobody Tue Oct 25 11:03:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0DB129859 for ; Tue, 25 Oct 2016 11:03:52 -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 RFbC3Bu4VeHT for ; Tue, 25 Oct 2016 11:03:49 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490B8129561 for ; Tue, 25 Oct 2016 11:03:49 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id b35so16627476uaa.4 for ; Tue, 25 Oct 2016 11:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ArIREo8qS0UMZePPhjD0HVNzbQNOKzY84YBaOTjU2qI=; b=RUhAq8gtao4kt33VDTaRDbnuUzMDRE7fzQGHAzA4xD1Q590RQSHOAplnt0hlSbAOXi A3Rrk3eViAswt1iOhe8Kxs/MGD/0/flIVxv4NrxPUH2EKW37Z+CoWRNHLSI49V8+E0No ZjqDNzlvnPog6LHVab2fZe0vkE0MHh4GoVvDudMV7Vf+FzpRCh2xIl9yIFiBVvCeo5dF Flr5lwYy0vKcNlvGBdOzeWsS1zl6RvBKWYV3Um9glpm8lKVmqCaWisBAxnRwMVyP9rh0 pmXP3xCOmv+58IxusJFrpKNeg4YODw3/bNOFv6I/hwicXH0EwCK7q+ehvckGawhvM2XN FFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ArIREo8qS0UMZePPhjD0HVNzbQNOKzY84YBaOTjU2qI=; b=NupkqZgvXye6Lac0CqePywVFDWPdKXAPYF0y9Wm/30aj56265L2nI3DYier7JZHstj 0RMg+vNymc1Ukbs861PBxiRLd4oNbOCQOOHD0q2E7+hH+2pdeexBSiAm0ykzUXYMu89p ZaAGxezpGR0GFi5rFpjcWzXxkxMGT2hy/KyglOlYzq3ql4F/Y0WlFl1kvHnbH7Mw5CaU nDwlvoqN6n8w5qsnDl+SWVuARUFuX37tOfxsJTnWmVc0hwlN7XZuOPbWdhIeLlo+rHNj SGG4jGHbhz1OsOXLLAxqRbT9bcemR9uD8JFeE5Q6yXhyLrQJ32ksRrBlgXNDt7HMaDbC h4VA== X-Gm-Message-State: ABUngvfcSumiFFjzljh9OXC9aFQyqcyMFaFUa23rjzRONBIluf1AZvEzdPzU7woPoIGOSNbwMuxa4NGxXb4uxA== X-Received: by 10.159.33.69 with SMTP id 63mr15261089uab.2.1477418628289; Tue, 25 Oct 2016 11:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.88 with HTTP; Tue, 25 Oct 2016 11:03:27 -0700 (PDT) In-Reply-To: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org> References: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org> From: Bernard Aboba Date: Tue, 25 Oct 2016 11:03:27 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=94eb2c0b70fe861ad2053fb454aa Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working Group Last Call: JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Oct 2016 18:03:53 -0000 --94eb2c0b70fe861ad2053fb454aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin said: "I don=E2=80=99t think what=E2=80=99s written here is right yet. The RTP sp= ecification has rules for forming RTP packets into RTP streams based on their SSRC, and for associating RTCP packets with RTP streams. Similarly, BUNDLE, as of -35, has rules for mapping RTP streams to m=3D sections based on the MID. This section seems to be trying to replicate these, rather than building on them." I think this section should leave the mapping from RTP/RTCP packets to RTP streams to RTP, and the mapping from RTP streams to m=3D sections to SDP (a= nd BUNDLE, if used). It should talk instead about how RTP streams associated with m=3D sections are mapped onto RtpSenders and RtpReceivers. This may sound like just a terminology difference, but I think it=E2=80=99s importan= t to get the layering and division of responsibilities right, if the protocol is to be maintainable and extensible." [BA] The advice given in the JSEP document is more detailed than what is provided in BUNDLE and also covers situations (overlapping payload types) that BUNDLE mandates packet drops for. So I don't believe that the material is entirely overlapping. On Tue, Oct 25, 2016 at 10:42 AM, Colin Perkins wrote: > Hi, > > This is a well written draft. I think Section 6 needs work, along the > lines of the recent discussion and updates to BUNDLE, but the rest of the > document seems to be in good shape. > > Section 6 says: > > Note: The following algorithm does not yet have WG consensus but is > included here as something concrete for the working group to discuss. > > I don=E2=80=99t think what=E2=80=99s written here is right yet. The RTP s= pecification has > rules for forming RTP packets into RTP streams based on their SSRC, and f= or > associating RTCP packets with RTP streams. Similarly, BUNDLE, as of -35, > has rules for mapping RTP streams to m=3D sections based on the MID. This > section seems to be trying to replicate these, rather than building on > them. > > I think this section should leave the mapping from RTP/RTCP packets to RT= P > streams to RTP, and the mapping from RTP streams to m=3D sections to SDP = (and > BUNDLE, if used). It should talk instead about how RTP streams associated > with m=3D sections are mapped onto RtpSenders and RtpReceivers. This may > sound like just a terminology difference, but I think it=E2=80=99s import= ant to get > the layering and division of responsibilities right, if the protocol is t= o > be maintainable and extensible. > > > I also had some minor nits on the rest of the document: > > - Section 5.1.1, 1st paragraph: The list of mandatory to implement > standards is =E2=80=9Cderived from the requirements outlined in > [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D. Should the draft say somewhere that= =E2=80=9CRTP > media transport MUST be implemented according to > [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D? > > - Section 5.1.1: It=E2=80=99s easy to skim-read R-5 this as =E2=80=9CMUST= =E2=80=9D, since all the > other requirements are MUST. It might be more visually distinct if writte= n > as =E2=80=9CSHALL NOT=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D. > > - Section 5.1.1: R-16 should be removed. > > - Section 5.2.1, top of page 38: The header extension is in Section 14 of > BUNDLE, not Section 11 (also second bullet point on page 39). > > - Section 5.8, 3rd bullet on page 60: I suggest changing =E2=80=9CIf the = MID > header extension is supported, prepare to demux RTP data intended for thi= s > media section=E2=80=9C to =E2=80=9C=E2=80=A6prepare to demux RTP streams = intended=E2=80=A6=E2=80=9D, to match the > recent discussion around terminology in BUNDLE. > > Colin > > > > > On 21 Oct 2016, at 20:25, Ted Hardie wrote: > > The chairs would like to start a working group last call on > draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. > > Please review thoroughly, as working through the last comments will be th= e > major effort of our working group meeting in Seoul. > > From a process perspective, we will be working through the comments as > issues against the github repo. In order to accommodate folks who do not > use github, the chairs will enter a new issue for any issue raised on the > mailing list. That means that if you are raising a new issue, please sen= d > it to the list with a new subject line so that the chairs catch it. > > If you prefer, you may also enter the issues at > https://github.com/rtcweb-wg/jsep. If you do so, please send a copy of > the issue to the mailing list so that conversation and resolution occurs > here. > > This has been a long road, but this a very major milestone. Thanks to th= e > authors for their work so far. > > regards, > > Ted, Cullen, Sean > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > of the IETF. > > Title : Javascript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-17.txt > Pages : 94 > Date : 2016-10-21 > > Abstract: > This document describes the mechanisms for allowing a Javascript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-17 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c0b70fe861ad2053fb454aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colin said:=C2=A0

"I don=E2=80=99t think what=E2=80=99s written here is righ= t yet. The RTP specification has rules for forming RTP packets into RTP str= eams based on their SSRC, and for associating RTCP packets with RTP streams= . Similarly, BUNDLE, as of -35, has rules for mapping RTP streams to m=3D s= ections based on the MID. This section seems to be trying to replicate thes= e, rather than building on them."

I think this sectio= n should leave the mapping from RTP/RTCP packets to RTP streams to RTP, and= the mapping from RTP streams to m=3D sections to SDP (and BUNDLE, if used)= . It should talk instead about how RTP streams associated with m=3D section= s are mapped onto RtpSenders and RtpReceivers. This may sound like just a t= erminology difference, but I think it=E2=80=99s important to get the layeri= ng and division of responsibilities right, if the protocol is to be maintai= nable and extensible."

[BA] The advice given in the JSEP document is more detail= ed than what is provided in BUNDLE and also covers situations (overlapping = payload types) that BUNDLE mandates packet drops for.=C2=A0 So I don't = believe that the material is entirely overlapping. =C2=A0

On Tue, Oct 25, = 2016 at 10:42 AM, Colin Perkins <csp@csperkins.org> wrote:
Hi,
This is a well written draft. I think Section 6 needs work= , along the lines of the recent discussion and updates to BUNDLE, but the r= est of the document seems to be in good shape.

Sec= tion 6 says:

=C2=A0 =C2=A0Note: The following= algorithm does not yet have WG consensus but is
=C2=A0 =C2=A0inc= luded here as something concrete for the working group to discuss.

I don=E2=80=99t think what=E2=80=99s written here is= right yet. The RTP specification has rules for forming RTP packets into RT= P streams based on their SSRC, and for associating RTCP packets with RTP st= reams. Similarly, BUNDLE, as of -35, has rules for mapping RTP streams to m= =3D sections based on the MID. This section seems to be trying to replicate= these, rather than building on them.=C2=A0

I thin= k this section should leave the mapping from RTP/RTCP packets to RTP stream= s to RTP, and the mapping from RTP streams to m=3D sections to SDP (and BUN= DLE, if used). It should talk instead about how RTP streams associated with= m=3D sections are mapped onto RtpSenders and RtpReceivers. This may sound = like just a terminology difference, but I think it=E2=80=99s important to g= et the layering and division of responsibilities right, if the protocol is = to be maintainable and extensible.


= I also had some minor nits on the rest of the document:

- Section 5.1.1, 1st paragraph: The list of mandatory to impleme= nt standards is =E2=80=9Cderived from the requirements outlined in [I-D.iet= f-rtcweb-rtp-usage]=E2=80=9D. Should the draft say somewhere that =E2=80=9C= RTP media transport MUST be implemented according to [I-D.ietf-rtcweb-rtp-u= sage]=E2=80=9D?=C2=A0

- Section 5.1.1: It=E2=80=99= s easy to skim-read R-5 this as =E2=80=9CMUST=E2=80=9D, since all the other= requirements are MUST. It might be more visually distinct if written as = =C2=A0=E2=80=9CSHALL NOT=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D.

- Section 5.1.1: R-16 should be removed.
=
- Section 5.2.1, top of page 38: The header extension is in = Section 14 of BUNDLE, not Section 11 (also second bullet point on page 39).=

- Section 5.8, 3rd bullet on page 60: I suggest c= hanging =E2=80=9CIf the MID header extension is supported, prepare to demux= RTP data intended for this media section=E2=80=9C to =E2=80=9C=E2=80=A6pre= pare to demux RTP streams intended=E2=80=A6=E2=80=9D, to match the recent d= iscussion around terminology in BUNDLE.

Coli= n




On 21 Oct 2016, at 20:25, Ted = Hardie <ted.ietf= @gmail.com> wrote:

The chairs would like to s= tart a working group last call on draft-ietf-rtcweb-jset-17 to end on Novem= ber 9th, 2016, 17:00 KST.
=C2=A0
Please review thoroughly, as workin= g through the last comments will be the major effort of our working group m= eeting in Seoul.

From a process perspective, we will be workin= g through the comments as issues against the github repo.=C2=A0 In order to= accommodate folks who do not use github, the chairs will enter a new issue= for any issue raised on the mailing list.=C2=A0 That means that if you are= raising a new issue, please send it to the list with a new subject line so= that the chairs catch it.

If you prefer, you may also enter t= he issues at https://github.com/rtcweb-wg/jsep.=C2=A0 If you do so, please se= nd a copy of the issue to the mailing list so that conversation and resolut= ion occurs here.

This has been a long road, but this a very major mi= lestone.=C2=A0 Thanks to the authors for their work so far.

regards,

T= ed, Cullen, Sean


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 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-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 94
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-10-21

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtc= web-jsep-17

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


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

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

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

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

=


=
--=C2=A0
Colin Perkins
=





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

--94eb2c0b70fe861ad2053fb454aa-- From nobody Tue Oct 25 11:12:16 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D209D129599 for ; Tue, 25 Oct 2016 11:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yAI42ulkHF7 for ; Tue, 25 Oct 2016 11:12:14 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD981294D3 for ; Tue, 25 Oct 2016 11:12:13 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id m72so110441936oik.3 for ; Tue, 25 Oct 2016 11:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pFVIisentRQYsToPpLvDh+8lbULjPrSXARVbHvooK2Y=; b=WQJmn8ntyI69l1xYWQKKqt2jo0Zaen63yRld7Alf3tLInkt5DYQ6LvpR9agMoqc0RS 3HwH8+BTeJFrQh2/FLhayR1NutGxKXnUJ9fAo/Nv1rrmNDXWJ1IiLv+9umGSgPF6j0v2 IRQsx7vgnJS6pNKqM92nHBUuvbMQxi23QlNI/KgB0qV3y5BH/kutzla6Zos/sl598OMa xRXalo39R7pb8/Dqq6xWQErZ5xywZdCa417MbH3vh55Q0V9MzZXIYFyrgDRDqsx2wXt5 AabDlpjbgKEFfDtecp+dMjbJkBJH1yksX0l5eqJx+SIkS8E1fuL1vHh0QDwpQgFShrX5 /05A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pFVIisentRQYsToPpLvDh+8lbULjPrSXARVbHvooK2Y=; b=aXar1flXlrFE6oXPeTYk5pYJtSn8Dcn6sD7IeBJy7sdMXD3eUey3qCM2SAlA5pzg0z JO1TgkNP2dplMq7hJTXOG7alEKaJbXl2bLPEeXzwMeJj25GkxDIoFUJoDgfxCCKoHEJ2 rPj57dckQgWc9jd2Uru8qnf1n/YGlX0/mffRFFB3m3atfIm/W6q8EpQp4D6DhG0APtUZ LMgGdUMi3vzjzDn61O6DgKR1F3jD9Av9+WEdELdtqJORWk8taX0t+elmGmYQ9xCi6wZk xTzPL4zvRLMUL2L9Wr7HBK5Jgh+i6u1TuS9gKlm/cnU7rnZiv8vxYjSh32LLW3GEPJQE fBVA== X-Gm-Message-State: AA6/9Rme6qzCojN9CYVmlDqhuYKHDReK3riT6SoSfh94CHPfSPtj/1lEWfDm8tyVYgNBYAkVMgzMOefWJo6LMQ== X-Received: by 10.202.230.207 with SMTP id d198mr23963625oih.27.1477419132831; Tue, 25 Oct 2016 11:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.203 with HTTP; Tue, 25 Oct 2016 11:11:42 -0700 (PDT) In-Reply-To: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org> References: <18EF5EAF-81FF-4917-93DE-B25F20913216@csperkins.org> From: Ted Hardie Date: Tue, 25 Oct 2016 11:11:42 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a1141ad8a98d5ab053fb4723d Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working Group Last Call: JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Oct 2016 18:12:16 -0000 --001a1141ad8a98d5ab053fb4723d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Colin, On Tue, Oct 25, 2016 at 10:42 AM, Colin Perkins wrote: > Hi, > > This is a well written draft. I think Section 6 needs work, along the > lines of the recent discussion and updates to BUNDLE, but the rest of the > document seems to be in good shape. > > Section 6 says: > > Note: The following algorithm does not yet have WG consensus but is > included here as something concrete for the working group to discuss. > > I don=E2=80=99t think what=E2=80=99s written here is right yet. The RTP s= pecification has > rules for forming RTP packets into RTP streams based on their SSRC, and f= or > associating RTCP packets with RTP streams. Similarly, BUNDLE, as of -35, > has rules for mapping RTP streams to m=3D sections based on the MID. This > section seems to be trying to replicate these, rather than building on > them. > > I think this section should leave the mapping from RTP/RTCP packets to RT= P > streams to RTP, and the mapping from RTP streams to m=3D sections to SDP = (and > BUNDLE, if used). It should talk instead about how RTP streams associated > with m=3D sections are mapped onto RtpSenders and RtpReceivers. This may > sound like just a terminology difference, but I think it=E2=80=99s import= ant to get > the layering and division of responsibilities right, if the protocol is t= o > be maintainable and extensible. > > I've entered the above as an issue in the tracker: https://github.com/rtcweb-wg/jsep/issues/364 . Further commentary on the list, please. > > I also had some minor nits on the rest of the document: > > - Section 5.1.1, 1st paragraph: The list of mandatory to implement > standards is =E2=80=9Cderived from the requirements outlined in > [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D. Should the draft say somewhere that= =E2=80=9CRTP > media transport MUST be implemented according to > [I-D.ietf-rtcweb-rtp-usage]=E2=80=9D? > > - Section 5.1.1: It=E2=80=99s easy to skim-read R-5 this as =E2=80=9CMUST= =E2=80=9D, since all the > other requirements are MUST. It might be more visually distinct if writte= n > as =E2=80=9CSHALL NOT=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D. > > - Section 5.1.1: R-16 should be removed. > > - Section 5.2.1, top of page 38: The header extension is in Section 14 of > BUNDLE, not Section 11 (also second bullet point on page 39). > > - Section 5.8, 3rd bullet on page 60: I suggest changing =E2=80=9CIf the = MID > header extension is supported, prepare to demux RTP data intended for thi= s > media section=E2=80=9C to =E2=80=9C=E2=80=A6prepare to demux RTP streams = intended=E2=80=A6=E2=80=9D, to match the > recent discussion around terminology in BUNDLE. > > I've entered these as a single editorial issue, at the moment, https://github.com/rtcweb-wg/jsep/issues/365 . If any need further discussion, we can break the relevant pieces out. Thanks for your review! Ted > Colin > > > > > On 21 Oct 2016, at 20:25, Ted Hardie wrote: > > The chairs would like to start a working group last call on > draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. > > Please review thoroughly, as working through the last comments will be th= e > major effort of our working group meeting in Seoul. > > From a process perspective, we will be working through the comments as > issues against the github repo. In order to accommodate folks who do not > use github, the chairs will enter a new issue for any issue raised on the > mailing list. That means that if you are raising a new issue, please sen= d > it to the list with a new subject line so that the chairs catch it. > > If you prefer, you may also enter the issues at > https://github.com/rtcweb-wg/jsep. If you do so, please send a copy of > the issue to the mailing list so that conversation and resolution occurs > here. > > This has been a long road, but this a very major milestone. Thanks to th= e > authors for their work so far. > > regards, > > Ted, Cullen, Sean > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > of the IETF. > > Title : Javascript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-17.txt > Pages : 94 > Date : 2016-10-21 > > Abstract: > This document describes the mechanisms for allowing a Javascript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-17 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a1141ad8a98d5ab053fb4723d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Colin,

On Tue, Oct 25, 2016 at 10:42 AM, Colin Perkins <csp@csp= erkins.org> wrote:
Hi,

This is a well written draft. I think Section 6 needs work, along the line= s of the recent discussion and updates to BUNDLE, but the rest of the docum= ent seems to be in good shape.

Section 6 says:

=C2=A0 =C2=A0Note: The following algorithm does = not yet have WG consensus but is
=C2=A0 =C2=A0included here as so= mething concrete for the working group to discuss.

I don=E2=80=99t think what=E2=80=99s written here is right yet. The = RTP specification has rules for forming RTP packets into RTP streams based = on their SSRC, and for associating RTCP packets with RTP streams. Similarly= , BUNDLE, as of -35, has rules for mapping RTP streams to m=3D sections bas= ed on the MID. This section seems to be trying to replicate these, rather t= han building on them.=C2=A0

I think this section s= hould leave the mapping from RTP/RTCP packets to RTP streams to RTP, and th= e mapping from RTP streams to m=3D sections to SDP (and BUNDLE, if used). I= t should talk instead about how RTP streams associated with m=3D sections a= re mapped onto RtpSenders and RtpReceivers. This may sound like just a term= inology difference, but I think it=E2=80=99s important to get the layering = and division of responsibilities right, if the protocol is to be maintainab= le and extensible.


I've entered the above as an issue in the tracker:=C2=A0 https://github.com/rtcweb-wg/= jsep/issues/364 .

Further commentary on the list, ple= ase.

=C2=A0
<= div style=3D"overflow-wrap: break-word;">

I a= lso had some minor nits on the rest of the document:

- Section 5.1.1, 1st paragraph: The list of mandatory to implement = standards is =E2=80=9Cderived from the requirements outlined in [I-D.ietf-r= tcweb-rtp-usage]=E2=80=9D. Should the draft say somewhere that =E2=80=9CRTP= media transport MUST be implemented according to [I-D.ietf-rtcweb-rtp-usag= e]=E2=80=9D?=C2=A0

- Section 5.1.1: It=E2=80=99s e= asy to skim-read R-5 this as =E2=80=9CMUST=E2=80=9D, since all the other re= quirements are MUST. It might be more visually distinct if written as =C2= =A0=E2=80=9CSHALL NOT=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D.

- Section 5.1.1: R-16 should be removed.
- Section 5.2.1, top of page 38: The header extension is in Sec= tion 14 of BUNDLE, not Section 11 (also second bullet point on page 39).

- Section 5.8, 3rd bullet on page 60: I suggest chan= ging =E2=80=9CIf the MID header extension is supported, prepare to demux RT= P data intended for this media section=E2=80=9C to =E2=80=9C=E2=80=A6prepar= e to demux RTP streams intended=E2=80=A6=E2=80=9D, to match the recent disc= ussion around terminology in BUNDLE.


I've entered these as a single editorial iss= ue, at the moment, https://github.com/rtcweb-wg/jsep/issues/365 .=C2=A0 If any need furth= er discussion, we can break the relevant pieces out.

Than= ks for your review!

Ted

=C2=A0
Colin




On 21 Oct 2016, at 20:25, Ted Hardie <ted.ietf@gmail.com> wrote:

The chairs would like to start a working group last ca= ll on draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST.=C2=A0
Please review thoroughly, as working through the last comments = will be the major effort of our working group meeting in Seoul.

From a process perspective, we will be working through the comments as is= sues against the github repo.=C2=A0 In order to accommodate folks who do no= t use github, the chairs will enter a new issue for any issue raised on the= mailing list.=C2=A0 That means that if you are raising a new issue, please= send it to the list with a new subject line so that the chairs catch it.
If you prefer, you may also enter the issues at https://github.com/rtcweb-= wg/jsep.=C2=A0 If you do so, please send a copy of the issue to th= e mailing list so that conversation and resolution occurs here.

This= has been a long road, but this a very major milestone.=C2=A0 Thanks to the= authors for their work so far.

reg= ards,

Ted, Cullen, Sean


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 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-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 94
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-10-21

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtc= web-jsep-17

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


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

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

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

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



--=C2=A0
Colin = Perkins





--001a1141ad8a98d5ab053fb4723d-- From nobody Wed Oct 26 08:24:38 2016 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 7519B129623; Wed, 26 Oct 2016 08:24:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147749547247.28152.16827819183348335144.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 08:24:32 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 15:24:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-17.txt Pages : 20 Date : 2016-10-26 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-17 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 Wed Oct 26 17:54:37 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7C1295AD for ; Wed, 26 Oct 2016 17:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8knnDjpZCa4b for ; Wed, 26 Oct 2016 17:54:33 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB895129406 for ; Wed, 26 Oct 2016 17:54:32 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id d65so16430332vkg.0 for ; Wed, 26 Oct 2016 17:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=SGXGUs3zxx74AqX4q44RBuArGrcxaIx/IdTBsfRXx1g=; b=y0gOYuIJJrtMPi2ohoQVaAagi1wkB9dihVCri9VkSWb0Pn3aiMR2Gwx5nHsS2RmM7G sdbbJY/5XfX6iZbeeBvyU2TWIgqh5+cQsU5Ry5+BlzAxyaGeEO5yYE6tyq0E1r/o/oMr lS00/yUNy0wll/FyfsdxrtAaWvOAclcWy8PsCiVdcNflLxqVYHdZwZVKwH9dxRDGQJ// 9LNQLW/STMT60pQO0yv/tUkSzCCxVIK8mLbsGviBB9BQRErZSCK487o9C1cWtupYKePH BqSxFv4YKBr6tVrHhXRltCGzmZSWdl9/teQB61oupGT9AakN+8qrve/Ep4G/B3ngIMiz cROg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=SGXGUs3zxx74AqX4q44RBuArGrcxaIx/IdTBsfRXx1g=; b=BLL+NKbpv6PMgNJbkAhkMcXXXtwItknaAxV3/hiOXmR87KjHOqqmWPHPHvffaajska 3jhJqGjAiaaGu5pKsB++PloUWL56ESqv2MPoKBvUKAYJ3H/JVgSa+aJUH/gO9oaciNlK WEKBcWafvWwDdtOHE1+GEroic7XBB9y1+1RelzhtWKH97Pm+OApbmpHNaT7NS2So8xBx /CSrrcaYhPMa9Ii4fih9WliySfJHgpE2VHVHBuJvqj9iLgZogEnkN6pB2y8PyIX+XMqF hUuoq6dKA3LRdpSVGT9GC2nCSSIz0bJnC8pImnfY5/FQI9m3W7ac0LkBzKXRJtgGr7Ni JwbA== X-Gm-Message-State: ABUngvcHt3CE0K/ceOBcNzdMZ+trVQBVd1tPn/ZYXtNYFoAgMPRdMNRoGg6Rc2zbf2yUqq1OPGBNkbnQjS44gQ== X-Received: by 10.31.130.74 with SMTP id e71mr3882565vkd.34.1477529671479; Wed, 26 Oct 2016 17:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.88 with HTTP; Wed, 26 Oct 2016 17:54:11 -0700 (PDT) From: Bernard Aboba Date: Wed, 26 Oct 2016 17:54:11 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114485f436b9fd053fce2f71 Archived-At: Cc: Robin Raymond Subject: [rtcweb] JSEP Section 6 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 00:54:35 -0000 --001a114485f436b9fd053fce2f71 Content-Type: text/plain; charset=UTF-8 Some comments. Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each payload type that RtpReceiver is configured to receive. The payload types of a given RtpReceiver are found in the m= section corresponding to that RtpReceiver in the local description. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. [BA] In the case where a payload type can map to more than one RtpReceiver, what if the earliest m-line is "send-only" or "inactive"? Wouldn't you want to map to the RtpReceiver whose m-line is "recv-only" or "send-recv" and is earliest? If the packet's payload type is in the payload type table, update the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that payload type. In addition, deliver the packet to the associated RtpReceiver and stop. [BA] I believe that PT-based SSRC latching breaks two of Cullen's proposed use cases (see: https://mailarchive.ietf.org/arch/msg/rtcweb/cvcpy-Rnj4ntL66haNnKHy2_Yvw ): Codec change, case 1: The PTs are all unique, and no SSRCs were signaled in SDP There is no RID, MID, FEC or RTX. Sender switches codecs, and the PT changes (but SSRC stays the same). The packet goes to the receiver that matches the new PT. Codec change, case 2: The PTs are all unique and SSRCs are signaled in SDP. There is no RID, MID, FEC or RTX. Sender switches codecs and the PT changes (but SSRC stays the same). SSRC does not match any signaled ones. The packet goes to the receiver that matches the new PT. [BA] For the RTCP routing, it is more clear to use the RFC 3550 terms for the various SSRC fields. For exchange, change: "If the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. In addition, for each report block in the report whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC." To: "If the packet is of type SR, and the "SSRC of sender" for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. In addition, for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC." [BA] Change: "If the packet is of type RR, for each report block in the packet whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC." To: "If the packet is of type RR, for each report block in the packet whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC." [BA] The RTCP SDES packet has no "SSRC of packet sender" field, so change: "If the packet is of type SDES, and the sender SSRC for the packet is found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC. In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID. (This case can occur when RTCP for a source is received before any RTP packets.)" To: "If the packet is of type SDES, for each chunk containing an "SSRC/CSRC" field found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC. In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID. (This case can occur when RTCP for a source is received before any RTP packets.)" [BA] Change: "If the packet is of type BYE, for each SSRC indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC." To: "If the packet is of type BYE, for each "SSRC/CSRC" indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC." [BA] Change: "If the packet is of type RTPFB or PSFB, as defined in [RFC4585 ], and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC." To: "If the packet is of type RTPFB or PSFB, as defined in [RFC4585 ], and the "SSRC of media source" for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC." [BA] Since FIR feedback messages can contain multiple FCI fields, I think you need to add the following text (see RFC 5104 Section 4.3.1.1): "In addition, for FIR feedback messages, as defined in [RFC5104], for each "SSRC" indicated in an FCI entry, deliver a copy of the packet to the RtpSender associated with that SSRC. --001a114485f436b9fd053fce2f71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some comments.

      Construct a table mapping payload type to RtpReceiver for e=
ach
      RtpReceiver configured to receive from this transport and for each
      payload type that RtpReceiver is configured to receive.  The
      payload types of a given RtpReceiver are found in the m=3D section
      corresponding to that RtpReceiver in the local description.  If
      any payload type could map to more than one RtpReceiver, map to
      the RtpReceiver whose m=3D section appears earliest in the local
      description.

[BA] In the case where =
a payload type can map to =C2=A0more than one RtpReceiver, what if the earliest m-line is "send-only" or &qu=
ot;inactive"?=C2=A0 Wouldn't you want to map to the =C2=A0RtpRecei=
ver whose m-line is "recv-only" or "send-recv" and is e=
arliest?=C2=A0

      If the pac=
ket's payload type is in the payload type table, update
      the the incoming SSRC mapping table to include an entry that maps
      the packet's SSRC to the RtpReceiver for that payload type.  In
      addition, deliver the packet to the associated RtpReceiver and
      stop.

[BA] I believe that PT-b=
ased SSRC latching breaks two of Cullen's proposed use cases (see:=C2=
=A0https://mailarchive.ietf.org/arch/msg/rtcweb/cvcpy-Rnj4ntL66ha=
NnKHy2_Yvw ):=C2=A0

Codec change, case 1: The PTs are all unique, and no SS=
RCs were signaled in
SDP  There is no RID, MID, FEC or RTX. Sender switches codecs, and the PT
changes (but SSRC stays the same).  The packet goes to the receiver that
matches the new PT.
Cod=
ec change, case 2:  The PTs are all unique and SSRCs are signaled in
SDP.  There is no RID, MID, FEC or RTX. Sender switches codecs and the PT
changes (but SSRC stays the same).  SSRC does not match any signaled ones.
The packet goes to the receiver that matches the new PT.
[BA] For the RTCP routing, it is more clear to use the R=
FC 3550 terms for the various SSRC fields.=C2=A0 For exchange, change:
      "If=
 the packet is of type SR, and the sender SSRC for the packet is
      found in the incoming SSRC table, deliver a copy of the packet to
      the RtpReceiver associated with that SSRC.  In addition, for each
      report block in the report whose SSRC is found in the outgoing
      SSRC table, deliver a copy of the RTCP packet to the RtpSender
      associated with that SSRC."
To:
=


      &quo=
t;If the packet is of type SR, and the "SSRC of sender" for the p=
acket is
      found in the incoming SSRC table, deliver a copy of the packet to
      the RtpReceiver associated with that SSRC.  In addition, for each
      report block in the report whose "SSRC of source" is found =
in the outgoing
      SSRC table, deliver a copy of the RTCP packet to the RtpSender
      associated with that SSRC."


[BA] Chang=
e:

      "If the packet is of type RR, for each report block in t=
he packet
      whose SSRC is found in the outgoing SSRC table, deliver a copy of
      the RTCP packet to the RtpSender associated with that SSRC."

To:=C2=
=A0

      &quo=
t;If the packet is of type RR, for each report block in the packet
      whose "SSRC of source" is found in the outgoing SSRC table, deliver a co=
py of
      the RTCP packet to the RtpSender associated with that=
 SSRC."


[BA] The RTCP SDES packet has no "SSRC of packet sender=
" field, so change:=C2=A0

      &q=
uot;If the packet is of type SDES, and the sender SSRC for the packet
      is found in the incoming SSRC table, deliver the packet to the
      RtpReceiver associated with that SSRC.  In addition, for each
      chunk in the packet that contains a MID that is in the table
      mapping MID to RtpReceiver, update the incoming SSRC mapping table
      to include an entry that maps the SSRC for that chunk to the
      RtpReceiver associated with that MID.  (This case can occur when
      RTCP for a source is received before any RTP packets.)"

To:

      "If the packet is of type SDES, for each chun=
k containing
      an "SSRC/CSRC" field fou=
nd in the incoming SSRC table,
      deliver the pack=
et to the RtpReceiver associated with that SSRC.
    =
  In addition, for each chunk in the packet that contains a MID that is in =
the table
      mapping MID to RtpReceiver, update the incoming SSRC mapping table
      to include an entry that maps the SSRC for that chunk to the
      RtpReceiver associated with that MID. (This case can occur when
      RTCP for a source is received before any RTP packets.)" 

[BA] Change: 


=
      "If the packet is of type BYE, for each SSRC indicated in the
      packet that is found in the incoming SSRC table, deliver a copy of
      the packet to the RtpReceiver associated with that SSRC."
<=
/pre>

To:

 
=

      "If the packet is of type BYE, for each "S=
SRC/CSRC" indicated in the
      packet that is found in the incoming SSRC table, deliver a copy of
      the packet to the RtpReceiver associated with that SSRC."
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px">
[BA] Change: 

      "If the packet i=
s of type RTPFB or PSFB, as defined in [RFC4585],
      and the media source SSRC for the packet is found in the outgoing
      SSRC table, deliver the packet to the RtpSender associated with
      that SSRC."

To:=


      "If the packet=
 is of type RTPFB or PSFB, as defined in [RFC4585],
      and the "SSRC of media source" for the packet is found in t=
he outgoing
      SSRC table, deliver the packet to the RtpSender associated with
      that SSRC."

[BA=
] Since FIR feedback messages can contain multiple FCI fields, I think you<=
/pre>
need to add the following text (see RFC 5104 Section 4.3.1.1): =


      "In ad=
dition, for FIR feedback messages, as defined in [RFC5104],
      for each "SSRC" indicated in an FCI entry, deliver a=
 copy of the
      packet to the RtpSender associated=
 with that SSRC.
--001a114485f436b9fd053fce2f71-- From nobody Thu Oct 27 00:06:19 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4121129418 for ; Thu, 27 Oct 2016 00:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (bad RSA signature)" header.d=sdiwc.info 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 28Ie5cN872Mz for ; Thu, 27 Oct 2016 00:06:16 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id F30B61293DF for ; Thu, 27 Oct 2016 00:06:15 -0700 (PDT) Received: (qmail 12746 invoked by uid 0); 27 Oct 2016 07:06:14 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 27 Oct 2016 07:06:14 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by CMOut01 with id 0X0f1u02N2Yhrsa01X0ijs; Thu, 27 Oct 2016 01:00:44 -0600 X-Authority-Analysis: v=2.1 cv=beT4Do/B c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=N1z6yVdWAAAA:8 a=m7MRygL9siagT3J2NmAA:9 a=CjuIK1q_8ugA:10 a=FST94vGo_0DdB_9W1aeC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=g/rF0doCrpNjVVc5ckj0cyUsqO0lUz89TzB5GxJMNis=; b=W+JUL3VjdicUDfRMz3rBE6KX+RXltCCUy53+sTDQ/VlLWfnJpyal+v6T99kQXoP7oE2p2JwbUv z/DuN/3rgU/6xxTZ9ZaANHjmKkOq/ICvPYtEJa3pB3Hb86p132vlQF; Received: from [127.0.0.1] (port=58391 helo=mail.sdiwc.info) by box817.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bzeg4-0006av-KJ for rtcweb@ietf.org; Thu, 27 Oct 2016 01:00:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 27 Oct 2016 01:00:40 -0600 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: <3cd9cff929cf14c48867a50893666820@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box817.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sdiwc.info X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Exim-ID: 1bzeg4-0006av-KJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (mail.sdiwc.info) [127.0.0.1]:58391 X-Source-Auth: jackie@sdiwc.info X-Email-Count: 4 X-Source-Cap: c2Rpd2NuZXQ7c2Rpd2NuZXQ7Ym94ODE3LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [rtcweb] CyberSec2017 Call for Papers and Special Session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 07:06:17 -0000 You are invited to contribute, participate and/or submit your research paper. The Fifth International Conference on Cyber Security, Cyber Welfare and Digital Forensic (CyberSec2017) St. Mary's University, Addis Ababa, Ethiopia April 22-24, 2017 http://sdiwc.net/conferences/6th-international-cyber-security-cyber-welfare-digital-forensic/ Paper Submission Deadline: March 1, 2017 ========================== Call for Special Session ========================== The conference also welcomes researchers to organize special session in any one of the tracks in cyber security and digital forensic with regards to the conference topic. Mechanics: Special Sessions may address one or more tracks, but they should be organized under a unified theme. Each special session should attract 6 registered papers. These papers will be part of the Conference Proceedings, and they will be published in the proceedings of the conference and will be sent to at least 10 indexing places. Submission: Send your session title and summary as detailed in the conference website. From nobody Thu Oct 27 06:43:43 2016 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 E0F35129483; Thu, 27 Oct 2016 06:43:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147757582191.24720.3318382294190482547.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 06:43:41 -0700 Archived-At: Cc: draft-ietf-rtcweb-transports@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [rtcweb] Protocol Action: 'Transports for WebRTC' to Proposed Standard (draft-ietf-rtcweb-transports-17.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 13:43:42 -0000 The IESG has approved the following document: - 'Transports for WebRTC' (draft-ietf-rtcweb-transports-17.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ Technical Summary This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Working Group Summary Nothing particularly controversial in this spec. It is largely just a pointer to other specifications saying if you do WebRTC, then you need to what RFC X,Y, and Z says. Based on the WGLC comments, the chairs suggest adding an RFC Ed note to include an informative reference to draft-ietf-rtcweb-return however there is not WG consensus to make this a MUST or SHOULD implement. (Cleary nothing forbids implementing it so it is already an MAY implement) Document Quality Much of this is implemented in chrome and firefox which share a significant amount of code with respect to this so some parts of it has 2 implementations, some parts 1, and some none. Personnel Cullen Jennings is the document shepherd. Alissa Cooper is the responsible AD. From nobody Thu Oct 27 09:48:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC542129629 for ; Thu, 27 Oct 2016 09:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rSV50B45xTG for ; Thu, 27 Oct 2016 09:48:55 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9531294C9 for ; Thu, 27 Oct 2016 09:48:55 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id c126so20297708vkd.1 for ; Thu, 27 Oct 2016 09:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Iyp3FJxj5IE2yofH1Po8DOGe7qCb0yv9md6YaNYlkd4=; b=oB9loNCOfNEO62qbFWJZPBlrYxe3v2zjAFDVhhvC7SX4RQXrD0M/17+xO0/UtNdhlH RYcN02rGVL7oTHpziqXAgJnS2Kc2gfU8kKS4+B4NXYrKSwgayDy8lDKajIDJVWCd3MKb jkZ5vXnaELMehMgRO7ztr8oxAgviwWIEjME55WU7/B0DQlp1eA3V2bDuW9hKVoOqmSdo PC6Wx3EUZnPy7XospW65CF4g6Kkd00P+7VFYdcZgGneVymg1RrAxsn9zDroZC8A9a4Pc MIUCMYYQgLj8cwf8EZUcTAJYvuHQC9EvzpWwkxpxbTKyOZ/YM22MljMHv5HzgqtayIkf R6eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Iyp3FJxj5IE2yofH1Po8DOGe7qCb0yv9md6YaNYlkd4=; b=luxektlfodvBP6n1W4cjpGLhHaVBhLm8CEdKULKWnzbg2JGz0aoVzC8baV+aVHp6F+ kptpno8qty6QPYHRVCDxeEtxnPzSNOgN9dJPGVEmVI2MAAP042ICLo7S5nYq10dYOwZ0 p+HpP2Wx4wzmVCe7wi6O7IUVZyFwv1+KYQ0kdzSs5ulsVD/NI/CsUwoFoglNlJTBeXuL gYeXpnib5oW5rhRwWEezLkfX7JoEdpFblz7PaBzJb25YGf/Q/2n++Cx754tD3PAx5WL3 qlVWG+To36nK7XbNuNocYFikTGrj5QtnHT/C94xxXkQ5T3pk4JhP4iI24RRxFdXFoJ9f +GQw== X-Gm-Message-State: ABUngveDhkIYvbHOc8Ny6HdrZDJHWjSUa/5MF7kTE95CEZOjbdVXJJz7LGBcf73ENV4YSKq1f2mRl8cvAT1Ybg== X-Received: by 10.31.224.71 with SMTP id x68mr6751251vkg.63.1477586933903; Thu, 27 Oct 2016 09:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.88 with HTTP; Thu, 27 Oct 2016 09:48:33 -0700 (PDT) From: Bernard Aboba Date: Thu, 27 Oct 2016 09:48:33 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07bb88520f9a053fdb84f8 Archived-At: Subject: [rtcweb] JSEP Section 3.7:Simulcast X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 16:48:57 -0000 --94eb2c07bb88520f9a053fdb84f8 Content-Type: text/plain; charset=UTF-8 JSEP currently does not provide an API to configure receipt of simulcast. This means that if simulcast is offered by the remote endpoint, the answer generated by a JSEP endpoint will not indicate support for receipt of simulcast, and as such the remote endpoint will only send a single encoding per m= section. [BA] In the description of addTransceiver, WebRTC 1.0 Section 5.1 states: However whensetRemoteDescription is called with a corresponding remote description that is able to send multiple RTP encodings as defined in [JSEP ], the RTCRtpReceiver may receive multiple RTP encodings and the parameters retrieved via the transceiver's receiver.getParameters() will reflect the encodings negotiated. This appears to indicate that a JSEP endpoint may indicate support for receipt of simulcast in an answer. In addition, when the JSEP endpoint is the answerer, the permitted encodings for the RTPSender must be consistent with the offer, but this information is currently not surfaced through any API. [BA] Not sure what this is trying to say. Once setRemoteDescription is called on the JSEP endpoint, won't it be possible to retrieve the sender settings via sender.getParameters() and the receiver settings via receiver.getParameters()? This means that established simulcast streams will continue to work through a received re-offer, but setting up initial simulcast by way of a received offer requires out-of-band signaling or SDP inspection. Future versions of this specification may add additional APIs to provide this control. [BA] Does this mean that a JSEP endpoint cannot respond to an offer to receive simulcast with an Answer indicating that it will send simulcast? Note sure why this would be the case, particularly if addTransceiver was called prior to setRemoteDescription indicating the ability to send simulcast. --94eb2c07bb88520f9a053fdb84f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
   JSEP currently does not=
 provide an API to configure receipt of
   simulcast.  This means that if simulcast is offered by the remote
   endpoint, the answer generated by a JSEP endpoint will not indicate
   support for receipt of simulcast, and as such the remote endpoint
   will only send a single encoding per m=3D section.  
[BA] In the description of addTransceiver, WebRTC 1.0 Sec=
tion 5.1 states: 
However whensetRemoteDescription<=
/code>=C2=A0is called with a corresponding remote description that is able =
to send multiple RTP encodings as defined in [JSEP], the=C2=A0RTC=
RtpReceiver=C2=A0may receive multiple RTP encodings and t=
he parameters retrieved via the transceiver's=C2=A0receiver.getParameters()=
=C2=A0will reflect the encodings negotiated.
This appears to indicate that a JSEP endpoint may =
indicate support for receipt of simulcast in an answer.=C2=A0
<= pre style=3D"color:rgb(0,0,0)"> In addition, when the JSEP endpoint is the answerer, the permitted encodings for the RTPSender must be consistent with the offer, but this information is currently not surfaced through any API. 
[BA] Not sure what this is trying to say. Once setRemoteDescription =
is
called on the JSEP endpoint, won=
9;t it be possible to retrieve the sender 
settings via sender.getParameters() and the receiver settings via 
receiver.getParameters()? 
   This means that established
   simulcast streams will continue to work through a received re-offer,
   but setting up initial simulcast by way of a received offer requires
   out-of-band signaling or SDP inspection.  Future versions of this
   specification may add additional APIs to provide this control.
[BA] Does this mean that a JSEP endpoint cannot=
 respond to an offer to receive
simulc=
ast with an Answer indicating that it will send simulcast? Note sure why
this would be the case, particularly if =
addTransceiver was called prior to 
se=
tRemoteDescription indicating the ability to send simulcast.
--94eb2c07bb88520f9a053fdb84f8-- From nobody Thu Oct 27 09:57:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7399C1294BE for ; Thu, 27 Oct 2016 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biC_pLP8JOeV for ; Thu, 27 Oct 2016 09:56:58 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5A31279EB for ; Thu, 27 Oct 2016 09:56:58 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d65so5393023vkg.0 for ; Thu, 27 Oct 2016 09:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2Agdu24x8iQoXmiLrf1PCaoslSfJjnYGnLIU5jhA6jg=; b=eFBS4V9aJC55pkvmc12e6dFVh7bz0u9KPv80KshFBxN+joVU12z+aGcP3VyScsKVqu JlAhotVPRSnow52y/KeDn0v+ttzc1xhP12q7Jlcpq+L2Bv9kFRw8MEKs5UYzLJIoAnw+ O5xxGeIzZuCnSe1V8t7saq7aMpnd+N5dZPBiT8GoKUWM4R6onfuER5D7wpmWN9He4kIy FWidXwDmU7DJcIOuu6tDOxKdyo5vsCC9a07II+XrbC0F2pccTau/RbhP5noRXGBslVd4 pBfs2TJ4kZfmP3+OlEV8l6qERscQ5hdvDDWS+CLKKcidnR9AJOHNg+XW4/b4GqtZj/fI ZYhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2Agdu24x8iQoXmiLrf1PCaoslSfJjnYGnLIU5jhA6jg=; b=SgtPBdHE09Byr3dQUWDaeOcegtPoU27Qm3vs2xLTfKInKK+CYi78ukLLlNHiRivAND 1X+ngTUPjHAA4Z6a3KT1T4JR0tF/ckGvlSegbPhpuUQ5T3On4BnmWBMq1NBpV6oGEuZg caHtaYNtdt1ELdJg3d522m38OJrX84MjowDxkIZlSZ4NMG/JnPglHE2IC30UxaPeeWXQ Updbtqlz5IihCz2eZY465wFE5jkzB+5MabYVylgcdRMb2mh6QNY16XTGRaEE86TrGjMi pJCtra1vKEHUKt/tg9fCdUR+3k58mXAUf31NYV/kLgcEoYu0IpnEDre6aChBRGYJgOm3 sfxw== X-Gm-Message-State: ABUngvfgZUsWh/ofEcgPY/rh9Kf8TIGhSRJAlPp4gXV9uDtLVJb7T2c/Acg71lKcHWb3MOJ1YUuTX2F8BnBptw== X-Received: by 10.31.130.74 with SMTP id e71mr7595075vkd.34.1477587417041; Thu, 27 Oct 2016 09:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.88 with HTTP; Thu, 27 Oct 2016 09:56:36 -0700 (PDT) From: Bernard Aboba Date: Thu, 27 Oct 2016 09:56:36 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114485f41e11f0053fdba16a Archived-At: Subject: [rtcweb] JSEP Section 4.2.2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 16:56:59 -0000 --001a114485f41e11f0053fdba16a Content-Type: text/plain; charset=UTF-8 *4.2.2. stopped The stopped method returns "true" if the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer* that govern *rejects* the creation and processing of offers *associated m= section,* and answers. *"false" otherwise.* *[BA] This should be rewritten as follows: * * The stopped attribute has the value "true if the RtpTransceiver has been stopped,* * either by a call to transceiver.stop() or by applying an answer that* * rejects the associated m= section and "false" otherwise.* --001a114485f41e11f0053fdba16a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
4.2.2.  stopped

   The stopped method returns "true" if the transceiver has been
   stopped, either by a call to stopTransceiver or by applying an answer
   that govern rejects the creat=
ion and processing of offers =
associated m=3D section, and an=
swers. "false" othe=
rwise.

[BA] This should be rewritten as follows: <=
/font>
    The stopped attribute has the value "true if the RtpTransc=
eiver has been stopped,
    either by a call to transceiver.stop() =
or by applying an answer that
    rejects the associated m=3D secti=
on and "false" otherwise.

--001a114485f41e11f0053fdba16a-- From nobody Thu Oct 27 17:59:21 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3375C12998D for ; Thu, 27 Oct 2016 17:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ-MQ6M2fxwl for ; Thu, 27 Oct 2016 17:59:18 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7142212999E for ; Thu, 27 Oct 2016 17:59:18 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z190so68629723qkc.2 for ; Thu, 27 Oct 2016 17:59: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=Efh2jHU23pRlKKaMO3lwHsMY23TZ21WYlzyTxPI7eNk=; b=jChkCHs3b9iBff9HIpNKL4Z1Biy7QDMpx5WwznGlJVqTmYhXVotsTj2PjJ3aCcXmu6 1LgKDeAr4PFE5f4wRdrC+1OM3+wj4dKMs6uPij0Agtci+7pot1oQ7wu0hTxiCh0T5CQ3 eaE1U/WGFlclC0Payx/f9KQ9Dh5gg4ZUO7C4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Efh2jHU23pRlKKaMO3lwHsMY23TZ21WYlzyTxPI7eNk=; b=S0xr9TmWIF8DMOEYl0huKHV/KbAqj7zStNQfVa49QEj+1CQMeZ7BxYk5AlNUc0g/vd ok3vsnDGZvn4eIMw0bPUWypJu6x9PzWajztAIlvbxwlzLV3ORGF93qn2Azu+x8olP4un V8ueFG0eRdlxyaYArVlHAr2z3I+MJxKpyl9gyjp3agSKGjFyCa+tA+OBkCTqaaTMIeAd ciXkjxNBfv/OHaRR704lRV+YZoP60QvQo6JwAp44EdcSnIWM2ERY2UexCUneIbJlBESc eCDpy4Ke2B9LHtQDn0Y422I9QhkKLd5lwqV7TtAt68O3rmU/f/xPQO2W8ndX6bMMM2S5 eO0g== X-Gm-Message-State: ABUngvcYbAIXrvnsjvMgN8reT2lbJgMcN9M0E7KQ+x3+bOHvP9bRJ2m7KB+6nJeqKB1OGw== X-Received: by 10.55.162.79 with SMTP id l76mr8201833qke.17.1477616357428; Thu, 27 Oct 2016 17:59:17 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id 141sm5055410qkd.11.2016.10.27.17.59.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Oct 2016 17:59:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <147757582191.24720.3318382294190482547.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 20:59:15 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0C0ADCED-389F-4D26-8C64-AB58BA20B85A@sn3rd.com> References: <147757582191.24720.3318382294190482547.idtracker@ietfa.amsl.com> To: draft-ietf-rtcweb-transports@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Protocol Action: 'Transports for WebRTC' to Proposed Standard (draft-ietf-rtcweb-transports-17.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 00:59:20 -0000 Congrats! Another draft has progressed down the road: https://giphy.com/gifs/car-reactiongifs-mrw-T4YX44tlqOKaI/fullscreen spt > On Oct 27, 2016, at 09:43, The IESG wrote: > > The IESG has approved the following document: > - 'Transports for WebRTC' > (draft-ietf-rtcweb-transports-17.txt) as Proposed Standard > > This document is the product of the Real-Time Communication in > WEB-browsers Working Group. > > The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa > Cooper. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > > > Technical Summary > > This document describes the data transport protocols used by WebRTC, > including the protocols used for interaction with intermediate boxes > such as firewalls, relays and NAT boxes. > > Working Group Summary > > Nothing particularly controversial in this spec. It is largely just a > pointer to other specifications saying if you do WebRTC, then you need > to what RFC X,Y, and Z says. > > Based on the WGLC comments, the chairs suggest adding an RFC Ed note > to include an informative reference to draft-ietf-rtcweb-return > however there is not WG consensus to make this a MUST or SHOULD > implement. (Cleary nothing forbids implementing it so it is already an > MAY implement) > > Document Quality > > Much of this is implemented in chrome and firefox which share a > significant amount of code with respect to this so some parts of it > has 2 implementations, some parts 1, and some none. > > Personnel > > Cullen Jennings is the document shepherd. Alissa Cooper is the > responsible AD. From nobody Fri Oct 28 23:48:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A20129432; Fri, 28 Oct 2016 23:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 68NjzuU2Qf0b; Fri, 28 Oct 2016 23:48:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1E61293E4; Fri, 28 Oct 2016 23:48:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3C3E27C0B4B; Sat, 29 Oct 2016 08:48:52 +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 r48bqYtuAsXA; Sat, 29 Oct 2016 08:48:50 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:40e9:5b1e:a3cd:b35e] (unknown [IPv6:2001:470:de0a:1:40e9:5b1e:a3cd:b35e]) by mork.alvestrand.no (Postfix) with ESMTPSA id F1D107C099C; Sat, 29 Oct 2016 08:48:49 +0200 (CEST) To: Sean Turner , draft-ietf-rtcweb-transports@ietf.org References: <147757582191.24720.3318382294190482547.idtracker@ietfa.amsl.com> <0C0ADCED-389F-4D26-8C64-AB58BA20B85A@sn3rd.com> From: Harald Alvestrand Message-ID: Date: Sat, 29 Oct 2016 08:48:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <0C0ADCED-389F-4D26-8C64-AB58BA20B85A@sn3rd.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Protocol Action: 'Transports for WebRTC' to Proposed Standard (draft-ietf-rtcweb-transports-17.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 06:48:56 -0000 On 10/28/2016 02:59 AM, Sean Turner wrote: > Congrats! Another draft has progressed down the road: > https://giphy.com/gifs/car-reactiongifs-mrw-T4YX44tlqOKaI/fullscreen Hooray! It is now part of RFC Editor's cluster 238, a giant snarl of dependencies: https://www.rfc-editor.org/cluster_info.php?cid=C238 An outstanding item here is the -security drafts; do we have any updated status on those? > > spt > >> On Oct 27, 2016, at 09:43, The IESG wrote: >> >> The IESG has approved the following document: >> - 'Transports for WebRTC' >> (draft-ietf-rtcweb-transports-17.txt) as Proposed Standard >> >> This document is the product of the Real-Time Communication in >> WEB-browsers Working Group. >> >> The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa >> Cooper. >> >> A URL of this Internet Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >> >> >> >> >> >> Technical Summary >> >> This document describes the data transport protocols used by WebRTC, >> including the protocols used for interaction with intermediate boxes >> such as firewalls, relays and NAT boxes. >> >> Working Group Summary >> >> Nothing particularly controversial in this spec. It is largely just a >> pointer to other specifications saying if you do WebRTC, then you need >> to what RFC X,Y, and Z says. >> >> Based on the WGLC comments, the chairs suggest adding an RFC Ed note >> to include an informative reference to draft-ietf-rtcweb-return >> however there is not WG consensus to make this a MUST or SHOULD >> implement. (Cleary nothing forbids implementing it so it is already an >> MAY implement) >> >> Document Quality >> >> Much of this is implemented in chrome and firefox which share a >> significant amount of code with respect to this so some parts of it >> has 2 implementations, some parts 1, and some none. >> >> Personnel >> >> Cullen Jennings is the document shepherd. Alissa Cooper is the >> responsible AD. -- Surveillance is pervasive. Go Dark. From nobody Mon Oct 31 16:49:54 2016 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 300D7129BED; Mon, 31 Oct 2016 16:49:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795779206.23286.8378300878125864662.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 16:49:52 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-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, 31 Oct 2016 23:49:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-04.txt Pages : 10 Date : 2016-10-31 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 16:58:02 2016 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 EA401129BF6; Mon, 31 Oct 2016 16:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795827995.23271.10493422219906237223.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 16:57:59 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-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, 31 Oct 2016 23:58:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-02.txt Pages : 8 Date : 2016-10-31 Abstract: This document provides best practices for how IP addresses should be handled by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-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/